La autenticación Kerberos no funciona con servidores vinculados en SQL Server 2012

8

Estoy configurando un entorno DEV / TEST utilizando 2 servidores SQL que ejecutan SQL Server 2012 en Windows Server 2012. Nos estamos moviendo de SQL Server 2005 en Windows Server 2008, donde ya tenemos esto funcionando correctamente.

En SQL Server 2012, la autenticación Kerberos no funciona.

Cada servidor tiene su propia cuenta de Active Directory que tiene los derechos "Escribir nombres principales de servicio" y "Leer nombres principales de servicio" otorgados a través de Usuarios y equipos de Active Directory. Cada vez que me conecto a los servidores de SQL Server 2005 y ejecuto:

SELECT net_transport, auth_scheme 
FROM sys.dm_exec_connections 
WHERE session_id = @@SPID;

Veo:

net_transport    auth_scheme
TCP              KERBEROS

Cuando realizo la misma consulta en mis nuevas instancias de SQL Server 2012, veo:

net_transport    auth_scheme
TCP              NTLM

Si uso SetSPN -Q MSSQLSvc/*para consultar Active Domain para los nombres principales del servicio, veo los servidores 2005 y 2012 en la lista, exactamente de la misma manera que no sea el nombre del servidor.

Por ejemplo:

MSSQLSvc/SERVERa2005.domain.inet
MSSQLSvc/SERVERa2005domain.inet:1433
MSSQLSvc/SERVERb2005.domain.inet
MSSQLSvc/SERVERb2005domain.inet:1433
MSSQLSvc/SERVERa2012.domain.inet
MSSQLSvc/SERVERa2012domain.inet:1433
MSSQLSvc/SERVERb2012.domain.inet
MSSQLSvc/SERVERb2012domain.inet:1433

¿Qué más debo hacer para habilitar la autenticación Kerberos en SQL Server 2012? Books Online parece no tener nada más que decir, excepto que los SPN deben configurarse. Que claramente lo son. Los registros de error de SQL Server en ambas máquinas 2012 dicen:

2012-12-10 14:55:47.630 The SQL Server Network Interface library 
                            successfully registered the Service Principal Name (SPN)
                            [ MSSQLSvc/SERVERa2012.domain.inet ] for the SQL Server
                            service. 

2012-12-10 14:55:47.630 The SQL Server Network Interface library 
                            successfully registered the Service Principal Name (SPN) 
                            [ MSSQLSvc/SERVERa2012.domain.inet:1433 ] for the SQL 
                            Server service. 

2012-12-10 14:55:47.590 SQL Server is attempting to register a Service 
                            Principal Name (SPN) for the SQL Server service. 
                            Kerberos authentication will not be possible until a 
                            SPN is registered for the SQL Server service. This is an
                            informational message. No user action is required.
sql-server sql-server-2012 linked-server kerberos Max Vernon
fuente
2
Mis fallas Kerberos favoritas son causadas por computadoras cuyos relojes se han alejado "demasiado". Asegúrese de que estén sincronizados con la hora oficial del dominio.
Darin estrecho
1
También asegúrese de que la zona horaria sea correcta.
Dave Markle

Respuestas:

8

Tratar con Active Directory siempre es muy divertido. Lo más importante aquí es darse cuenta de que está tratando con datos distribuidos que pueden tomar tiempo para propagarse a través de su red.

Se cambió el nombre de los servidores SQL en cuestión como parte de un procedimiento de actualización; reemplazamos una máquina existente (SQL01) que ejecuta SQL Server 2005 con una nueva máquina (SQL03) que ejecuta SQL Server 2012. SQL03 era el nombre de la nueva máquina cuando la configuré inicialmente en el dominio. SQL01 tenía un SPN existente asociado con una cuenta de dominio único que utilizamos para varios servidores SQL que se ejecutan en 2005. Dado que es una buena práctica ejecutar solo una máquina en una cuenta de dominio determinada, creé una cuenta nueva y configuré SQL03 para que se ejecute con ese nombre de la cuenta. Después de poner fuera de servicio el SQL01 original y cambiar el nombre de SQL03 a SQL01, hubo un conflicto de SPN.

Utilicé la utilidad SetSPN.exe para eliminar el SPN en conflicto (en la cuenta de dominio anterior), y todavía no funcionó. En este punto, no hice nada más y pasé a otros artículos. Cuando regresé unos 30 minutos después, la autenticación KERBEROS estaba funcionando. Simplemente necesitaba esperar a que el cambio de SPN se propagara entre nuestros controladores de dominio.

Utilicé SetSPN -L DOMAIN\Accounty comparé ese resultado con SetSPN -Q MSSQLSvc/Machine.domain.inet:1433para encontrar los SPN duplicados, y luego solía SetSPN -D MSSQLSvc/Machine.domain.inet:1433 DOMAIN\Accounteliminar los SPN antiguos.

Max Vernon
fuente