Partager via

Conseils de résolution des problèmes liés à l’authentification Kerberos

Ce guide fournit des concepts fondamentaux à suivre lorsque vous résolvez les problèmes d’authentification Kerberos.

Important

Cet article fournit des conseils généraux. Vous devrez peut-être adapter les procédures et exemples présentés ici pour fonctionner pour votre configuration spécifique.

Liste de contrôle pour la résolution des problèmes

Le protocole Kerberos s’appuie sur plusieurs composants et services d’infrastructure. Si l’un de ces composants ou services n’est pas disponible ou ne fonctionne pas, vous pouvez rencontrer des problèmes d’authentification.

1. Vérifier les événements et les journaux

Vérifiez les journaux des événements pour obtenir des indications d’un problème. Utilisez l’Observateur d’événements pour passer en revue les journaux de sécurité et système sur les systèmes impliqués dans l’opération d’authentification :

  • Le client d’authentification
  • Serveur ou service cible
  • Contrôleur de domaine

En particulier, recherchez les événements provenant de sources susceptibles d’être liés à l’authentification Kerberos ou aux services sur lesquels il s’appuie, comme les sources suivantes :

  • Kerberos
  • Centre de distribution de clés (KDC)
  • LSA (LsaSrv)
  • Netlogon

Sur le serveur cible, consultez le journal de sécurité pour les audits d’échec. Ces échecs peuvent indiquer que le protocole Kerberos est utilisé lorsqu’une défaillance d’authentification se produit.

Certains événements ou erreurs indiquent des problèmes spécifiques. Si l’un des ordinateurs concernés a enregistré l’un des événements ou erreurs suivants, sélectionnez le lien pour obtenir des informations de dépannage plus détaillées.

Événement ou erreur Résolution de problèmes
ID d’événement 4, erreur KERB_AP_ERR_MODIFIED Le client n’a pas pu déchiffrer le ticket de service. Étant donné que plusieurs problèmes peuvent provoquer cette erreur, recherchez les événements associés. Par exemple, cette chaîne peut signifier que les horloges client et serveur cible ne sont pas synchronisées, ou que le SPN n’est pas unique. Dans un environnement multi-domaine, le nom du compte de service peut ne pas être unique dans la forêt (ou d’autres forêts approuvées).
Pour plus d’informations, consultez le client Kerberos a reçu une erreur KRB_AP_ERR_MODIFIED du serveur et une erreur KDC_ERR_S_PRINCIPAL_UNKNOWN ou une erreur KDC_ERR_PRINCIPAL_NOT_UNIQUE générée par Kerberos.
ID d’événement 4, Erreur KERB_AP_ERR_SKEW Vérifiez que les horloges de l’ordinateur sont synchronisées
ID d’événement 14 Erreur « Etype non pris en charge » lors de l’accès à une ressource dans un domaine approuvé
ID d’événement 16 ou ID d’événement 27 L’ID d’événement KDC 16 ou 27 est enregistré si DES pour Kerberos est désactivé
Erreurs d'ID d'événement 27 KDC sur les contrôleurs de domaine Windows Server 2003
Erreur 1069 Les connexions au service échouent en raison de noms principaux de service (SPN) incorrectement configurés
ID d’événement 5719, erreur 1311 ou erreur 1355 ID d’événement 5719, Erreur 1311 ou Erreur 1355 - Contrôleur de domaine ou domaine introuvable

Si vous vérifiez un problème que vous savez résoudre, commencez par résoudre ce problème, puis réessayez de vous authentifier avant de continuer.

2. Vérifier l’infrastructure

a) Assurez-vous que l’application cliente et le service cible ne se trouve pas sur le même ordinateur

Par défaut, si l’application cliente et le service cible sont installés sur un seul ordinateur, Kerberos est désactivé. Si vous ne pouvez pas installer l’application cliente et le service cible sur des ordinateurs distincts, vous devez modifier des paramètres de sécurité spécifiques dans Windows. En outre, vous devrez peut-être modifier une clé de Registre. Pour plus d’informations sur les problèmes liés à ce scénario et les paramètres spécifiques qui l’affectent, consultez message d’erreur lorsque vous essayez d’accéder à un serveur localement.

