[jcifs] username dialog syntax changes

[Tapperson Kevin]

Thanks for the feedback Richard, I tried the combinations you described
and found jcifs to work fine with all of them.  I dug a little deeper
into the problem we were having with the '@' syntax and found that it
was some code in our custom filter implementation that was actually
breaking it.  (We have implemented some more robust lookups for domain
controllers in our filter, and those were failing when no domain was
provided in the type 3 message.)


These all work in jcifs:
  domain=MYDOM
  username=bob

  domain=my.domain.com
  username=bob

  domain=<not specified>
  username=bob at MYDOM

  domain=<not specified>
  username=bob at my.domain.com

The patch that I proposed to start this thread should not be applied;
jcifs works fine in all of the above cases as is.

-----Original Message-----
From: Richard Caper [mailto:rcaper at gmail.com] 
Sent: Monday, March 27, 2006 2:41 PM
To: Michael B Allen
Cc: Tapperson Kevin; jcifs at lists.samba.org
Subject: Re: [jcifs] username dialog syntax changes

I poked around with this awhile back... from what I recall the current
jCIFS actually works with some finagling.  From what I remember:

1) specifying "jcifs.smb.client.username" as the full kerberos-style
username with no jcifs.smb.client.domain specified works; i.e.
username = "bob at my.domain.com".

2) specifying "jcifs.smb.client.username" as the account username and
the full kerberos style realm as jcifs.smb.client.domain works.  i.e.
username = "bob" and domain = "my.domain.com".

3) specifying "jcifs.smb.client.username" as user at ntdomain also worked;
i.e. "bob at MYDOM" with no jcifs.smb.client.domain.

On 3/27/06, Michael B Allen <mba2000 at ioplex.com> wrote:
> On Mon, 27 Mar 2006 10:51:49 -0600
> "Tapperson Kevin" <Kevin.Tapperson at hcahealthcare.com> wrote:
>
> > >> > correct fix would be to use RFC 2052 SRV DNS lookups to find 
> > >> > the domain controller for the particular realm.
> > >>
> > >> In this case, what is the relationship then between a realm and a

> > >> domain.
> > >
> > >There is a 1:1 mapping between a user principal name and a SAM 
> > >account
> > name but the realm and domain are not required to >be the same. For 
> > example in a large company you might divide up your domains by 
> > department with a single realm.
> >
> > So, if I understand correctly, the <userid>@<domain> syntax is 
> > really just using the userPrincipalName attribute from AD.  And the 
> > userPrincipalName is composed of <sAMAccountName>@<realm>.
> >
> > It also appears from the packet captures that I had originally sent 
> > with this thread that the realm can be abbreviated.  The user used 
> > in the packet caputres (ylp4565 at wintel) has a userPrincipalName 
> > attribute in AD of ylp4565 at wintel.certlab.net.  (The domain for this

> > user is wintel.)
>
> So maybe it looks like <sAMAccountName> ~= <userPrincipalName> and 
> <realm> and <domain> are interchangeable since you can always get the 
> realm from the domain. But I'm no expert by any measure. I don't 
> really know what the definitive rules are. Regardless, I think jcifs 
> would still need a considerable modification to allow the domain to be
converted to realm.
>
> Incedentally, your patch was NOT integrated into 1.2.8. I just didn't 
> feel like there was enough understanding about it yet (and I still
don't).
>
> Mike
>