Does Kerberos authentication handle DNS names the same way between Windows 7 and Windows 10?

Question

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 ?

Answer 1

What you're seeing is name canonicalization during the formation of the SPN. Kerberos requires clients to resolve names to the official record in an attempt to restrict hijacking/ticket theft and Windows enforces that.

Both Windows 7 and Windows 10 will do this by default, but it's possible to configure it to not do that through registry settings like DisableStrictNameChecking. However, that's pretty drastic and dangerous.

The recommended approach is to register the appropriate SPN cifs/filesvr1234.prod.company to the service account you're using for the NAS.