Okay, folks. Here's where I am on security settings and their impact. The settings below are all based on NT4SP6, but similar stuff is (should be?) available for W2K and other Windows flavors.
1) MAC Signing: On the server: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters The parameter EnableSecuritySignature is used to enable and disable SMB MAC signatures. If enabled (set to one (1) instead of zero (0)), the server will sign SMB packets if the client wants to sign packets. The parameter RequireSecuritySignature is used to force SMB MAC signatures. The RequireSecuritySignature parameter has no effect unless EnableSecuritySignature is also enabled. If both are set to one (1), the server will require that the client use MAC signatures. On the client: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters Notice that the path is different (Rdr instead of LanManServer). Otherwise, this is all similar to the server, if EnableSecuritySignature is enabled then the client will perform MAC signing if the server supports or requires it. If both EnableSecuritySignature and RequireSecuritySignature are enabled, then the client must use MAC signing. The session will fail if the server does not have MAC signing enabled. (The client closes the TCP connection immediately after the server sends the NegProt Response with the SecurityMode field indicating that it doesn't support MAC signing.) There are docs which state that W/9x cannot do server-side MAC signing, but can do client-side. 2) Challenge/Response algorithm: The following KB articles are useful references: 147706, 239869. The registry variable HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\control\LSA\LMCompatibilityLevel is used to set the minimum challenge/response algorithm. On W/9x boxes the variable is LMCompatibility rather than LMCompatibilityLevel. (Why do they do things like that?) Anyway, this is an annoying variable because it does too much. There are six possible values, ranging from 0..5. They work like so: Client Domain Controller (or Server) ---------------------------------- --------------------------------- 0 Default. Client sends both LM Default. DC accepts LM, NTLM, and NTLM[v1] Response. LMv2, and NTLMv2 responses. 1 Discussion below. Discussion below. 2 Client sends the NTLMv1 response DC accepts LM, NTLM, LMv2, in both password fields (the same and NTLMv2 responses. value twice...I've seen it, it's real). 3 The Client places the 24-byte LMv2 According to the docs, at this response into the ANSI password setting the DC still accepts field, and the longer NTLMv2 LM, NTLM, LMv2, and NTLMv2. response into the Unicode password field. 4 The client sends both a 24-byte The DC does not compare any response (probably the LMv2) and response against the LM response the longer NTLMv2 response. NTLM, LMv2, and NTLMv2 are accepted. 5 Same as level 4. The DC does not compare against LM or NTLM. Only LMv2 and NTLMv2 are accepted. From the testing I've done, the above is pretty close to reality. The setting that bangs me on the head until my feet ache is LMCompatibilityLevel = 1. The docs say that this enables "NTLMv2 Session Security", but I can't find docs on that. Abartlet tells me that it's specific to NTLMSSP. My question, at this point, is: how do the client and server know to use NTLMSSP? Digging... Chris -)----- -- Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)----- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/ -)----- [EMAIL PROTECTED]