[jcifs] Annoying SMB URL question.

[Christopher R. Hertel]

On Mon, Dec 09, 2002 at 06:09:08AM -0500, Michael B. Allen wrote:
:
> > Just my two cents.  On another note (out of curiosity), in my environment we
> > have two domains (for example, "DOM1" and "DOM2") which I'm assuming are set
> > up with some sort of trust relationship; that is, I can log into box
> > "server" which is a member of DOM2 using my account "eric" in DOM1.  How
> > would that be represented in a URL, where my user credentials are for an
> > account in one domain ("DOM1\eric"), but I am accessing a resource on a
> > server which is a member of another domain ("DOM2\server")?
> 
> I don't know if the domain that this server is a member of differs from
> it's workgroup but if there is any semantic difference I don't know
> of any case where that would need to be represented with an SMB URL. A
> "server that's a member of a domain" is not an addressable resource.

It is my understanding (heh) that when you authenticate to the server you
indicate your native domain.  The server asks its DC (assuming
pass-through auth) and the DC then passes the query along to the DC for 
your native domain (assuming trust relationship).

So the key thing is to be able to tell the auth system which NT domain is 
your "native" NT domain.  ...your "home" domain.  That's why the 
nt_dom;user syntax exists.

Note that this is *separate* from the workgroup browsing functionality.  
Workgroups and NT Domains are overlapping concepts, which causes no end of 
confusion.  Still, even if you are a member of DOM1 you may want to browse 
the DOM2 workgroup.  We needed to allow you to do that.  The syntax would 
be:

  smb://DOM1;eric:passwd@DOM2/

That should give you the browse list for DOM2.

The SMB protocol suite is fairly messy, and we are trying to accomodate a 
very bigbunch of stuff in the SMB URL:

  * Access to SMB servers and shares over NBT transport.
  * Access to NBT Workgroup listings, including the local workgroup list.
  * Access to SMB servers and shares over naked TCP transport (port 445).
  * Access to AD domain listings (via LDAP).

That's a lot of overloading, which is why the SMB URL is so complex.  It's 
also why folks like Conrad had to put up with a lot of kvetching from me 
at the last two CIFS conferences.  I appreciate that they were willing to 
do so.  I think we have a better understanding of this URL form as a 
result.

Chris -)-----

-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org