Si vous avez apporté des modifications, réessayez de vous authentifier avant de continuer.

b. Vérifiez que l’ordinateur client, le serveur cible et les serveurs de ressources sont joints aux domaines appropriés

Si nécessaire, joignez l’ordinateur client ou le serveur cible à un domaine approprié. Ensuite, réessayez de vous authentifier.

Remarque

Dans ce contexte, les « domaines appropriés » sont des domaines au sein d’une forêt unique ou dans un ensemble de forêts qui ont des relations d’approbation.

v. Vérifier l’intégrité du serveur cible et de ses services de prise en charge

Assurez-vous que les services d’application ou frontaux (tels que les services web) et les services principaux (tels que le service SQL Server) sont en cours d’exécution.

Remarque

Vous pouvez recevoir un message semblable à celui de « Un service a généré l’erreur 1069 : le service n’a pas démarré en raison d’un échec d’ouverture de session de service ». Si vous recevez ce message, consultez Les ouvertures de session de service échouent en raison d’un paramètre SPN incorrect.

d. Vérifiez que les ports appropriés sont disponibles

Vérifiez tous les pare-feu (y compris le Pare-feu Windows sur chaque ordinateur) entre l’ordinateur client, le contrôleur de domaine et le serveur cible. Vérifiez que le trafic est autorisé sur les ports suivants.

Remarque

Cette liste utilise le format serveur:port client, port serveur.

  • DHCP : 67 (UDP), 67 (UDP)
  • DNS : 49152 -65535 (TCP, UDP), 53 (TCP, UDP)
  • HTTPS, y compris l’authentification basée sur un certificat : 443 (TCP), 443 (TCP)
  • Kerberos : 49152 -65535 (TCP, UDP), 88 (TCP, UDP)
  • Modification du mot de passe Kerberos : 49152 -65535 (TCP), 464 (TCP, UDP)
  • LDAP, y compris le localisateur DC : 49152 -65535 (TCP, UDP), 389 (TCP, UDP)
  • LDAP SSL : 49152 -65535 (TCP), 636 (TCP)
  • SMB : 49152 -65535 (TCP, UDP), 445 (TCP)
  • Mappeur de point de terminaison RPC : 49152 -65535 (TCP), 135 (TCP)
  • RPC pour LSA, SAM, NetLogon : 49152 -65535 (TCP), 49152-65535 (TCP)
  • W32Time : 49152 -65535 (UDP), 123 (UDP)

Si vous apportez des modifications à des paramètres de pare-feu, réessayez de vous authentifier.

é. Vérifier que les contrôleurs de domaine sont disponibles

Lorsque le client tente de contacter un service ou une application (appelé « serveur cible »), le client et le serveur cible nécessitent un contrôleur de domaine pour faciliter l’authentification, l’autorisation et la délégation.

Sur l’ordinateur client, ouvrez une fenêtre d’invite de commandes avec des privilèges élevés, puis exécutez la commande suivante :

nltest /dsgetdc:<DomainName> /force /kdc

Remarque

Dans cette commande, <DomainName> représente le nom du domaine de l’ordinateur à partir duquel vous interrogez.

La nltest commande récupère une liste de contrôleurs de domaine disponibles (bien que la liste n’inclue pas tous les contrôleurs de domaine disponibles). Enregistrez les noms de domaine complets et les adresses IP de ces contrôleurs de domaine à utiliser dans les procédures ultérieures.

Si le client ou le serveur cible ne peut pas contacter un contrôleur de domaine, vous recevez un message semblable à ce qui suit (parfois étiqueté « erreur 1355 ») :

Le domaine spécifié n’existe pas ou n’a pas pu être contacté.

Si vous recevez ce message, consultez l’ID d’événement 5719, l’erreur 1311 ou l’erreur 1355 - Contrôleur de domaine ou domaine introuvable pour plus d’informations de dépannage. Sinon, passez par cette liste de contrôle.

f. Vérifier que DNS fonctionne entre le client et le serveur cible

Sur l’ordinateur client, ouvrez une fenêtre d'invite de commandes avec privilèges d'administrateur, puis exécutez la commande suivante :

nslookup <TargetName>

