Per 3.4.5.1, I'm expecting KeyExchangeKey to be '1C FB AD 6A 7B C6 66 5D A1 F2 97 5D DE 70 E2 D1'.ĩ. Per 3.3.1, I'm expecting SessionBaseKey to be MD4(NTOWF('Password')): 'D8 72 62 B0 CD E4 B1 CB 74 99 BE CC CD F1 7 84'.Ĩ. the issue can be recreated even if the server does not set NTLMSSP_NEGOTIATE_KEY_EXCH).ģ. The User name is 'User' and the password is 'Password', the AUTHENTICATE_MESSAGE's NTChallengeResponse field is as expected.Ģ. In the packet capture you should observe the following:ġ. Only when using Windows 8 / Windows 10, the issue occurs (MIC signature NOT as expected). My tests suggests that when the client is Windows 7 SP1 (under the same conditions), the MIC signature is as expected, instead, NTLMSSP_NEGOTIATE_LM_KEY is used. The client connects to an SMB server implementation that does not support NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY. 'Network security: LAN Manager authentication level' is set to 'Send LM & NTLM responses' (a.k.a. Freshly installed Windows 8.1 or Windows 10 v1607.Ģ. I'm able to repeatedly recreate this issue using the following configuration:ġ. I'm sending a packet capture session to dochelp at. During many tests of an SMB2 server implementation, I have noticed a (single) case where the MIC signature of an NTLM authentication exchange differs from what the MS-NLMP specifications suggests.
0 kommentar(er)
