Rotation du mot de passe krbtgt : pourquoi deux fois, et comment le faire sans casse
Dans beaucoup de domaines, le mot de passe du compte krbtgt n'a pas changé depuis la création de la forêt. C'est pourtant la clé qui permet de forger un Golden Ticket. Sa rotation est simple à condition de respecter un ordre et des délais.
Le rôle du compte krbtgt
Le compte krbtgt est désactivé et ne sert jamais à ouvrir une session. Sa clé est utilisée par le KDC pour chiffrer et signer les tickets TGT. Un attaquant qui obtient cette clé, par exemple via DCSync ou une copie de NTDS.dit, peut fabriquer des TGT pour n'importe quel compte, avec n'importe quelle appartenance de groupe et une durée de validité arbitraire : c'est le Golden Ticket. Tant que la clé ne change pas, ces tickets restent valides, même si les comptes d'administration ont tous été réinitialisés.
Pourquoi deux réinitialisations
Le KDC conserve le mot de passe actuel et le précédent du compte krbtgt, afin que les tickets émis juste avant un changement restent utilisables. Une seule réinitialisation laisse donc l'ancienne clé valide. Il en faut deux pour invalider complètement une clé compromise.
Enchaîner les deux changements sans attendre est en revanche risqué : les TGT légitimes émis avec la clé d'origine deviennent invalides d'un coup, et un contrôleur qui n'a pas encore répliqué le premier changement se retrouve désynchronisé. Les symptômes sont des échecs d'authentification et d'accès aux ressources difficiles à diagnostiquer.
La procédure
- Vérifier la santé de la réplication sur tous les contrôleurs du domaine (
repadmin /replsummary). - Réinitialiser une première fois le mot de passe krbtgt.
- Attendre que le changement soit répliqué partout, puis au moins la durée de vie maximale d'un ticket utilisateur (dix heures par défaut, davantage si la stratégie Kerberos a été modifiée).
- Réinitialiser une seconde fois, puis vérifier à nouveau la réplication.
Microsoft publie un script PowerShell de réinitialisation, New-KrbtgtKeys.ps1, qui propose un mode de simulation, vérifie la réplication et cible un contrôleur précis. Il est préférable de l'utiliser plutôt que de réinitialiser le compte à la main dans la console. Le mot de passe lui-même est généré aléatoirement : personne n'a besoin de le connaître.
En cas de compromission avérée. Le calendrier change : il peut être justifié de réduire fortement l'attente entre les deux réinitialisations, en acceptant des perturbations temporaires. Cette décision relève de la gestion d'incident, pas de la maintenance courante.
Les comptes krbtgt des RODC
Chaque contrôleur en lecture seule dispose de son propre compte, nommé krbtgt_ suivi d'un numéro. Il signe les tickets émis par ce RODC. Ces comptes doivent être inclus dans la rotation, en particulier si un RODC situé sur un site distant a pu être compromis physiquement. Le script de Microsoft sait les traiter.
À quelle fréquence ?
Il n'existe pas de chiffre universel. Une rotation au moins annuelle est une pratique répandue ; de nombreuses organisations la font plus souvent, et certains référentiels signalent comme anomalie un mot de passe krbtgt trop ancien. Elle s'impose en tout cas :
- après toute suspicion de compromission du domaine ;
- après le départ d'un administrateur de niveau 0 ;
- après une restauration de forêt ;
- si le domaine a été élevé à un niveau fonctionnel 2008 ou supérieur sans rotation depuis, car le compte peut alors ne pas disposer de clés AES.
Ce qu'un audit vérifie
- La date du dernier changement (
pwdLastSet) du compte krbtgt et des comptes krbtgt des RODC. - L'existence d'une procédure documentée et testée.
- La santé de la réplication, préalable indispensable.