Remarque

Dans cette commande, <TargetName> représente le nom NetBIOS du serveur cible.

Si la nslookup commande résout correctement le nom du serveur cible, la configuration DNS est correcte. Si la commande ne résout pas le nom du serveur cible, procédez comme suit pour vérifier la configuration de la carte réseau de l’ordinateur client :

  1. Sur l’ordinateur client, exécutez la commande suivante :

    ipconfig /all

  2. Dans la sortie de commande, déterminez la carte réseau en cours d’utilisation. Vérifiez les paramètres d’adaptateur suivants :

    • Adresse IP du client

    • Masque de sous-réseau

    • Passerelle par défaut

    • Suffixe DNS spécifique à la connexion

    • Adresses IP des serveurs DNS

      Enregistrez les adresses IP et notez quel serveur DNS est préféré et qui est secondaire. Ces informations sont utiles pour résoudre les problèmes ultérieurs.

    Si l’un de ces paramètres est incorrect, corrigez-les ou contactez votre administrateur DNS pour obtenir de l’aide. Si vous avez apporté des modifications, réexécutez-les nslookup <TargetName> .

Si DNS ne fonctionne toujours pas correctement, procédez comme suit :

  1. Exécutez la commande suivante sur l’ordinateur client :

    nslookup <ClientName> <DNSIPAddress>

    Remarque

    Dans cette commande, <ClientName> représente le nom NetBIOS de l’ordinateur client, et <DNSIPAddress> représente l’adresse IP de l’un des serveurs DNS que le client est configuré pour l’utiliser. Tout d’abord, utilisez l’adresse IP du serveur DNS préféré que vous avez enregistré dans la procédure précédente. Si la commande ne fonctionne pas, réessayez à l’aide de l’adresse IP du serveur DNS secondaire du client.

    Par exemple, si le nom de l’ordinateur client est « client1 » et que l’adresse IP du serveur DNS préféré du client est 10.0.0.1, exécutez la commande suivante :

    nslookup client1 10.0.0.1

  2. Exécutez la même commande à partir du serveur cible. Elle ressemble maintenant à la commande suivante :

    nslookup <TargetName> <DNSIPAddress>

    Remarque

    Dans cette commande, <TargetName> représente le nom NetBIOS du serveur cible, et <DNSIPAddress> représente l’adresse IP de l’un des serveurs DNS que le serveur cible est configuré pour l’utiliser. Tout d’abord, utilisez l’adresse IP du serveur DNS préféré que vous avez enregistré dans la procédure précédente. Si la commande ne fonctionne pas la première fois que vous l’exécutez, réessayez à l’aide de l’adresse IP du serveur dns secondaire du serveur cible.

    Par exemple, si le nom du serveur cible est « WebServer1 » et que l’adresse IP du serveur cible est 10.0.0.0.1, exécutez la commande suivante :

    nslookup WebServer1 10.0.0.1

    Le tableau suivant récapitule les résultats possibles des nslookup requêtes et leurs implications.

    Requête cible
    Réussit    		 Requête cible
    Échoue
    Requête du client
    Réussit    		 Aucun problème DNS Problème qui affecte la cible ou au moins un serveur DNS
    Requête du client
    Échoue    		 Problème qui affecte le client ou au moins un serveur DNS Problème qui affecte un ou plusieurs serveurs DNS

Si les résultats de la requête indiquent que vous rencontrez un problème DNS, consultez les articles suivants pour obtenir de l’aide supplémentaire :

Si vous résolvez le problème DNS mais que le problème Kerberos reste, essayez les méthodes de résolution des problèmes suivantes.

g. Vérifiez que les horloges de l’ordinateur sont synchronisées

L’ordinateur client ou le serveur cible peut mettre en cache des tickets pour une utilisation ultérieure. Toutefois, chaque ticket a des horodatages qui déterminent son temps de vie (TTL). Le service Centre de distribution de clés Kerberos, qui s’exécute sur les contrôleurs de domaine, définit les horodatages.

La différence de temps entre le contrôleur de domaine et l’ordinateur client ou le serveur cible doit être inférieure à cinq minutes. En règle générale, si les horloges ne sont pas synchronisées, Windows peut les resynchroniser automatiquement. Il existe deux cas dans lesquels vous devrez peut-être prendre des mesures :

  • Les horloges ont un décalage de plus de 48 heures.
  • L’horloge hors synchronisation n’utilise pas de contrôleur de domaine dans son domaine comme serveur de temps ou n’utilise pas le même serveur de temps que ces contrôleurs de domaine.

Pour résoudre ce problème, l’ordinateur concerné doit revérifier le réseau pour les serveurs de temps, puis resynchroniser son propre horloge. Pour activer ces actions, ouvrez une fenêtre d’invite de commandes d’administration, puis exécutez la commande suivante :

w32tm /resync /computer:<Target> /rediscover

Remarque

Dans cette commande, <Target> représente l’ordinateur que vous configurez. L’option /rediscover indique à l’ordinateur de vérifier le réseau pour des sources de temps nouvelles ou mises à jour.

Pour plus d’informations sur les options disponibles pour la commande, consultez les w32tm.

Si vous resynchronisez les horloges, réessayez de vous authentifier.

h. Vérifier l’état de Windows Update

Assurez-vous que tous les contrôleurs de domaine, l’ordinateur client et le serveur cible ont tous des mises à jour Windows pertinentes.

Si vous avez installé des mises à jour, redémarrez les ordinateurs concernés, puis réessayez de vous authentifier.

i. Vérifier l’état de la mise à jour de l’application

Assurez-vous que les applications client et serveur sont à jour sur l’ordinateur client et le serveur cible. Si vous installez des mises à jour, redémarrez les ordinateurs concernés, puis réessayez de vous authentifier.

j. Redémarrer les ordinateurs

Si vous n’avez pas déjà redémarré l’ordinateur client, le serveur cible ou le contrôleur de domaine, redémarrez-les maintenant. Une fois les ordinateurs redémarrés, réessayez de s’authentifier.

Si votre infrastructure est correcte et que vous rencontrez toujours un problème, passez aux procédures de résolution des problèmes plus avancées.

3. Collecter les données de trace et de ticket

Les procédures suivantes utilisent l’outil Moniteur réseau gratuit. Téléchargez et installez l’outil sur l’ordinateur client et le serveur cible. Pour obtenir un exemple d’utilisation du Moniteur réseau pour collecter des données de trace et identifier des messages Kerberos, consultez les erreurs Kerberos dans les captures réseau.

a) Collecter des traces réseau simultanées

Sur l’ordinateur client, procédez comme suit :

  1. Effectuez l’une des actions suivantes :

    • Redémarrez l'ordinateur client.
    • Déconnectez-vous du compte que vous utilisez pour résoudre les problèmes, puis reconnectez-vous.
    • Fermez l’application cliente, puis rouvrez-la.

  2. Démarrez le traçage. Pour ce faire, procédez comme suit :

    1. Sélectionnez Démarrer, puis tapez netmon.
    2. Dans les résultats de la recherche, cliquez avec le bouton droit sur Microsoft Network Monitor 3.4, puis sélectionnez Exécuter en tant qu’administrateur (sélectionnez Oui dans la fenêtre Contrôle de compte d’utilisateur).
    3. Dans Moniteur réseau, sélectionnez Démarrer.

  3. Ouvrez une fenêtre d’invite de commandes d’administration, puis exécutez les commandes suivantes, en suivant ces étapes :

    ipconfig /flushdns
nbtstat -RR
klist purge
klist -li 0x3e7 purge

Sur le serveur cible, procédez comme suit :

  1. Ouvrez Moniteur réseau en tant qu’administrateur, puis sélectionnez Démarrer.

  2. Ouvrez une fenêtre d’invite de commandes d’administration, puis exécutez les commandes suivantes, en suivant ces étapes :

    ipconfig /flushdns
nbtstat -RR
klist purge
klist -li 0x3e7 purge

Essayez de reproduire votre problème, puis arrêtez et enregistrez les traces sur l’ordinateur client et le serveur cible. Pour ce faire, dans Moniteur réseau, sélectionnez Arrêter, puis sélectionnez Enregistrer sous.

b. Enregistrer les informations de ticket

