Aqui está uma situação que surgiu ontem: temos um compartilhamento em uma máquina que precisamos acessar usando um alias (CNAME). A máquina está executando o Windows Server 2012 R2 e atende clientes Windows 7 e 8.
Os clientes Windows 7 não têm problemas para abrir o compartilhamento \SHARECNAME ou \IP.AD.DR.ESS Os clientes Windows 8 só podem abrir o compartilhamento por \IP.AD.DR.ESS
O que funcionou eventualmente foi criar registros SPN para o CNAME apontar para o HOSTNAME (setspn -S HOST/CNAME HOSTNAME, etc.) e de repente o compartilhamento ficou utilizável.
A máquina HOSTNAME registrou um erro:
"O cliente Kerberos recebeu um erro KRB_AP_ERR_MODIFIED do servidor HOSTNAME$. O nome de destino usado foi cifs/CNAME." para o qual não encontrei muitas informações, mas me indicou a direção de definir os registros SPN adequados.
O que estou tentando entender é por que a diferença na experiência do cliente?
Obrigado.
Responder1
Não tenho certeza, mas você definiu a configuração de registro DisableStrictNameChecking?
http://www.md3v.com/enable-windows-server-smb-2-0-alias-cname
O IP vs CName junto com o SPN obviamente indica que o Kerberos está envolvido. Talvez seja a criptografia SMB 3.0 que está se mostrando. Isso ocorreria apenas em uma conexão Server2012 para Win8, mas essa é uma das principais diferenças entre SMB 2 e SMB 3. Não acredito que a criptografia nos compartilhamentos esteja habilitada por padrão, mas ao mudar para SMB 3, o protocolo pode exigir uma autenticação Kerberos.
Responder2
Tivemos um problema semelhante com um novo NetApp. Todos os clientes W10/2012 não conseguiram acessar o compartilhamento CNAME, mas os clientes W7/2008R2 conseguiram. Não tivemos que criar o CNAME SPN. O que fizemos foi remover todos os SPNs do CNAME que apareceram com setspn -l cname.
NOTA: Também tínhamos o CNAME como conta de computador AD e ele permaneceu lá depois.