[jcifs] NTLM Authentication and multiple domains

O'Rourke, James jorourke at rsasecurity.com
Thu Apr 29 19:25:13 GMT 2004

My apologies. It seems to be working now. Ooops.

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

> I have now set up 2 domains with bi-directional explicit trusts 
> between them however when I try to authenticate a user say on domain1 
> by querying in jCIFS the dc on domain2 (domain1 and domain2 trust each 
> other) I still get an access denied exception. Am I missing something. 
> Is there something specific that would cause this.

Hmm.  Are you able to access files on a domain2 box using explorer with a
domain1 account?  I can't think of anything offhand that would prevent this
from working.  One thing to try would be to access a member server (i.e.,
instead of going against the domain2 domain controller directly with a
domain1 account, go against a machine that is a member of domain2).  If that
doesn't work, a packet trace from the domain2 box might shed some light on
things (as that would have the traffic from the client plus the inter-domain


> -----Original Message-----
> From: Eric [mailto:eglass1 at comcast.net]
> Sent: Thursday, April 22, 2004 6:16 PM
> To: O'Rourke, James
> Cc: jcifs at lists.samba.org
> Subject: Re: [jcifs] NTLM Authentication and multiple domains
> O'Rourke, James wrote:
> > 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.
> > 
> Kind of.  The authentication domain is known with the type 3; I don't
> think the server will actually "resolve" it though.  The server is 

> joined to a domain, and receives an account on the domain controller;
> this is the account that is used to set up the NetLogon pipe.  So the 
> server effectively talks to a single domain controller, regardless of 
> what domain the user specifies; the domain controller uses trust 
> relationships to talk to other domains.  I'm fuzzy on how this last bit 
> works myself.
> > 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.
> > 
> The response has to go to the server that generated the challenge.  So
> whatever server generated the challenge in the type 2 message has to get 

> the responses from the type 3 (even if the type 3 indicates a 
> different
> authentication domain).  In the NetLogon scenario you could have the 
> server send the challenge and response to an arbitrary/appropriate 
> domain controller; however, the server would need to have a machine 
> account established in each domain (i.e. it would need to "join" 
> multiple domains).
> > 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?
> > 
> Yes; that's what the trust is for.
> Eric

More information about the jcifs mailing list