Kerberos sous Windows : klist, klist purge et setspn -L/-Q pour diagnostiquer les problèmes de SPN

Objectif

Inspecter et vider les tickets Kerberos mis en cache sur un client Windows, et diagnostiquer les problèmes de noms de principal de service (SPN) qui empêchent l'authentification Kerberos auprès d'un service, sous Windows Server 2016 et versions ultérieures / Windows 10 et versions ultérieures.

Prérequis

Une invite de commandes sur le client pour klist (aucune élévation n'est nécessaire pour votre propre session ; le cache du compte d'ordinateur, klist -li 0x3e7, requiert une invite avec élévation de privilèges) ; setspn, fourni par les outils RSAT/AD DS. L'interrogation des SPN (-L, -Q, -X) est possible pour tout utilisateur du domaine ; leur ajout ou leur suppression exige l'appartenance au groupe Domain Admins ou un droit d'écriture délégué sur l'attribut servicePrincipalName du compte.

Étapes

1. Lister les tickets en cache pour la session de connexion courante : klist. La commande affiche pour chaque ticket le principal de serveur, le principal client et la période de validité.
2. Vider le cache pour tester une nouvelle authentification (par exemple après une modification de groupe ou de SPN) : klist purge. Cette commande supprime tous les tickets en cache de la session courante, de sorte que la requête suivante force un nouvel échange avec le KDC.
3. Vérifier quels SPN existent pour un compte de service : setspn -L <accountname> liste tous les SPN actuellement enregistrés sur ce compte.
4. Vérifier qu'un SPN n'est pas déjà enregistré avant de l'ajouter : setspn -Q <SPN> ; setspn -X liste les SPN en double, et setspn -S <SPN> <account> n'ajoute un SPN qu'après avoir vérifié l'absence de doublon (Microsoft le recommande plutôt que -A).
5. Si un service ne reçoit pas de ticket Kerberos et se rabat sur NTLM, la première vérification consiste à exécuter setspn -Q HTTP/servername (ou la classe de service concernée) : si la requête ne renvoie aucun résultat, le SPN est manquant ; si elle renvoie un compte autre que celui qui exécute le service, il s'agit d'un conflit de SPN en double, que Kerberos traite comme une ambiguïté fatale au lieu d'en choisir un.

Résultat attendu

Une fois le bon SPN enregistré et le cache de tickets du client vidé avec klist purge, une nouvelle connexion au service fait apparaître dans la sortie de klist un ticket pour le SPN de ce service, et l'authentification auprès du service s'effectue via Kerberos au lieu de se rabattre sur NTLM.

Limites et base de vérification

setspn -Q et -X recherchent par défaut dans le domaine courant ; ajoutez -F pour interroger au niveau de la forêt. Un SPN présent sur le mauvais compte (reliquat d'un service renommé ou réinstallé) doit être supprimé avec setspn -D avant que setspn -S puisse l'ajouter au bon compte. Comme sous Linux, Kerberos sous Windows rejette aussi l'authentification lorsque les horloges du client et du contrôleur de domaine divergent au-delà du décalage maximal configuré pour le domaine (5 minutes par défaut dans la stratégie Kerberos d'AD) ; cela se manifeste par un échec d'authentification sans aucun symptôme lié aux SPN. Vérifiez donc la synchronisation de l'heure avant de passer du temps sur setspn.