Eu encontrei este Blog da Microsoft que me levou a usar o nome do host do servidor vs. CNAME.
Especificamente, os snippets abaixo:
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 KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.
E ...
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?
E ...
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.
Observação: Quando em um host do Windows Server 2008 eu pude executar o comando dir usando o CNAME com êxito.
SOLUÇÃO 1:
Use o nome do host em vez de CNAME.
Verifiquei se, em um host do Windows Server 2003, acessei o compartilhamento UNC com o nome do host (ou seja, \HOSTNAME\share ) em vez do CNAME (ou seja, \CNAME\share ), o acesso funcionaria bem.
Exemplo - WORKED:
dir \HOSTNAME\share
Exemplo - NÃO TRABALHOU:
dir \CNAME\share
Access is denied.
SOLUÇÃO 2:
Defina um SPN (nome principal de serviço) para o CNAME.
setspn -a HOST/CNAME SERVER
Depois de fazer isso, o dir \CNAME\share funcionou.
Veja também Como configurar Windows Machine para permitir o compartilhamento de arquivos com alias de DNS para obter mais informações.