[jcifs] NTLM and JCIFS: architecture/protocols

Christopher R. Hertel crh at ubiqx.mn.org
Thu Feb 15 18:16:20 GMT 2007


Below...

Alastair Green wrote:
> Hi,
> 
> After a lot of reading I'm still puzzling over a question about the
> architecture of the NTLM protocol(s).
> 
> Let me lay out my understanding and questions, and then someone can
> correct me.
> 
> NTLM is a challenge-response protocol supported by AD, whose client side
> is the NTLMSSP.
> 
> A Windows machine can run NTLM against an AD DC by using the NTLMSSP
> (possibly through many levels of indirection in terms of the piled APIs
> MSFT provide).
> 
> If this happens then AD will compare the NTLM hashed version of the u/p
> pair with its own records and authorize or otherwise accordingly.

Not quite.
Neither the password nor the password hash are ever sent over the wire.

As you mentioned above, it's a challenge-response protocol.  The challenge
is a random string sent by the server (not necessarily the AD server).  The
client encrypts the challenge to produce the response.  The server must
*also* encrypt the challenge using the hash.  It then compares the responses
(its own against the client's) to verify that they match.

  See: http://www.ubiqx.org/cifs/SMB.html#SMB.8.3

I'll let someone else answer regarding the specifics of the implementation
since there are some details I have not studied in a while.  In general,
however, there are two ways for the server to verify the response:

1) If it is a "domain member server", it will have (encrypted) access to
   the authentication database.  That gives the server access to the hashes
   themselves and the server can perform the encryption necessary to create
   the response.

2) If the server does not have direct (encrypted) access to the database,
   then it performs a proxy login.  It requests a login from the Domain
   Controller (or other server), which sends the challenge.  That challenge
   is then passed along to the client, which creates the response.  The
   response is then "passed through" to the DC.

The second method is great because it allows a system that is not a domain
member server to use domain authentication.  You may have noticed, however,
that it is also the formula used to create a man-in-the-middle attack.

Fun stuff, eh?

Chris -)-----

> HTTP NTLM Authentication is a variant of the NTLM protocol, where the
> challenge response messages are a) Base64 encoded, and b) passed in HTTP
> headers, and c) replace standard HTTP authentication exchanges like
> Basic Auth and Digest Auth.
> 
> When using NTLM/HTTP the web server end has to decide, between receiving
> the type 2 message-in-a-header and sending the type 3 message, whether
> the hashed u/p pair is good or bad.
> 
> Question (if I am roughly right so far): by what means does the web
> server establish the goodness or badness of the hashed auth data?
> 
> If the "web server" is the JCIFS HTTP Filter, does it (in classic mode,
> prior to introduction of Kerberos checking) a) do a CIFS authentication
> exchange, if such a thing exists, or b) run a non-HTTP version of NTLM
> (i.e. act as a bridge between NTLM/HTTP and NTLM/proper) or c) something
> else?
> 
> If the JCIFS HTTP Filter is doing Kerberos authentication, does it still
> do NTLM/HTTP between browser and Filter/WS, and merely use Kerberos as a
> goodness establisher, or is there something slicker going on?
> 
> Thanks in advance for any help you can give.
> 
> Alastair
> 
> _________________________________________________________________
> MSN Hotmail is evolving – check out the new Windows Live Mail
> http://ideas.live.com
> 

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org


More information about the jcifs mailing list