Résoudre les problèmes de Kerberos et d’échecs d’authentification dans SQL Server avec des gMSA

S’applique à : SQL Server sur Windows

Résumé

Cet article vous aide à résoudre les échecs d’authentification Kerberos, de serveur lié et de groupe de disponibilité lorsque SQL Server s’exécute sous un compte de service administré de groupe (gMSA). Ces échecs ont les mêmes causes, que le compte de service soit un compte d’utilisateur gMSA ou un compte d’utilisateur de domaine. Pour un chemin de diagnostic complet, utilisez les références suivantes :

Utilisez les sections suivantes pour connaître les différences qui s’appliquent uniquement aux GMSA, telles que la propriété du nom de principal de service (SPN), la délégation et les autorisations de point de terminaison.

Avant de commencer, passez en revue les prérequis et exécutez la liste de contrôle de validation rapide dans Résoudre les problèmes d’installation, de démarrage et d’authentification de SQL Server avec des gMSA.

Échecs Kerberos ou SPN

Vérifier les SPN du compte gMSA

  • Répertoriez les SPN avec la forme de nom du compte d’ordinateur. Un gMSA est un objet de type ordinateur ; le nom du compte doit donc se terminer par le signe dollar.

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

  • Vérifiez que l’inscription automatique du SPN peut réussir. SQL Server enregistre son SPN au démarrage uniquement si le compte de service peut écrire dans son propre attribut servicePrincipalName. Si le compte gMSA n'a pas cette autorisation, le journal des erreurs SQL Server signale que le SPN n'a pas pu être inscrit et qu'un administrateur doit l'inscrire manuellement. Pour plus d’informations, consultez Inscrire un nom de principal de service pour les connexions Kerberos.

  • Revérifiez la propriété SPN après la modification d’un compte de service. Les SPN enregistrés sur l’ancien compte restent sur ce compte. Déplacez-les ou supprimez-les afin que le SPN attendu MSSQLSvc ait exactement un seul propriétaire : le gMSA sous lequel SQL Server s’exécute désormais.

Vérifier l’authentification Kerberos pour le gMSA

  1. Exécutez la commande suivante sur le client avant de retester.

    klist purge

  2. Reconnectez-vous à partir d’une session Windows distante authentifiée et exécutez la requête suivante.

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

    Résultat attendu : une nouvelle connexion à distance authentifiée par Windows signale KERBEROS.

Pour les SPN manquants, en double ou mal placés, ainsi que pour Kerberos Configuration Manager, consultez les références suivantes :

Échecs liés à un serveur lié ou à un double saut

Un serveur lié qui utilise le contexte de sécurité actuel échoue avec NT AUTHORITY\ANONYMOUS LOGON lorsque le second saut ne peut pas déléguer l’identité de l’utilisateur. Vous avez besoin de SPN corrects, mais ils n’activent pas à eux seuls la deuxième étape.

Vérifier la délégation du gMSA

  • Configurez la délégation contrainte sur l’objet gMSA en définissant msDS-AllowedToDelegateTo, ou en configurant la délégation contrainte en fonction des ressources sur la destination. La délégation configurée sur un compte d’utilisateur ne s’applique pas.
  • Si vous avez remplacé le compte de service d’un compte d’utilisateur de domaine par un compte gMSA, vérifiez que les paramètres de délégation ont été recréés sur le compte gMSA. La délégation n’est pas transférée avec le SPN.

Vérifiez le premier saut avant d’examiner la délégation.

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;

Résultat attendu : le premier saut indique KERBEROS.

Pour le parcours de diagnostic complet en double saut, consultez les références suivantes :

Échecs d’authentification du réplica du groupe de disponibilité

La connectivité des groupes de disponibilité dépend de l’état du point de terminaison, de l’URL et du port, du pare-feu, du DNS, CONNECT de l’autorisation et de l’authentification de compte de service. Validez ces éléments séparément de Kerberos client et utilisez la preuve SPN uniquement lorsque l’erreur indique spécifiquement Kerberos ou SSPI.

Vérifier les autorisations de point de terminaison pour gMSA

  • Accordez CONNECT sur le point de terminaison de mise en miroir de base de données au compte de connexion gMSA sous la forme [CONTOSO\SQLgMSA$] sur chaque réplique. Une connexion créée pour le compte de service précédent n’autorise pas le compte gMSA.
  • Si les réplicas fonctionnent sous des gMSA différents, vérifiez que chaque réplica dispose d’un identifiant de connexion et CONNECT d’une autorisation pour chaque compte de service partenaire.
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';

Résultat attendu : le point de terminaison est STARTED, le port est accessible et l’état du réplica passe à CONNECTED.

Pour le dépannage des problèmes de point de terminaison, de pare-feu et de connectivité qui ne sont pas spécifiques au compte de service, consultez Le réplica de disponibilité est déconnecté dans un groupe de disponibilité Always On et Résolution des problèmes de configuration des groupes de disponibilité Always On.

Collecter des données de diagnostic

Si l’authentification échoue toujours après avoir effectué ces étapes, collectez les données de diagnostic sur l’hôte SQL Server et de chaque réplica affecté sur la même période d’échec. Pour obtenir les données de preuve spécifiques à gMSA et les journaux d’activité de SQL Server standard à collecter, consultez Collecte des données de diagnostic dans la vue d’ensemble de la résolution des problèmes gMSA. Utilisez ces données pour poursuivre l’enquête ou ouvrir un cas de support.

Contenu connexe

  • Dernière mise à jour :