[jcifs] username dialog syntax changes
Michael B Allen
mba2000 at ioplex.com
Tue Mar 28 18:43:15 GMT 2006
Note, there was a bug in 1.2.7 and prior that prevented preauthentication
from working with the jcifs.http.domainController property. This has been
fixed. I would suggest you try the second "Explicit Domain Controller"
example in the updated NTLM HTTP Authentication documentation with
On Tue, 28 Mar 2006 12:49:09 -0500
"John Engilis" <JohnE at vacationsonly.com> wrote:
> Hey Rich,
> This was very helpful for me. I've been having difficulty authenticating
> to a Windows 2003 Domain Controller for the past 2 weeks.
> I've attempted to specify the domain, wins server and domain controller
> as well as do pre-authentication. The domain and wins alone would give
> me an unknown host error. I surmised that it may have been an issue
> with our network. But I have yet to locate any problems. Attempting to
> specify the full domain name and not the NT domain resulted in the same
> error, but the full domain name was being truncated (it's 17 characters
> counting the .com; I believe the last character or 2 were being cut
> off). Since the domain was not resolving, the username and password for
> pre-authentication was not working.
> I've been using version 1.1.11 because it was actually allowing users to
> connect to our Intranet. The first user could get in without an error.
> Most subsequent users would get an error message (invalid signature or
> something to that effect) the first time, but could then get in after
> refreshing. The later version of jcifs (1.2.7) caused the
> authentication dialog box to pop up and even when correct credentials
> were entered it would not authenticate and allow users to see our
> Intranet (using NT domain or the full domain name). Setting the
> jcifs.smb.client.ssnLimit to 1 as mentioned at jcifs.samba.org made it
> worse locking it up or again producing the dialog box that wouldn't
> authenticate (depending on the version of jcifs).
> Referencing your email, I eliminated the jcifs.smb.client.domain and
> changed the username to user at domain.com. With that simple change I was
> able to do pre-authenticating and have each user connect every time
> without fail.
> John Engilis
> Project Coordinator / Programmer
> john.engilis at vacationsonly.com
> -----Original Message-----
> From: jcifs-bounces+johne=vacationsonly.com at lists.samba.org
> [mailto:jcifs-bounces+johne=vacationsonly.com at lists.samba.org] On Behalf
> Of Richard Caper
> Sent: Monday, March 27, 2006 3: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
> > Mike
More information about the jcifs