[jcifs] NTLM and JCIFS: architecture/protocols

Alastair Green alastair.j.green at hotmail.co.uk
Mon Feb 19 17:00:19 GMT 2007

Eric, Chris:

Thank you very much for these detailed replies.

A couple of follow-on questions, if you don't mind.

1) I mentioned NTLMSSP as if it were a library that provided client access 
to a DC. Is it that, or is it a service that then accesses the DC behind the 
scenes? In other words are we dealing with three net hops (browser to 
server, server to NTMSSP service, NTLMSSP to DC) or two (browser to server, 
server to DC via NTMLSSP as a library)?

2) I read in one of the references you supplied that Kerberos is the 
"default authentication protocol" for NTLMSSP, or a similar statement. What 
exactly is the relationship between CIFS and Kerberos? The latest version of 
JCIFS is billed as supporting Kerberos, for example, implying that 
previously it was not using Kerberos?

Thanks again,


>From: "Eric Glass" <eric.glass at gmail.com>
>To: "Christopher R. Hertel" <crh at ubiqx.mn.org>
>CC: "Alastair Green" <alastair.j.green at hotmail.co.uk>, 
>jcifs at lists.samba.org
>Subject: Re: [jcifs] NTLM and JCIFS: architecture/protocols
>Date: Thu, 15 Feb 2007 13:57:52 -0500
>>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 
>>    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, 
>>that it is also the formula used to create a man-in-the-middle attack.
>In the newer NETLOGON scenario, the intermediate web server (or file
>server in the case of CIFS) generates the challenge; both the
>challenge and the client's corresponding response are sent to the
>domain controller over the NETLOGON RPC pipe, and the DC indicates
>success by providing the session key back to the intermediate server.
>This has a couple of advantages over the straight passthrough in the
>case of CIFS:
>1) It allows SMB/CIFS signing between the client and intermediate
>server (this is not possible in a passthrough scenario, since the
>intermediate server does not have access to the raw password hash
>needed to calculate the session key).
>2) It prevents the man-in-the-middle attack previously described (as
>the NETLOGON pipe is mutually authenticated, the DC "knows" it is
>actually talking to the intermediate server).
>In the case of HTTP, the advantages are minimal (since there is no
>signing/MAC between the web browser and web server).  It does provide
>some assurance against rogue web servers I suppose (since if all
>servers are configured to require signing, a malicious web server
>would hypothetically not be able to participate).
>In the jCIFS case, we do "preauthentication" to get around this;
>basically the web server makes a CIFS connection to a backend server
>(DC or other domain member), acting as a man-in-the-middle; we exploit
>the fact that SMB/CIFS signing establishes a session key for each
>physical connection rather than each authentication.  So we connect
>using an account for which we have the credentials, setting up signing
>with a key derived from the known password, and can then use that
>established pipe to act as a man-in-the-middle for subsequent
>authentication requests.

Upload 500 photos a month & blog with your Messenger buddies on Windows Live 
Spaces. Get yours now, FREE! http://specials.uk.msn.com/spaces/default.aspx

More information about the jcifs mailing list