[jcifs] NTLM Authentication and multiple domains

[O'Rourke, James]

So given this case, it implies that an application with access to NetLogon
RPC such as IIS in this case is able to defer resolving the domain until
message 3, however using jCIFs as it currently stands, is not able to do
this. 

Is it the case that in this current jCIFs scenario that the SMB server which
provides the challenge in Type2, once it receives the Type3 response from
the client, then in fact takes this response (Type3) + the challenge it
provided and forwards it to the appropriate domain controller based on the
actual domain information for the account being authenticated as is
encapsulated in the Type3 message or is this not necessary. Perhaps I'm way
off target. 

Finally, when a domain controller (say DC1) receives a Type3 message to
authenticate joeuser say, but joeuser has only an account on another domain
(with say DC2), which DC1 has a trust relationship with, then will this
request be authenticated nonetheless?



-----Original Message-----
From: eglass1 at comcast.net [mailto:eglass1 at comcast.net] 
Sent: Thursday, April 22, 2004 1:40 PM
To: O'Rourke, James
Cc: jcifs at lists.samba.org
Subject: RE: [jcifs] NTLM Authentication and multiple domains



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