I found this Microsoft Blog which got me looking at using the server's hostname vs. CNAME.
Specifically, the below snippets:
If you answered DNS name resolution you would be correct. If name
resolution is not working properly in the environment it will cause
the application requesting a Kerberos ticket to actually request a
Service ticket for the wrong service principal name. So if you
remember the remote file server I am attempting to connect to
“ltwre-chd-mem1.chd.litwareinc.com”, however the DNS Server found a
record for “ltwre-chd-mem1.litware.com”. Since we found the remote
file server in the “litwareinc.com” domain the Kerberos client
requests a service ticket for “cifs/ltwre-chd-mem1.litwareinc.com” as
noted in the Kerberos ticket request, and the KDC responds with
Actually, there are several different ways to “fix” the problem:
a. Find out why DNS is resolving the machine name incorrectly.
i. Is there a HOST or CNAME record for this name?
ii. Did you configure the DNS Zone for WINS lookup?
If you find that fixing the DNS problem is not possible, then the next
best solution would be to make the application use the FQDN of the
server. Keep in mind that the application vendor would need to be
involved to use this fix.
Note: When on a Windows Server 2008 host I could execute the dir command using the CNAME successfully.
Use hostname instead of CNAME.
I verified that if from a Windows Server 2003 host I accessed the UNC share with the hostname (i.e.
\\HOSTNAME\share) instead of the CNAME (i.e.
\\CNAME\share), the access would work fine.
Example - WORKED:
Example - DID NOT WORK:
Access is denied.
Set a SPN (service principal name) for the CNAME.
setspn -a HOST/CNAME SERVER
After doing this the
dir \\CNAME\share worked.
Also see How to Configure Windows Machine to Allow File Sharing with DNS Alias for more information.