[jcifs] NTLM and JCIFS: architecture/protocols

[Alastair Green]

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.

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