Bug 4365 - NTLMV2 not functioning when Samba is configured as security = domain
Summary: NTLMV2 not functioning when Samba is configured as security = domain
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.23d
Hardware: All Solaris
: P1 normal
Target Milestone: 3.0.25
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
: 4414 (view as bug list)
Depends on:
Reported: 2007-02-02 09:16 UTC by Tom Schaefer
Modified: 2013-02-18 13:29 UTC (History)
3 users (show)

See Also:

example smbd and winbind logs (113.64 KB, application/octet-stream)
2007-02-27 11:26 UTC, Tom Schaefer
no flags Details
patch from volker to use the client domain name string in the samlogon request (739 bytes, patch)
2007-03-01 07:58 UTC, Gerald (Jerry) Carter (dead mail address)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Schaefer 2007-02-02 09:16:26 UTC
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.
Comment 1 Tom Schaefer 2007-02-02 14:54:58 UTC
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.
Comment 2 Tom Schaefer 2007-02-27 11:26:57 UTC
Created attachment 2311 [details]
example smbd and winbind logs
Comment 3 Tom Schaefer 2007-02-27 11:50:44 UTC
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
        workgroup = UMSL-USERS
        netbios name = STERCUS
        interfaces =
        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 =
        map archive = No
        security = DOMAIN
        password server = stl-dc21 stl-dc22 stl-dc23

        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
Comment 4 Volker Lendecke 2007-02-28 04:23:17 UTC
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.

Comment 5 Tom Schaefer 2007-02-28 11:57:59 UTC
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.
Comment 6 Gerald (Jerry) Carter (dead mail address) 2007-03-01 07:58:16 UTC
Created attachment 2314 [details]
patch from volker to use the client domain name string in the samlogon request
Comment 7 Tom Schaefer 2007-03-01 15:30:52 UTC
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
Comment 8 Volker Lendecke 2007-03-01 16:13:37 UTC
Fixed with r21642.

Comment 9 Bartlomiej Solarz-Niesluchowski 2007-03-09 02:27:24 UTC
*** Bug 4414 has been marked as a duplicate of this bug. ***
Comment 10 Tom Schaefer 2007-03-26 21:47:20 UTC
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.

Comment 11 Gerald (Jerry) Carter (dead mail address) 2007-04-05 08:07:53 UTC
Tom, the ntlmv2 bug is fixed.  You other comments are different 

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.
Comment 12 Tom Schaefer 2007-04-05 08:33:53 UTC
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. 
Comment 13 Gerald (Jerry) Carter (dead mail address) 2007-04-05 08:46:13 UTC
(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.