[jcifs] NTLM and JCIFS: architecture/protocols

[Eric Glass]

> 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)?


Two hops is closer to the "real picture".  Windows provides an API
called the "Security Support Provider Interface" (SSPI).  This is a
framework with pluggable providers for authentication, encryption,
etc.; one of the providers is the NTLM Security Support Provider
(NTLMSSP), which implements the NTLM protocol suite (in addition to
the most visible aspect, authentication, there are also facilities for
encryption and message integrity provided by the API).

In a "normal" HTTP NTLM authentication scenario (i.e. IIS
authenticating a client via NTLM), the web server would take the
tokens provided by the client and feed them to the SSPI security
context setup functions as outlined here:

http://davenport.sourceforge.net/ntlm.html#ntlmsspAndSspi

The NTLMSSP library implementation on the server side would process
the tokens to authenticate the user and establish the context.  If the
account is local to the web server, this would be done against the
server's own SAM database.  If it is a domain account, the NetLogon
service would be used to authenticate the user against the domain
controller.  No CIFS would typically be involved at all (not quite
true, as the NetLogon connection is over a CIFS RPC pipe, but not
directly involved).

In the jCIFS scenario, we don't implement the NetLogon stuff.  So
instead, we act as a man-in-the-middle; we connect to a backend CIFS
server, which generates the information we need to create NTLM tokens
for the client, and also authenticates the client responses for us.
So we appear as a CIFS client to the intermediate server.


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


In addition to the NTLMSSP provider, Windows also provides a Kerberos
SSPI provider.  There is also a SPNEGO provider, which is basically a
wrapper - it allows the server and client to negotiate the underlying
provider that is actually used.  So if Kerberos is available, that is
used, and otherwise NTLM is used.

"Classic" CIFS only uses NTLM authentication (actually just passes the
challenge and response fields).  Newer implementations provide support
for CIFS "extended security", which passes arbitrary authentication
blobs between the server and client.  These blobs are basically passed
to the SPNEGO provider, allowing the server and client to negotiate
either Kerberos or NTLM for authentication.  This same mechanism is
also used by the IIS "Negotiate" authentication mechanism - providing
support for either NTLM or Kerberos HTTP authentication.

The Kerberos patch for jCIFS implements CIFS extended security, which
supports the above.  The normal jCIFS just supports NTLM-based
authentication.


Eric