The Samba-Bugzilla – Bug 359
NTLMv2 behaviour does not match windows
Last modified: 2005-08-24 10:15:53 UTC
Our current NTLMv2 behaviour is badly broken - the 'autodetection' does no such
thing, and in the default code paths, we fail to connect to a number of
In particular, we cannot connect to a system that is not running Win2k/Samba 3.0
that has a DC requiring NTLMv2. We also cannot contact a system running
Win2k/Samba 3.0 that has a DC that cannot understand NTLMv2.
There is *NO* correlation bettween extended security status and NTLMv2 support.
Win2k does not use this in determinating if it should use NTLMv2 - that is an
explict configuration option.
What may be negotiated are things like NTLMSSP, which has a number of
sub-protocol options, described in http://davenport.sf.net/ntlm.html that should
satisfy any 'require NTLMv2 session security' requirement that a DC may have,
without the need to explicty configure NTLMv2. (It uses what I can NTLM2,
after the flag that negotiates it, and is compatible with older PDCs).
Furthermore, the current 'client ntlmv2 = yes' disables share-level logins,
becouse the parameter's documented meaning is to disable LANMAN and Plaintext
authentication (which is what share-level security uses).
Also refer to the thread starting here:
Created attachment 126 [details]
Proposed fix, implements NTLM2, and key exchange.
* Domain joins from nt4sp6a/2ksp4/xpsp1
* Browsing to trusted servers and browsing
from trusted servers works ok.
* domain joins to mixed mode domain ok.
* winbind enumerates users/groups ok.
I think we're ready for RC3. Thanks Andrew.
originally reported against one of the 3.0.0rc[1-4] releases.
Cleaning up non-production versions.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.