Created attachment 12207 [details] possible patch Samba V4.4.4 smbclient fails to connect to an Azure share. The visible error is "NTLMSSP packet check failed due to short signature (0 bytes)!" The last Session Setup response does not contain a mechListMIC and it looks similar to what is described in appendix C of RFC 4178 which predates use the MIC. The existing logic call gensec_check_packet() without the mecListMIC which then fails. I am attaching a patch that enables the connect to succeed. Someone that is familiar with this area should look it over closely as I am worried about the unprotected mechanism list. I will also pass this on to Microsoft in case they want to change something. Here are some wireshark extracts for comparison. Samba V4.4.4 smbclient to Azure - fails because mechListMIC is not present ==================================== Frame 912: 151 bytes on wire (1208 bits), 151 bytes captured (1208 bits) on interface 0 Ethernet II, Src: Force10N_d7:d4:8d (00:01:e8:d7:d4:8d), Dst: Vmware_31:13:9f (00:0c:29:31:13:9f) Internet Protocol Version 4, Src: xxxxx, Dst: yyyyy Transmission Control Protocol, Src Port: 445 (445), Dst Port: 58898 (58898), Seq: 474, Ack: 1125, Len: 85 NetBIOS Session Service SMB2 (Server Message Block Protocol version 2) SMB2 Header Session Setup Response (0x01) StructureSize: 0x0009 Session Flags: 0x0004 Security Blob: a1073005a0030a0100 Offset: 0x00000048 Length: 9 GSS-API Generic Security Service Application Program Interface Simple Protected Negotiation negTokenTarg negResult: accept-completed (0) Samba V4.4.4 smbclient to Windows 10 ==================================== Frame 717: 171 bytes on wire (1368 bits), 171 bytes captured (1368 bits) on interface 0 Ethernet II, Src: Force10N_d7:d4:8d (00:01:e8:d7:d4:8d), Dst: Vmware_31:13:9f (00:0c:29:31:13:9f) Internet Protocol Version 4, Src: xxxxx, Dst: yyyyy Transmission Control Protocol, Src Port: 445 (445), Dst Port: 38782 (38782), Seq: 888, Ack: 1183, Len: 105 NetBIOS Session Service SMB2 (Server Message Block Protocol version 2) SMB2 Header Session Setup Response (0x01) StructureSize: 0x0009 Session Flags: 0x0000 Security Blob: a11b3019a0030a0100a312041001000000656f85723255b5... Offset: 0x00000048 Length: 29 GSS-API Generic Security Service Application Program Interface Simple Protected Negotiation negTokenTarg negResult: accept-completed (0) mechListMIC: 01000000656f85723255b52600000000 Windows 10 to Azure ==================================== There is no Security Blob in the response (length 0) Frame 71873: 130 bytes on wire (1040 bits), 130 bytes captured (1040 bits) on interface 0 Ethernet II, Src: Force10N_d7:d4:8d (00:01:e8:d7:d4:8d), Dst: Vmware_a2:7e:7b (00:50:56:a2:7e:7b) Internet Protocol Version 4, Src: xxxxx 6, Dst: yyyyy Transmission Control Protocol, Src Port: 445 (445), Dst Port: 49581 (49581), Seq: 445, Ack: 982, Len: 76 NetBIOS Session Service SMB2 (Server Message Block Protocol version 2) SMB2 Header Session Setup Response (0x01) StructureSize: 0x0009 Session Flags: 0x0004 Security Blob: <MISSING>: NO DATA Offset: 0x00000048 Length: 0
We need a wireshark captures of the whole sessions My first guess is that Microsoft needs to fix azure.
This is a bug I already ran into at the Microsoft plugfest interop event. I asked them to fix their server (which they are planning on doing).
FYI - I don't want to remove the mechListMic check as this protects us against a mitm attack (for which we needed to raise a CVE) when this code is used under LDAP.
Created attachment 12421 [details] git-am fix for master. Proposed fix for master.
So is it also expected that if winbindd talks to Azure AD, and falls back to NTLM for some reason, it will also fail without this fix?
Azure doesn't do AD at the moment - it only exposes a fileserver using NTLM over port 445.
Created attachment 12425 [details] git-am fix for 4.5.0, 4.4.next, 4.3.next. Cherry-picked from master.
Pushed to autobuild-v4-5-test.
Pushed to v4-5-test.
Pushed to autobuild-v4-{3,4}-test.
Pushed to all branches. Closing out bug report. Thanks!