Are you saying that it could be as simple as adding a case like this one headed
up by a 'case 10:' ?
case 1: werr = init_srv_sess_info_1(p,
r->in.info_ctr->ctr.ctr1,
r->in.resume_handle,
r->out.totalentries);
break;
On Tuesday, 11 September 2018, 11:02:31 GMT-7, Andrew Bartlett via samba
<samba at lists.samba.org> wrote:
On Tue, 2018-09-11 at 15:52 +0000, ray klassen via samba
wrote:> so I sent you the dump separately. and i tried a persistent drive
> mapping to \\DC\netlogon which I figured should create a more
> permanent session as you described. That worked the same.
>
> On Tuesday, 11 September 2018, 08:21:50 GMT-7, Andrew Bartlett
> via samba <samba at lists.samba.org> wrote:
>
> On Tue, 2018-09-11 at 15:14 +0000, ray klassen via samba wrote:
> >
> >
> > Yes, after further research the solution could possibly be to
> > create
> > a python script to monitor the json output in log.samba and push
> > out
> > eventlog formatted events to 'Security' with eventlogadm.
Seems a
> > lot
> > of work.
> That still assumes the appliance is reading the same type of event
> log
> (because the eventlog RPC service was superseeded by eventlog6 and
> the
> WMI thin, which is the reason I asked for details).
>
> >
> > The appliance in question also supports getting the necessary info
> > via the netapi call "netsessionenum" I have tried that and a
> > wireshark dump shows samba replying with WERR_INVALID_LEVEL.
> >
> > if you could shed any light on that, I would appreciate it.
> If you could get the exact details on that, or the capture file if
> not
> confidential, that would be good.
This showed that it uses srvsvc_NetSessEnum level 10, whereas Samba
only supports level 0 and 1. Perhaps have a go at implementing level
10? It looks like just a cut down version of level 1.
source3/rpc_server/srvsvc/rpc_srvsvc_nt.c
The tests could do with some work however, they are at:
source4/torture/rpc/srvsvc.c
but don't actually check for anything, including if the call even
worked, let alone expected data...
> Note however that the Samba AD DC doesn't have a persistent
> connection
> from the client unless you mount a share, so even if it worked it
> wouldn't show up all the clients reliably.
>
> (A domain login to AD can be done with just a kerberos ticket
> exchange).
A persistent drive mapping would fix that, certainly.
Thanks,
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba