Bug 4524 - with security = domain authenticating as user@domain doesn't work properly
Summary: with security = domain authenticating as user@domain doesn't work properly
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.25
Hardware: All All
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
: 4523 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-04-18 14:35 UTC by Tom Schaefer
Modified: 2017-07-16 21:31 UTC (History)
1 user (show)

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:35:25 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:40:08 UTC
I'm sorry, I just got the email of this bug report and noticed I have some pretty severe typos.  The third to last paragraph, where I'm using myself as an example should have been written as this..

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-users, call my add user script, and a new user will be created in
/etc/passwd schaefert@umsl-users.  To be clear, the newly created user will
literally be the entire string schaefert@umsl-users.
Comment 2 Tom Schaefer 2007-04-18 14:53:13 UTC
*** Bug 4523 has been marked as a duplicate of this bug. ***
Comment 3 Tom Schaefer 2007-04-19 07:47:42 UTC
Previously I reported this problem exists in samba-3.0.25rc2, I meant samba-3.0.25pre2.

Also, I compiled samba-3.0.25rc1 today, same problem still exists.
Comment 4 Andrew Bartlett 2017-07-16 21:31:20 UTC
I think this was finally fixed (accidentally) by e8c76932e4ac192a00afa3b9731f5921c4b37da6 for Samba 4.2 when we moved to using the server-returned username as the canonical username for mapping and user creation. 

Some other fixes for 4.6 and 4.7 probably also helped in ensuring correct routing of username@domain logins, which are now much better supported.