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):
- 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). - 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). - 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).
Best Answer
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 recordfiles.company.com
pointing toserver1.branch.company.com
, the\\files.company.com\sharename
would not be accessible, because clients would try to use Kerberos authentication with the old SPN (associatingfiles.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 ofsetspn -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).