Aquí hay una situación que surgió ayer: tenemos un recurso compartido en una máquina a la que tenemos que acceder usando un alias (CNAME). La máquina ejecuta Windows Server 2012 R2 y da servicio a clientes de Windows 7 y 8.
Los clientes de Windows 7 no tienen problemas para abrir el recurso compartido \SHARECNAME o \IP.AD.DR.ESS Los clientes de Windows 8 solo pueden abrir el recurso compartido mediante \IP.AD.DR.ESS
Lo que finalmente funcionó fue crear registros SPN para que CNAME apunte a HOSTNAME (setspn -S HOST/CNAME HOSTNAME, etc.) y, de repente, el recurso compartido se pudo utilizar.
La máquina HOSTNAME registró un error:
"El cliente Kerberos recibió un error KRB_AP_ERR_MODIFIED del servidor HOSTNAME$. El nombre de destino utilizado fue cifs/CNAME". para lo cual no encontré mucha información, pero me indicó cómo configurar los registros SPN adecuados.
Lo que estoy tratando de entender es ¿por qué la diferencia en la experiencia del cliente?
Gracias.
Respuesta1
No estoy exactamente seguro, pero ¿estableció la configuración de registro DisableStrictNameChecking?
http://www.md3v.com/enable-windows-server-smb-2-0-alias-cname
La IP frente al CName junto con el SPN obviamente indica que Kerberos está involucrado. Quizás sea el cifrado SMB 3.0 el que se muestra. Esto solo sería en una conexión de Server2012 a Win8, pero esa es una de las principales diferencias entre SMB 2 y SMB 3. No creo que el cifrado en los recursos compartidos esté habilitado de forma predeterminada, pero al pasar a SMB 3, el protocolo podría requerir una autenticación Kerberos.
Respuesta2
Tuvimos un problema similar con una nueva NetApp. Todos los clientes de W10/2012 no pudieron acceder al recurso compartido CNAME, pero los clientes de W7/2008R2 sí pudieron hacerlo. No tuvimos que crear el CNAME SPN. Lo que hicimos fue eliminar todos los SPN del CNAME que aparecían con setspn -l cname.
NOTA: También teníamos el CNAME como cuenta de computadora AD y permaneció allí después.