[jcifs] NTLM Authentication and multiple domains

eglass1 at comcast.net eglass1 at comcast.net
Thu Apr 22 20:39:33 GMT 2004


> --> jorourke represents a username (sorry about not making this clearer). It
> seems to me from experimenting with IE accessing an IIS NTLM protected
> resource, that the first message does not contain domain information. To my
> knowledge, this would imply that IIS has no way of supporting multi-domain
> NTLM authentication. If it could, how would it be able to get the challenge
> for Type2 message from the *correct* DC. From what I can see, you are right,
> that the only sensible way to do multi-domain login is through setting up of
> trust relationships. Can you confirm this inference about IIS? 
> 

The Type 1 message will only contain the supplied domain (primary domain of
the client workstation) if it is attempting to "feel out" local authentication
(to employ the existing logon session against the local machine).  This
happens when "automatically log on" is selected in the IE options.  Under
manual NTLM (where you type in the username in a prompt) a new logon session
will be established; the supplied domain/workstation aren't sent because IE
knows this is a new session.  The supplied domain also isn't sent by Win9x
clients.  Also, note that the supplied domain is the primary domain for the
workstation, not necessarily related to the user's login domain.  There are
some notes here:

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

Logons to a "real" IIS server work a bit differently than jCIFS does.  We do
the following:

1)  client sends type 1 message to HTTP server

2)  server connects via SMB to "domain controller" (could be any SMB server);
SMB server gives us a challenge

3)  server sends type 2 message to client, containing challenge from SMB
server

4)  client sends type 3 message to server, containing response to challenge

5)  server completes handshake with SMB server by passing on the
response from the client


Essentially, we're a benevolent man-in-the-middle attack.  NetLogon-based
authentication is the typical case nowadays, which is:


1)  client sends type 1 message to HTTP server

2)  server generates *its own* challenge and sends it in a type 2 message
to the client

3)  client sends type 3 message to server, containing response to challenge

4)  server sends both the challenge and the response to an actual live domain
controller, over the encrypted NetLogon RPC pipe (a connection made using
the machine's domain account).

5)  domain controller responds with result of authentication and session key
(for signing operations if needed).


This is why applications like Davenport are able to overcome the "double hop"
issue IIS has; we pass the authentication through to the target server, so
the connection is authenticated from end-to-end.  It's also why Davenport
doesn't work with SMB signing; we don't have the session key in this scenario
(as man-in-the-middle attacks are precisely what SMB signing is intended to
prevent).

Long term (once NetLogon RPC support is available), the intent is for
Davenport to use a "hybrid" model:

1)  client sends type 1 message to HTTP server

2)  server connects via SMB to any backend SMB server.  SMB server gives us a
challenge

3)  server sends type 2 message to client, containing challenge from SMB
server

4)  client sends type 3 message to server, containing response to challenge

5)  server sends both the challenge and the response to a domain controller,
over the encrypted NetLogon RPC pipe.

6)  server responds with result of authentication and session key

7)  server completes handshake with SMB server by passing on the
response from the client


So we still use the "man-in-the-middle" approach to overcome the double-hop
issue; but we also authenticate using NetLogon to get the session key, so
we can sign SMB messages to the SMB server.  That's the theory anyway.


Eric



More information about the jcifs mailing list