[cifs-protocol] domain logon limitations with Windows 10

[Björn JACKE]

Hello dochelp,

until Windows 8.1 it was possible to join and authenticate against NT4 style
domains, when the registry keys

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"DomainCompatibilityMode"=dword:00000001
"DNSNameResolutionRequired"=dword:00000000

had been applied. This was also working with the client site using the SMB2
protocol.

With Windows 10 also the following HardenedPaths registry key had to be set to
make a client connect to the netlogon share of a NT4-style DC:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths]
"\\\\*\\netlogon"="RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0"

A Windows 10 client will abort the logon process though, when the server
supports any SMB protocol better than SMB1. That means to make Windows 10
clients work in a NT4-style domain, SMB2/SMB3 has to be disabled.

A Windows 10 (1709 in my case) client can successfully JOIN a NT4-stlye domain,
which supports SMB1+SMB2/3. It does not matter if the client has SMB1Protocol
enabled or disabled.

But a Windows 10 client, which is joined to the NT4-style domain can not
AUTHENTICATE against the domain if the DC supports SMB2/3. In that case it does
not matter if the client machine has SMB1Protocol enabled or disabled. You find
a network capture of that test attached
(win10-logon-fail-client-smb2-only-server-all-prots.pcap).

If the DC ONLY supports SMB1 the Windows 10 client can successfully authenticate
the client against the DC. Of course this requires that the client does not
have SMB1Protocol disabled. You also find a network capture of that test
attached (win10-logon-success-client-smb1-enabled-server-smb1-only.pcap).

It's not obvious, why Windows 10 does not proceed domain logons when the
NT4-style DC supports SMB2 while previous Windows versions did that. You find a
network capture of a Windows 7 client authenticating with SMB2 again that
NT4-stlye DC attached (win7-logon-success-smb2.pcap). This is seems to be a
regression in Windows 10 from earlier Windows versions.

Question:

Is the Windows 10 client expecting anything differently in the SMB2 session setup
response from the DC or why is it aborting the longon precess after that
point?

This issue is affecting a lot of customers of mine and the workaround to leave
SMB1 enabled on the client site and on the DCs is not nice at all. So we'd be
happy to get the actual problem solved.

Best regards
Björn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win10-logon-fail-client-smb2-only-server-all-prots.pcap
Type: application/vnd.tcpdump.pcap
Size: 5982 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20180117/1c634693/win10-logon-fail-client-smb2-only-server-all-prots-0001.pcap>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win10-logon-success-client-smb1-enabled-server-smb1-only.pcap
Type: application/vnd.tcpdump.pcap
Size: 27064 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20180117/1c634693/win10-logon-success-client-smb1-enabled-server-smb1-only-0001.pcap>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win7-logon-success-smb2.pcap
Type: application/vnd.tcpdump.pcap
Size: 59983 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20180117/1c634693/win7-logon-success-smb2-0001.pcap>