Negotiation fails when server Requires NTLMv2 session security

[davejohnston]

Negotiate fails when servers have strict checking enabled using the registry key NtlmMinServerSec. The key can be found under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 If it is set to 0x00080000 or greater, the request will fail.

The issue appears to be that the negotiate header is not setting the relevant flag to indicate that this is supported.

https://www.ultimatewindowssecurity.com/wiki/page.aspx?spid=NSrpcservers Require NTLMv2 session security. If the value of either this entry or the NtlmMinClientSec entry is 0x80000, then the connection will fail unless NTLMv2 session security is negotiated

According to the spec (https://msdn.microsoft.com/en-us/library/cc236621.aspx) in 2.2.2.5 NEGOTIATE

P (1 bit): If set, requests usage of the NTLM v2 session security. NTLM v2 session security is a misnomer because it is not NTLM v2. It is NTLM v1 using the extended session security that is also in NTLM v2. NTLMSSP_NEGOTIATE_LM_KEY and NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY are mutually exclusive. If both NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY and NTLMSSP_NEGOTIATE_LM_KEY are requested, NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY alone MUST be returned to the client. NTLM v2 authentication session key generation MUST be supported by both the client and the DC in order to be used, and extended session security signing and sealing requires support from the client and the server in order to be used.<25> An alternate name for this field is NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY

[davejohnston]

The issue appears to be resolved by adding the negotiateFlagNTLMSSPNEGOTIATEEXTENDEDSESSIONSECURITY flag to the list of defaults: https://github.com/Azure/go-ntlmssp/blob/master/negotiate_message.go#L25

[davejohnston]

I raised this PR https://github.com/Azure/go-ntlmssp/pull/18

[davejohnston]

This has been addressed by https://github.com/Azure/go-ntlmssp/commit/4a21cbd618b459155f8b8ee7f4491cd54f5efa77