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 different servers: 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: http://lists.samba.org/pipermail/samba/2003-August/102080.html
Created attachment 126 [details] Proposed fix, implements NTLM2, and key exchange.
patch applied. * Domain joins from nt4sp6a/2ksp4/xpsp1 all work. * 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.