Après avoir reproduit votre problème et arrêté le suivi, vérifiez les tickets Kerberos générés pendant l’enregistrement des données de trace. À l’invite de commandes sur l’ordinateur client et sur le serveur cible, exécutez la commande suivante :

klist tickets

Cette commande génère une liste de tickets. Vous pouvez copier ces informations dans une autre application (par exemple, le Bloc-notes) afin de pouvoir l’utiliser dans les procédures de résolution des problèmes ultérieures.

4. Vérifiez les données de trace pour les messages Kerberos

Vous pouvez utiliser le moniteur réseau pour passer en revue, filtrer et rechercher des données dans les fichiers de capture. En particulier, recherchez les événements étiquetés à l’aide de « KerberosV5 ». Ces événements fournissent des informations d’état. Ils peuvent également répertorier les noms ou adresses IP des contrôleurs de domaine qui ont été contactés et le nom du principal de service (SPN) du service que le client a tenté d’atteindre.

Les descriptions d’événements qui contiennent des chaînes qui ressemblent à ce qui suit font partie des fonctions Kerberos classiques :

  • KerberosV5 :KRB_Error -KDC_ERR_PREAUTH_REQUIRED
  • KerberosV5 : Demande de SA
  • Réponse KerberosV5 :AS
  • KerberosV5 : Requête TGS
  • Réponse KerberosV5 :TGS
  • KerberosV5 :AP Request
  • KerberosV5 :AP Response

Remarque

Vous pouvez également utiliser Network Monitor pour examiner les données de suivi pour les informations sur les tickets dans les requêtes HTTP GET. Si les informations de ticket sont manquantes dans la requête GET, un problème s’est produit lors de l’utilisation de l’authentification Kerberos.

Les descriptions d’événements qui contiennent des chaînes qui ressemblent à la suivante signifient qu’il existe un problème. La liste suivante inclut certaines des erreurs les plus courantes. Si vous voyez l'une de ces chaînes, notez les noms de serveur, les adresses IP et les SPNs pour une utilisation ultérieure.

  • KDC_ERR_PRINCIPAL_NOT_UNIQUE ou KDC_ERR_S_PRINCIPAL_UNKNOWN. Le SPN demandé est associé à plusieurs comptes ou n’est associé à aucun compte. Pour obtenir de l’aide sur la résolution de l’un de ces problèmes, consultez l’erreur KDC_ERR_S_PRINCIPAL_UNKNOWN ou KDC_ERR_PRINCIPAL_NOT_UNIQUE générée par Kerberos.

  • KRB_AP_ERR_MODIFIED. Le client n’a pas pu déchiffrer le ticket de service. Plusieurs problèmes peuvent provoquer cette erreur. Passez en revue les données de trace pour d’autres erreurs qui accompagnent KRB_AP_ERR_MODIFIED. Vérifiez les journaux des événements pour l’ID d’événement 4 et d’autres événements connexes, comme décrit dans 1. Vérifiez les événements et les journaux.

  • ERB_AP_ERR_SKEW. Les horloges client et serveur cible ne sont pas synchronisées. Pour plus d’informations, consultez Vérifier que les horloges de l’ordinateur sont synchronisées.

  • KDC_ERR_ETYPE_NOTSUPP. Un ou plusieurs composants impliqués dans l’authentification utilisent un type de chiffrement désactivé pour d’autres composants. Consultez les journaux des événements pour plus d’informations sur les composants et les types de chiffrement impliqués, comme décrit dans 1. Vérifiez les événements et les journaux.

Problèmes courants et solutions

Problème HTTP 400 - Requête incorrecte (en-tête de requête trop long)

Si un utilisateur appartient à un grand nombre de groupes (par exemple, plus de 1 000 groupes), Kerberos peut refuser l’accès utilisateur, car il ne traite pas correctement la demande. Pour plus d’informations sur ce problème, consultez les articles suivants :

Problèmes liés aux services

Les problèmes de service impliquent généralement le SPN et le compte de service. Par exemple, le SPN peut être incorrect, manquant, configuré sur le compte incorrect ou configuré sur plusieurs comptes. Liste de contrôle de dépannage de cet article a. Collectez les traces réseau simultanées plus haut dans cet article. Si vous avez déjà déterminé un problème de SPN courant, consultez les articles suivants :

