I'm using Samba joined to a domain with a MS Windows 2003 domain controller Samba is configured with security = domain. I'm not using winbind at all. Windows Vista's default security policy is "Send NTLMv2 response only". With that default setting I simply can not get Vista to connect to a security = domain Samba server. Windows XP is the exact same, Windows XP defaults to "Send LM & NTLM - use NTLMv2 session security if negotiated" but if I manually change it to Vista's default setting then XP just like Vista can not connect to Samba configured as security = domain. In both Windows XP and Vista the setting I'm referring to is manipulated by Start -> Run -> secpol.msc -> Local Policies -> Security Options -> Network Security: LAN Manager authentication level. I've tested against multiple 3.0.23d servers running Sparc/Solaris. I compiled 3.0.23d on Red Hat Enterprise ES Release 3 to make sure I wasn't looking at a Solaris problem and the exact same problem occurs under Linux as well. I've tested using a different domain controller in a different domain, same result.. NTLMV2 only - can't connect, change Windows so it can send LM & NTLM and then it immediately is able to connect. I've been doing a lot of testing of this issue this week, a couple interesting findings I've made are... 1) If I configure Samba with security = user and stick users in smbpasswd, then Vista/XP DO connect fine with their default setting of NTLMV2 only. 2) If I configure Samba with security = domain but limit it only to NTLMV2 by putting the entries lanman auth = no and ntlm auth = no into smb.conf.. Vista/XP still can't connect with the default setting of sending NTLMV2 only BUT THEY WILL CONNECT if I configure them with send LM & NTLM, NTLMV2 if negotiated.
I seem to have hit upon the solution, run winbindd. Don't even need to make any changes to my smb.conf at all, just run winbindd. Actually I do need to make one alteration in my [homes] section, having.. valid users = %S in [homes] prevents even the correct user from connecting. Oh well, I guess I can do without that.
Created attachment 2311 [details] example smbd and winbind logs
My solution of just running winbindd caused a new problem in that my "add user script" is never executed so I went back to the Samba mailings list. Volker Lendecke responed saying "Vista *should* work against us even without winbind." I gave him some more detail and he asked that I reopen this bug and submit "level 10 logs of the failing smbd, as well as debug level 10 logs of smbd and winbind when it succeeds." So, I've just uploaded the requested logs and am reopening the bug. The logs where created as follows: Here is the entire smb.conf that was used.. # Global parameters [global] workgroup = UMSL-USERS netbios name = STERCUS interfaces = 134.124.15.43/24 127.0.0.1 bind interfaces only = Yes encrypt passwords = Yes log level = 10 max log size = 75000 name resolve order = lmhosts wins bcast host preferred master = False wins server = 134.124.45.45 map archive = No security = DOMAIN password server = stl-dc21 stl-dc22 stl-dc23 [Homes] comment = Home Directories writeable = Yes browseable = No I began with no log files. I started smbd and nmbd. Using an installation of Windows Vista Enterprise, with all settings still at their defaults I went to a command prompt and issued the command net use * \\stercus\schaefert /user:umsl-users\schaefert mypassword I hit enter, the command failed giving the error message "The specified network password is not correct." I shutdown smbd and nmbd and renamed log.smbd log.smbd-winbindd-not-running-auth-fails which is in the attachment. I started winbindd, nmbd, and smbd. Still at the Vista command prompt, I hit the up arrow key to get back the exact same command, net use * \\stercus\schaefert /user:umsl-users\schaefert mypassword I hit enter, now it succeeded, mapped \\stercus\schaefert to z:. I stopped winbindd, nmbd, and smbd. I renamed log.smbd log.smbd-with-winbindd-running-auth-succeeds which is in the attachment. Also in the attachment are the logs that winbind created, log.wb-UMSL-USERS, log.winbindd, and log.winbindd-idmap. Please don't hesitate with any further requests, thankyou, Tom Schaefer
Just to give you some feedback: Got this reproduced. The critical piece is that you have to use the "net use /user:<someoneelse>". With the transparent login using the currently logged on user it does work even without winbind. Weird. Volker
Hi Volker, thank you for the update. When I first read your message stating that it only fails for <someoneelse> I was puzzled. Then I got to thinking, and investigating, yes, turns out you are exactly right, it only fails for <someoneelse>. I agree, "weird". We'd observed the behaviour you describe where the transparent login works if you are logged into Windows with the same domain\username you need for a samba share. But, we had completely misjudged why those cases where succeeding. We assumed the domain controllers had a policy which was over riding and lowering Vista's default security below "NTLMV2 only". But after reading your message this morning I went and investigated and no, the domain controllers don't modify that setting at all, its simply as you've discovered, if you are already using the same domain\username password as you need for the Samba server it does work even without winbind. But, if you need to manually specify a different domain\username password it fails unless winbind is running.
Created attachment 2314 [details] patch from volker to use the client domain name string in the samlogon request
The patch works!! Thank you so much Volker, greatly appreciated! (I'm not sure if I'm supposed to close this bug out myself or not so I'm leaving it open). Tom Schaefer University of Missouri Saint Louis
Fixed with r21642. Volker
*** Bug 4414 has been marked as a duplicate of this bug. ***
I finally put the patched smbd this into production this past Friday. (I'm only allowed the 2nd and 4th Friday evenings of the month to do stuff like this.) Everything seemed good for us Volkner on March 1 but the real world has proved otherwise. 2 problems have come up. 1) Prior to this patch users have always been able to connect regardless of the domain they sent with their username. Now they HAVE to specify the domain name (unless they are using a workstation that is a member of the domain then the correct domain name is sent automatically). In other words, my domain is umsl-users and my userid is schaefert. Prior to this patch I could connect with a userid of simply schaefert or even random-gibberish\schaefert and as long as I gave the correct password it would work. 2) So, one of my users had the above problem happen to him today, his workstation is not joined to the domain and he normally connects to a samba share by just specifying his username only. I guess Windows gave him examples of how to log in, one of them being username@dotted.domain.name. Enter problem number 2. Our dotted domain name is umsl.edu. Lets say his userid was joeblow. He tries to connect to a Samba share specifying joeblow@umsl.edu. Mind you he already has an account on the Samba server but he can't connect to it normally (not bothering to specify a domain) because of problem #1. Samba successfully authenticates him and passes the entire string joeblow@umsl.edu to my add user script via %u. So my add user script actually created him a second account named joeblow@umsl.edu. I mean in /etc/passwd there is an entirely new user now literally whos username is the entire string joeblow@umsl.edu. I've been doing testing of the above 2 problems a lot today since discovering these issues. They are completely reproducible. They don't occur if use a smbd that doesn't have the March 1 patch. Put a smbd in place which is identical except that is has the March 1 patch, problems 1 and 2 promptly appear.
Tom, the ntlmv2 bug is fixed. You other comments are different issues. Part (1) will most likely not be fixed as the current implementation is more correct and the previous behavior was hat I consider a bug. Part (2) should be filed as a separate bug I think.
I'll leave this closed, but I have a couple comments. Regarding #1) Bug or not, being able specify any domain was convenient, particularly for clients like Win98 which aren't even capable of specifying an alternate domain. Regarding #2) If I need to file it as a separate bug, I will, but to be sure you understand.. problem #2 does not exist if the patch for bug #4365 is not applied.
(In reply to comment #12) > I'll leave this closed, but I have a couple comments. > > Regarding #1) Bug or not, being able specify any domain was convenient, > particularly for clients like Win98 which aren't even capable of > specifying an alternate domain. I stand by the comment on this part. Maybe we can address this in the future, but not right now. > Regarding #2) If I need to file it as a separate bug, I will, but > to be sure you understand.. problem #2 does not exist if the > patch for bug #4365 is not applied. Please file another bug. Thanks.