Accessing Windows file server by alias name

Question

What could be the possible problems with accessing a Windows file server shares using a DNS CNAME instead of the actual computer name? The file server is joined to an Active Directory domain, but is not a Domain Controller.

E.g. let's assume there is a file server with computer name SERVER1 joined to Active Directory domain branch.company.com. And there is a DNS CNAME record files.company.com that points to server1.branch.company.com. What could be the potential problems when connecting to \\files.company.com\sharename ?

Things currently known to me (but no yet verified):

1. Need to add the alias name to HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SrvAllowedServerNames REG_MULTI_SZ registry value, if the "Microsoft network server: Server SPN target name validation level" Group Policy setting is not Off (HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SmbServerNameHardeningLevel registry value if not 0).
2. Need to add the alias name to HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\BackConnectionHostNames REG_MULTI_SZ registry value (for the connections to the alias name from the server itself to work).
3. SPN might need to be added in Active Directory using a command like setspn -A host/files.company.com SERVER1 (I am not sure whether/when this is needed and whether authentication will be downgraded from Kerberos to NTLM without this).

Answer 1

Looks like the 3 things mentioned in the OP/question were the important ones.

Some more info about the Kerberos SPN (point 3.):

3.1. Looks like if no SPN exists accessing the file share will still work (at least in many cases/configurations), but will fall back to using NTLM authentication.

3.2. If there exists another SPN that associates the alias name with another AD (computer) account, then the alias name will not be accessible.

I.e. If in the OP example the files.company.com would have been the name of an old & decommissioned file server and AD computer account (with default SPNs) of that file server would still exist, then despite of DNS CNAME record files.company.com pointing to server1.branch.company.com, the \\files.company.com\sharename would not be accessible, because clients would try to use Kerberos authentication with the old SPN (associating files.company.com with the decommissioned file server's AD account) and fail.

3.3. For creating SPNs setspn -S host/files.company.com SERVER1 should be used instead of setspn -A host/files.company.com SERVER1, because -S checks that no duplicate SPN exists (on current and future versions of Windows -A option likely either works as -S option or is removed altogether).

Answer 2

Well one possible problem may be multiple DNS servers in your environment, and that the current client, will get the dns information from the correct server.
Windows client settings