Parsing a NetLogon exchange.

Christopher R. Hertel crh at
Tue Aug 10 12:45:56 MDT 2010

Rafal Szczesniak wrote:
> Chris,
> By default, none of logon calls are visible. You can request signing-only
> for schannel/netlogon binding but that's good only for hacking and testing.
> In production environment it has to be sealed, obviously.

Interesting...  I can see the request itself and much of the response too.
Is it possible that the implementation I am studying doesn't support
schannel encryption?

I can, for example, see the Identity Information as well as the LMv1 and
NTLMv1 crypto-responses in the NetLogon request.

>> How do I know whether the credentials presented by the client were accepted
>> (successful authentication) or rejected?
> Decrypt the PDU and check status code ?

Which status code where?  :)

The NTSTATUS code in the NetrLogonSamLogon response shows success, but that
only indicates (to me) that the transaction operation was successful.  I was
hoping for a clear indication somewhere in the protocol that the DC was
happy with the credentials provided by the client.  As you say below, I
think the elongated response is that indication.

>> It looks to me as though the server is returning success, because there is a
>> roughly 6K blob that is read from the named pipe.  I'm assuming that this
>> blob is the authorization information that the DC sends back to the server,
>> and that the server uses in order to determine what it is that the client
>> may access.  As I understand it, that information would not be returned if
>> the authentication failed.
>> The thing is, the server implementation that I'm studying returns Bad
>> Password to the client.  If I'm right that the authorization information is
>> only returned by the DC if authentication is successful, then there must be
>> something in the authorization information that is causing access to be denied.
> You are right. Only successful authentication counts here. Is it password or network
> logon (see netr_LogonLevel type in netlogon.idl) ?

It's Level 2, which WireShark says is a NetrLogonSamLogon.  That seems to
match what the Samba netlogon.idl says.

WireShark reassembles the packets coming back from the DC.  There is a
Transaction response and a ReadAndX to retrieve remaining data from the
pipe.  Unfortunately, WireShark only lists the important results as "Stub Data".

I had a little more luck with NetMon.  It parses out things like last
logon/logout times, LogonCount, etc.  It also affirms that the
"EffectiveName" is the same as what was sent in the NetLogon request.
Things like FullName, LogonScript, and HomeDirectory are left NULL, however.

The next big chunk of the transaction after that remains a mystery.  I had
assumed that it could not be parsed because it was encrypted, but since I
can see so much of the rest of the response, I'm beginning to suspect that
the CIFS server in the middle here is not capable of encrypting the schannel.


Chris -)-----

"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team --     -)-----   Christopher R. Hertel
jCIFS Team --   -)-----   ubiqx development, uninq.
ubiqx Team --     -)-----   crh at
OnLineBook --    -)-----   crh at

More information about the samba-technical mailing list