Recently, we migrated from Windows 7 to Windows 10 and during that migration, we progressively ran into some issues with our NAS device. To be more precise, we progressively noticed some tcp socket flooding on it while client computers were upgraded to Windows 10. We suspect that our NAS has some difficulties with NTLM, but this is out of this question scope.
Our NAS has a FQDN : filesvr1234.prod.company
We also have a DNS alias pointing to that FQDN : prodfiles.company
Kerberos authentication is enabled on filesvr1234.prod.company, but not on the alias prodfiles.company because we have some legacy apps that need NTLM.
We investigated on those issues by running WireShark while trying to read a file from a samba share on our NAS \prodfiles.company\shared\test.txt.
We observed the following behaviour. Both Windows 7 and Windows 10 try first to authenticate using Kerberos.
Windows 10 will try authenticate using the alias prodfiles.company (which is the expected behaviour because we access the share with \prodfiles.company\shared\test.txt). It will use NTLM. However, we noticed that Windows 7 uses the FQDN (filesvr1234.prod.company) instead of the DNS alias, even if we access the share using the alias (\prodfiles.company\shared\test.txt). It will use Kerberos.
To see this, we looked at "SNameString" in KRB5 packets (Wireshark). To summarize : We read a file in \prodfiles.company\shared\test.txt Windows 7 use filesvr1234.prod.company even if we access the share using prodfiles.company. Windows 10 use prodfiles.company
Does something changed between Windows 7 and Windows 10 that makes the authentication process to use the DNS alias instead of the FQDN ?