Changer le mot de passe du compte krbtgt sans casser le domaine

Le compte krbtgt porte la clé de toute l'authentification Kerberos du domaine. Le réinitialiser est une mesure d'hygiène et de réponse à incident, à condition de suivre l'ordre et les délais que fixe Microsoft.

Par la rédaction de Pixelabs · 12 octobre 2026

Chaque domaine Active Directory possède un compte nommé krbtgt. Il ne peut pas être activé, mais son mot de passe protège tous les tickets Kerberos du domaine. Le changer touche d'un coup tous les utilisateurs et tous les ordinateurs : l'opération se prépare.

Le risque : une clé qui ne change jamais

Microsoft décrit krbtgt comme le compte de service du Centre de distribution de clés (KDC). Son mot de passe sert à créer la clé secrète qui chiffre et déchiffre les tickets d'octroi de tickets (TGT) ; c'est grâce à elle que n'importe quel contrôleur de domaine peut valider un TGT émis par un autre. La documentation le résume ainsi : le mot de passe krbtgt est la clé sur laquelle repose toute la confiance dans Kerberos.

Un mot de passe fort lui est attribué automatiquement, puis rien ne le change. Microsoft recommande de le modifier régulièrement, comme celui de tout compte de service privilégié, et de le réinitialiser lors d'une récupération de forêt. En cas de compromission soupçonnée du domaine, Microsoft conseille de faire appel à des services professionnels de réponse à incident : la réinitialisation fait alors partie d'un effort de reprise plus large.

Qui est concerné

Tout domaine Active Directory, quelle que soit la version de Windows Server. Deux cas particuliers :

Sur Windows Server 2025, Microsoft indique par ailleurs que le KDC n'émet plus de TGT chiffrés en RC4.

Vérifier d'abord

La réinitialisation doit se répliquer à tous les contrôleurs. Une réplication en panne au moment de l'opération, et certains contrôleurs refuseront les tickets des autres. Contrôlez donc la santé du domaine avec dcdiag et repadmin, détaillés dans la page sur les outils de dépannage Active Directory.

Notez ensuite la date du dernier changement de mot de passe, portée par l'attribut pwdLastSet :

Get-ADUser -Identity krbtgt -Properties pwdLastSet

Microsoft documente cet attribut comme la date et l'heure du dernier changement, stockées en nombre d'intervalles de 100 nanosecondes depuis le 1er janvier 1601 (UTC). Une date proche de la création du domaine signifie que la clé n'a jamais été renouvelée.

Il faut être membre du groupe Admins du domaine, ou avoir reçu la délégation correspondante. Testez la procédure dans un domaine de lab, et vérifiez que vous disposez d'une sauvegarde récente de l'état système des contrôleurs avant d'agir en production.

La procédure de Microsoft

Elle s'applique aux contrôleurs de domaine accessibles en écriture.

1. Ouvrez Utilisateurs et ordinateurs Active Directory.
2. Menu Affichage, cochez Fonctionnalités avancées.
3. Dans le conteneur du domaine, sélectionnez Utilisateurs.
4. Clic droit sur le compte krbtgt, puis Réinitialiser le mot de passe.
5. Saisissez un mot de passe et confirmez. Microsoft précise que la valeur saisie importe peu : le système génère de lui-même un mot de passe fort.

Ne faites pas les deux réinitialisations à la suite : Microsoft impose un délai entre elles.

Pourquoi deux fois, et pourquoi attendre

L'historique de mot de passe du compte krbtgt vaut 2 : il conserve les deux derniers mots de passe. Une seule réinitialisation laisse donc l'ancien en mémoire ; la seconde l'efface définitivement.

Entre les deux, Microsoft demande d'attendre 10 heures, soit la durée de vie maximale par défaut d'un ticket utilisateur et d'un ticket de service. Si votre stratégie Kerberos fixe une durée de vie plus longue, l'attente doit dépasser la valeur configurée. Vérifiez entre-temps que la première réinitialisation s'est répliquée partout.

Vérifier après chaque réinitialisation

Microsoft demande de contrôler que l'ID d'événement 9 de la source Key-Distribution-Center (Kerberos) a bien été écrit dans le journal Système. Pour automatiser ces contrôles, la page sur l'écriture de scripts PowerShell donne la structure d'un script fiable.

Impact et retour arrière

Microsoft compare l'opération au renouvellement de la clé d'une autorité de certification racine, avec arrêt immédiat de la confiance dans l'ancienne. Les effets documentés :

• les TGT déjà émis ne sont plus valides une fois l'ancienne clé sortie de l'historique ;
• les sessions déjà ouvertes sur une ressource restent valides jusqu'à ce qu'un nouveau ticket de service soit nécessaire ;
• les connexions authentifiées en NTLM ne sont pas affectées ;
• il faut supposer que tous les ordinateurs et tous les utilisateurs peuvent être touchés.

Le redémarrage d'un ordinateur est, selon Microsoft, le seul moyen fiable de rétablir ses fonctions, car il force une nouvelle ouverture de session et de nouveaux TGT. Il n'y a pas de retour arrière : un mot de passe réinitialisé ne se restaure pas, d'où le contrôle préalable et la fenêtre de maintenance.

D'autres mesures de durcissement du domaine accompagnent souvent celle-ci, comme la désactivation de SMBv1. Les autres procédures sont dans la rubrique Windows Server.

Questions fréquentes