The Samba-Bugzilla – Bug 4523
with security = domain authenticating as user@domain doesn't work properly
Last modified: 2007-04-18 14:53:13 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 email@example.com in the Windows dialogue box Samba will set %u to firstname.lastname@example.org, call my add user script, and a new user will be created in /etc/passwd email@example.com. To be clear, the newly created user will litterally be the entire string firstname.lastname@example.org.
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.
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 ***