Parsing a NetLogon exchange.

[Rafal Szczesniak]

On Tue, Aug 10, 2010 at 01:45:56PM -0500, Christopher R. Hertel wrote:
> 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?

It's the server implementation so yes, of course, it is possible. It's possible
to do that even with windows server given the right flags are negotiated during
rpc bind phase. What is the client implementation ?

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

Is the traffic signed, by the way ? It can still be preceded by schannel
auth handshake just the signing of rpc binding could have been requested.

> > 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.

I was assuming the traffic is encrypted so you couldn't see the NetrLogonSamLogon
status code. If it was a success then the authentication was successful, obviously.

> >> 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.

Yes, that's a network logon (challenge/response).

> 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.

They can be. All of those fields are optional.

> 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.

You could look at the hex dump and try to find the rpc opnum in rpc request.
That would give you some hint as to what rpc gets called next.


cheers,
-- 
Rafal Szczesniak
Samba Team member   http://www.samba.org
Likewise Software   http://www.likewise.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100810/9aba8a09/attachment.pgp>