From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041109 Firefox/1.0 Description of problem: Whenever the client sends only an "Unicode" ("NT"/"Case sensitive") password, the Samba server will not be able to authenticate against a password server in an NT domain. One such client is the CIFS kernel module, which doesn't send the less secure LanMan/ANSI/CaseSensitive password on purpose - some of the code is in the source, but commented out. You can reproduce the same behaviour with smbclient, by adding "client lanman auth = no" to smb.conf. Looking at network traffic, I see that whenever the client system sends both passwords, the Samba server will successfully forward the request to the password server. In the case of the smbfs module, both passwords are identical binary strings of 24 bytes each. If only the "Unicode" password gets sent, though, then Samba will proceed to forward a request to the NT authentication server with the right user and domain, but with the length of both passwords set to zero. Is it maybe just copying the "ANSI" password? Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. set up Samba server in security = server mode 2. mount share with cifs (or smbfs with "client lanman auth = no") Actual Results: Samba server tries to authenticate the user with an empty password Expected Results: Samba server should trie to authenticate using the password it was given and thus succeed. Additional info: I would have classified this as Severity: high, but it's not exactly a case of "crashes, lots of data, severe memory leak".
Have you reported this upstream at bugzilla.samba.org ? Please do, as the Samba team is likely better at debugging this than I. Incidentally, why are you using "security = server" in the first place. Page 36 of the Official Samba-3 HOWTO and Reference Guide says "It is highly recommended not to use his feature.", and I can only agree with that statement.
It turns out this is most likely a bug in cifs. And I was wrong, I couldn't reproduce it with smbclient - there was an error mounting the share, but for unrelated reasons. The cifs module only sends the Unicode/CaseSensitive/NTLM response, on the principle that the LM response encryption is very easy to crack. It turns out that that's not exactly the way to avoid sending an LM response. On an XP system, setting LMCompatibilityLevel to 2 (meaning "no LM response is sent") results in the LM response being set to the same value as the NTLM response. In other words, it's ugly, but smbd is still "right" when expecting a non-null LM response. I'm changing the component. Please reassign to the appropriate developer if Bugzilla doesn't do it automatically. I have no idea who that would be. More details, with a patch: http://lists.samba.org/archive/linux-cifs-client/2004-November/000523.html http://lists.samba.org/archive/linux-cifs-client/2004-December/000526.html http://lists.samba.org/archive/linux-cifs-client/2004-December/000530.html
Heh, that was a mid-air collision. I already talked to Tridge and Steve French about it. Tridge suggested waiting for Andrew Bartlett to return from vacation. Looking at XP's behaviour, it looks like this is a scenario that is not supposed to happen in the first place. I would still feel uncomfortable with leaving it unhandled - no warnings whatsoever! I suppose this should be fixed in cifsfs first, though. As to using "security = server", there are cases in which it's difficult to join a domain. Think of bureaucracy.
The cifs.ko part of the bug should be fixed in 2.6.10. There is no mention of it in the (huge) CIFS 2.6.10 changelog, but, if you look at connect.c, you should now see the response being sent in both fields. I guess the resolution of this bug depends on the release of a 2.6.10 kernel update, if there's going to be such a thing. According to a few Samba developers, smbd is guilty as well. It shouldn't fail miserably like that when it receives a request with only one password field set. I tried against a W2K server and it handled such a request without problems. Andrew Bartlett said he'll look into rewriting the code at fault.