Solucionar problemas de Kerberos de SQL Server y errores de autenticación con gMSA

Se aplica a: SQL Server en Windows

Resumen

Este artículo le ayuda a solucionar errores en la autenticación de Kerberos, de servidores vinculados y de grupos de disponibilidad cuando SQL Server se ejecuta con una cuenta de servicio administrada de grupo (gMSA). Estos errores tienen las mismas causas si la cuenta de servicio es una gMSA o una cuenta de usuario de dominio. Para obtener una ruta de diagnóstico completa, use las siguientes referencias:

Utilice las siguientes secciones para las diferencias que solo se aplican a las gMSA, como la propiedad del nombre de entidad de seguridad de servicio (SPN), la delegación y los permisos de punto de conexión.

Antes de empezar, revise los requisitos previos y ejecute la lista rápida de comprobación para la validación en Solucionar problemas de instalación, inicio y autenticación de SQL Server con gMSA.

Errores de Kerberos o SPN

Comprobar los SPN de la gMSA

  • Enumere los SPN con el formato computer-account del nombre. Una gMSA es un objeto de clase equipo, por lo que el nombre de la cuenta debe llevar un signo de dólar al final.

    setspn -L CONTOSO\SQLgMSA$
setspn -Q MSSQLSvc/sql01.contoso.com:1433

  • Confirme que el registro automático de SPN puede realizarse correctamente. SQL Server registra su SPN al iniciarse solo si la cuenta de servicio puede escribir en su propio atributo servicePrincipalName. Si la gMSA no tiene ese permiso, el SQL Server registro de errores notifica que no se pudo registrar el SPN y un administrador debe registrarlo manualmente. Para obtener más información, consulte Registrar un nombre de entidad de servicio para las conexiones Kerberos.

  • Vuelva a comprobar la propiedad del SPN después de cambiar una cuenta de servicio. Los SPN registrados en la cuenta anterior permanecen en esa cuenta. Mueva o quítelos para que el SPN esperado MSSQLSvc tenga exactamente un propietario: la gMSA que ahora ejecuta SQL Server.

Comprobación de la autenticación Kerberos para la gMSA

  1. Ejecute el siguiente comando en el cliente antes de volver a probar.

    klist purge

  2. Vuelva a conectarse desde una sesión Windows autenticada remota y ejecute la consulta siguiente.

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

    Resultado esperado: una nueva conexión remota autenticada mediante Windows muestra KERBEROS.

Para los SPN ausentes, duplicados o mal ubicados, y para el Administrador de configuración de Kerberos, consulte las siguientes referencias:

Errores de servidor vinculado o errores de doble salto

Un servidor vinculado que usa el contexto de seguridad actual genera el error NT AUTHORITY\ANONYMOUS LOGON cuando el segundo salto no puede delegar la identidad del usuario. Necesitas los SPN adecuados, pero no habilitan el segundo salto por sí solos.

Comprobar la delegación de la gMSA

  • Configure la delegación restringida en el objeto gMSA estableciendo msDS-AllowedToDelegateToo configurando la delegación restringida basada en recursos en el destino. No se aplica la delegación configurada en una cuenta de usuario.
  • Si ha cambiado la cuenta de servicio de una cuenta de usuario de dominio a una gMSA, confirme que la configuración de delegación se ha vuelto a crear en la gMSA. La delegación no se transfiere con el SPN.

Compruebe el primer salto antes de investigar la delegación.

SELECT ORIGINAL_LOGIN() AS original_login, SUSER_SNAME() AS execution_login, c.auth_scheme
FROM sys.dm_exec_connections AS c
WHERE c.session_id = @@SPID;

Resultado esperado: el primer salto muestra KERBEROS.

Para obtener la ruta de diagnóstico de doble salto completa, consulte las referencias siguientes:

Errores de autenticación en la réplica del grupo de disponibilidad

La conectividad del grupo de disponibilidad depende del estado del extremo, de la dirección URL y del puerto, del firewall, del DNS, de los permisos de CONNECT y de la autenticación de la cuenta de servicio. Valide estos valores por separado del cliente Kerberos y use evidencia de SPN solo cuando el error indique específicamente Kerberos o SSPI.

Comprobación de los permisos de punto de conexión para la gMSA

  • Otorgue CONNECT en el extremo de creación de reflejo de la base de datos al inicio de sesión gMSA con el formato [CONTOSO\SQLgMSA$] en cada réplica. El inicio de sesión creado para la cuenta de servicio anterior no autoriza la gMSA.
  • Si las réplicas se ejecutan con distintas gMSA, asegúrese de que cada réplica dispone de un inicio de sesión y de CONNECT permisos para cada cuenta de servicio asociada.
SELECT ar.replica_server_name, ars.role_desc, ars.connected_state_desc, ars.synchronization_health_desc
FROM sys.availability_replicas AS ar
LEFT JOIN sys.dm_hadr_availability_replica_states AS ars ON ar.replica_id = ars.replica_id;

SELECT name, state_desc, type_desc, port
FROM sys.tcp_endpoints
WHERE type_desc = 'DATABASE_MIRRORING';

Resultado esperado: el punto de conexión es STARTED, el puerto es accesible y el estado de réplica progresa a CONNECTED.

Para solucionar problemas de extremo, firewall y conectividad que no estén relacionados específicamente con la cuenta de servicio, consulte La réplica de disponibilidad está desconectada dentro de un grupo de disponibilidad Always On y Solucionar problemas de configuración de grupos de disponibilidad Always On.

Recopilación de datos de diagnóstico

Si la autenticación sigue fallando después de completar estos pasos, recopile datos de diagnóstico del host de SQL Server y cada réplica afectada para el mismo intervalo de error. Para obtener la evidencia específica de gMSA y los registros de SQL Server estándar que se van a recopilar, consulte Recopilación de datos de diagnóstico en la introducción a la solución de problemas de gMSA. Use esos datos para continuar la investigación o para abrir un caso de soporte técnico.

Contenido relacionado

  • Se actualizó por última vez el