Problèmes d’authentification unique

L’authentification unique est une méthode d’authentification qui permet aux utilisateurs de se connecter à l’aide d’un ensemble d’informations d’identification pour plusieurs systèmes ou applications au sein d’un seul intranet. Pour fonctionner correctement, le service cible (ou le composant frontal du service cible) et le client doivent avoir les paramètres appropriés. Pour plus d’informations sur la résolution de ces paramètres, consultez Résolution des problèmes d’authentification unique Kerberos.

Problèmes de délégation

Lorsque votre service cible dispose de composants frontaux et principaux distincts, Kerberos peut déléguer des informations d’identification client (y compris des autorisations d’accès) à un compte de service. En termes simples, le client accède au service frontal, puis le service frontal accède au service principal au nom du client.

Kerberos prend en charge trois types de délégation :

  • Délégation non contrainte. Une fois que le client a accès au service frontal, le service frontal peut accéder à n’importe quel autre service au nom du client. Cette configuration est la plus simple à implémenter, mais elle est également la moins sécurisée. Nous ne recommandons pas la délégation non contrainte, car elle ne limite pas les services avec lesquels le compte authentifié peut interagir.
  • Délégation contrainte. Le service frontal gère une liste de services auxquels il peut accéder au nom d’un client.
  • Délégation contrainte basée sur les ressources (RBCD). Le service back-end gère une liste verte de services frontaux qui peuvent demander l’accès au service principal pour le compte d’un client.

Remarque

Si vous rencontrez un problème lorsque vous utilisez une délégation contrainte avec CIFS, consultez la délégation contrainte pour CIFS échoue avec l'erreur ACCESS_DENIED.

Important

  • Ne configurez pas la délégation contrainte et RBCD sur le même ensemble de serveurs frontaux et principaux.

    La délégation contrainte et RBCD sont des configurations différentes, et elles s’excluent mutuellement. Lorsqu’un service frontal demande un ticket à un service d'arrière-plan, le KDC vérifie d’abord le service frontal pour la délégation contrainte. Si la délégation contrainte n’est pas configurée pour le service frontal, le KDC vérifie le service de back-end pour la délégation contrainte basée sur les ressources. En raison de cette séquence, la délégation contrainte est prioritaire sur la délégation basée sur les ressources.

  • Par défaut, Microsoft Edge ne prend pas en charge la délégation non contrainte. Si vous utilisez une délégation non restreinte, consultez l’authentification Kerberos à deux sauts sans contrainte avec Microsoft Edge (Chromium) pour plus d’informations sur la configuration requise.

  • La délégation non contrainte n’est pas recommandée, car elle ne limite pas les services avec lesquels le compte authentifié peut interagir.

Types de topologie pris en charge

Les différents types de délégations ont des exigences différentes sur votre topologie. Le tableau suivant répertorie trois types courants de topologie et quels types de délégation (le cas échéant) sont pris en charge pour chaque type.

Type de topologie Délégation sans contrainte Délégation contrainte RBCD
Tous les services résident dans un seul domaine Pris en charge (non recommandé) Soutenu Soutenu
Les services frontaux et principaux résident dans différents domaines Pris en charge (non recommandé) Non prise en charge Soutenu
Les services front-end et back-end résident dans différentes forêts de confiance. Pris en charge* (non recommandé) Non prise en charge Supporté*

* Assurez-vous que le compte de service du service frontal peut s'authentifier à travers la relation de confiance avec le contrôleur de domaine de confiance.

Résolution des problèmes liés aux types de délégation spécifiques

Les détails de configuration de la délégation diffèrent selon le type de délégation que vous utilisez et le type de compte utilisé par le service frontal. Pour résoudre les problèmes de délégation plus loin, consultez les articles suivants, le cas échéant :

Utilisation d’un scénario de test d’analyse des journaux pour résoudre les problèmes d’authentification Kerberos

Pour les tests et la résolution des problèmes Kerberos avancés, consultez Utiliser un scénario de test d’analyse des journaux pour résoudre les problèmes d’authentification Kerberos.

  • Last updated on