Bug 4523 - with security = domain authenticating as user@domain doesn't work properly
with security = domain authenticating as user@domain doesn't work properly
Status: RESOLVED DUPLICATE of bug 4524
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.25
All All
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-18 14:30 UTC by Tom Schaefer
Modified: 2007-04-18 14:53 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Schaefer 2007-04-18 14:30:26 UTC
Using security = domain..

In Bug 4365 ( https://bugzilla.samba.org/show_bug.cgi?id=4365 ) I reported a problem with NTLMV2 authentication existing in Samba 3.0.24.  A patch to 3.0.24 was created which resolves the specific NTLMV2 problem but has created a new problem.  The 4365 bug patch is included in the 3.0.25rc2 distribution and I have verified first hand that 3.0.25rc2 suffers the same issue as 3.0.24 patched with 4365's patch.

Prior to compiling in that patch my clients could connect to Samba shares regardless of what domain the client sent. My users, even using notebooks not joined to our domain, could simply specify username and password.

Now the connection attempt fails if they only enter a username and password, they are now required to enter domain\username and password.  Or, what should work, and what some of them have been attempting is entering username@domain and password.

If a connection attempt is made of the form username@domain Samba is treating this as an entirely new user setting the value of %u to the entire string user@domain and calling my add user script.

Using myself as an example, domain umsl-users, userid schaefert.  In /etc/passwd there is an account for me schaefert, if I connect via samba specifying umsl-users\schaefert all is well.  If I attempt to connect by specifing schaefert@umsl.users in the Windows dialogue box Samba will set %u to schaefert@umsl.edu, call my add user script, and a new user will be created in /etc/passwd schaefert@umsl.edu.  To be clear, the newly created user will litterally be the entire string schaefert@umsl.edu.

I'm currently working around this by having my add user script check for @ symbols in the username and if so then not making a new account.

I went back and did some testing with 3.0.24 which has not had this patch applied.  In that case connection attempts of the form user@domain just altogether fail, add user script is never called.
Comment 1 Tom Schaefer 2007-04-18 14:53:13 UTC
Sheesh, I meant to add to this bug and accidentally recrated the entire thing as Bug 4524, I'll close this one.  My apologies.

*** This bug has been marked as a duplicate of 4524 ***