Renouveler le mot de passe krbtgt sans risque dans AD

Les clés du compte krbtgt chiffrent et signent chaque TGT du domaine. Quiconque les détient peut forger un golden ticket pour n'importe quelle identité, avec n'importe quelles appartenances à des groupes, tant que la clé reste valide. Dans de nombreux domaines, cette clé n'a pas changé depuis la création du domaine : chaque compromission passée, chaque ancienne sauvegarde et chaque DCSync effectué par un prestataire parti depuis longtemps produit encore des tickets valides. Le renouvellement régulier du krbtgt est le seul contrôle qui fait expirer cette exposition.

La procédure elle-même se résume à deux réinitialisations de mot de passe. Ce qui la rend sûre, c'est tout ce qui l'entoure : comprendre l'historique des clés, confirmer la réplication, gérer les comptes des RODC et choisir entre mode routine et mode incident. Ce guide développe la section sur la double réinitialisation de Durcissement de Kerberos.

Pourquoi deux réinitialisations, et pourquoi l'intervalle compte

Lorsque krbtgt est réinitialisé, le DC conserve la clé précédente à côté de la nouvelle. Un TGT chiffré avec l'une ou l'autre est accepté. C'est ce qui évite une interruption : les tickets émis une minute avant la réinitialisation restent valides.

• Après la réinitialisation 1 : clé actuelle = K1, clé précédente = K0. Les golden tickets forgés avec K0 fonctionnent encore.
• Après la réinitialisation 2 : clé actuelle = K2, clé précédente = K1. K0 a disparu, donc les tickets forgés avec la clé d'origine sont rejetés.

Si la réinitialisation 2 intervient trop tôt, les TGT légitimes émis avec K0 juste avant la réinitialisation 1 sont eux aussi rejetés. Les utilisateurs subissent des échecs d'authentification jusqu'à ce qu'ils verrouillent et déverrouillent leur session ou se reconnectent, et les services dotés de sessions longues peuvent tomber en échec. L'intervalle sûr correspond à la durée de vie maximale d'un TGT plus la tolérance de décalage d'horloge, une fois la réplication convergée.

# Lire la stratégie Kerberos dans la Default Domain Policy
$gpo = Get-GPO -Name 'Default Domain Policy'
$report = [xml](Get-GPOReport -Guid $gpo.Id -ReportType Xml)
$report.GPO.Computer.ExtensionData.Extension.Account |
    Where-Object { $_.Type -eq 'Kerberos' } |
    Select-Object Name, SettingNumber

Si la requête ne renvoie rien, la stratégie n'est pas définie explicitement et les valeurs par défaut s'appliquent. MaxTicketAge (en heures, 10 par défaut) est la durée de vie du TGT, MaxRenewAge (en jours, 7 par défaut) la fenêtre de renouvellement et MaxClockSkew (en minutes, 5 par défaut) la tolérance. Les demandes de renouvellement sont validées avec la clé actuelle ou la clé précédente : un TGT émis sous K0 ne peut donc de toute façon plus être renouvelé après la réinitialisation 2.

Mesurer : l'état actuel

# Comptes krbtgt de chaque domaine de la forêt, y compris les comptes krbtgt_ des RODC
(Get-ADForest).Domains | ForEach-Object {
    Get-ADUser -Server $_ -Filter 'SamAccountName -like "krbtgt*"' `
        -Properties PasswordLastSet, msDS-KeyVersionNumber |
        Select-Object @{n='Domain';e={$_.DistinguishedName -replace '^.*?,DC=','DC='}},
                      SamAccountName, PasswordLastSet, msDS-KeyVersionNumber
}

Lors de la première exécution, un PasswordLastSet qui se compte en années est la norme. Chaque domaine possède son propre krbtgt ; une forêt multidomaine nécessite un renouvellement dans chaque domaine. Chaque RODC possède un compte krbtgt_NNNNN, lié à l'objet ordinateur du RODC via msDS-KrbTgtLink :

Get-ADComputer -Filter 'PrimaryGroupID -eq 521' -Properties msDS-KrbTgtLink |
    Select-Object Name, msDS-KrbTgtLink

Auditer : la santé de la réplication d'abord

Une réinitialisation qui n'a pas atteint tous les DC accessibles en écriture est dangereuse. Un DC qui a manqué la réinitialisation 1 continue d'émettre des TGT avec K0, et si la réinitialisation 2 est ensuite répliquée avant que la réinitialisation 1 n'ait convergé, les DC se retrouvent avec des historiques de clés différents et rejettent mutuellement leurs tickets. Ne commencez jamais un renouvellement tant que la réplication échoue.

# Synthèse de la réplication à l'échelle de la forêt : chaque colonne « fails » doit être à 0
repadmin /replsummary

# Échecs par DC
Get-ADReplicationFailure -Target (Get-ADDomain).DNSRoot -Scope Domain |
    Select-Object Server, Partner, FailureCount, LastError

Corrigez toutes les erreurs, confirmez que tous les DC sont joignables et assurez-vous de disposer d'une sauvegarde récente et testée de l'état système d'au moins un DC par domaine avant la première réinitialisation.

Planifier le changement

Le premier renouvellement dans un domaine dont le krbtgt n'a pas changé depuis des années mérite une vraie demande de changement, même si la commande elle-même ne prend que quelques secondes.

Inventorier ce qui dépend de tickets à longue durée de vie. Interrogez les responsables d'applications sur les services qui s'authentifient une fois et conservent une session Kerberos pendant des jours : hôtes Linux utilisant des keytabs avec des tickets renouvelables, serveurs d'applications dotés de clients Kerberos spécifiques, traitements batch de longue durée. Ce sont les systèmes qui remarqueront la réinitialisation 2.

Choisir la fenêtre. La réinitialisation 1 est invisible pour les utilisateurs si la réplication est saine. C'est la réinitialisation 2 qui peut faire apparaître des problèmes : planifiez-la en début de journée de travail, en présence des équipes de support, et non la nuit, quand personne ne remarquera une intégration cassée avant le matin.

Ordre dans une forêt multidomaine. Les renouvellements dans les différents domaines sont indépendants, car le krbtgt de chaque domaine ne signe que les TGT de ce domaine ; les tickets inter-royaumes à travers les approbations utilisent plutôt les clés des comptes d'approbation. Commencez par un petit domaine enfant pour la répétition, puis la racine de la forêt, puis les domaines restants. Ne les enchaînez pas tous dans la même fenêtre.

RODC. En mode routine, renouvelez les comptes krbtgt_NNNNN des RODC après le compte du domaine, un RODC à la fois, en confirmant que le RODC et ses partenaires de réplication accessibles en écriture s'accordent sur la nouvelle version de clé avant de passer au suivant. C'est dans les agences reliées par des liens lents que les contrôles de convergence vous sauvent.

Preuves. Consignez les valeurs msDS-KeyVersionNumber et PasswordLastSet avant et après pour chaque compte. Auditeurs et intervenants en réponse à incident demanderont quand la clé a changé pour la dernière fois, et la réponse doit être un document, pas une supposition.

Imposer : renouvellement de routine avec New-KrbtgtKeys.ps1

Utilisez New-KrbtgtKeys.ps1, publié à l'origine par Microsoft et désormais maintenu par la communauté sur GitHub, plutôt que des appels Set-ADAccountPassword improvisés. Le script propose un mode informatif, un mode simulation qui exerce la procédure sur des comptes krbtgt de test qu'il crée, et un mode de réinitialisation réelle. En mode réel, il réinitialise le compte choisi sur l'émulateur PDC (ou sur le DC source du RODC pour les comptes de RODC), force la réplication de cet objet unique vers chaque DC et vérifie que chaque DC indique la nouvelle version de clé. Lisez attentivement son menu et exécutez d'abord les modes informatif et simulation dans chaque domaine.

Un renouvellement de routine se déroule ainsi :

1. Exécutez le script en mode informatif et lisez le rapport : DC découverts, joignabilité, version de clé sur chaque DC.
2. Exécutez le mode simulation sur les comptes de test ; confirmez que la réplication réussit vers chaque DC.
3. Réinitialisation 1 du krbtgt du domaine en mode réel. Confirmez que msDS-KeyVersionNumber a été incrémenté sur chaque DC.
4. Attendez au moins MaxTicketAge + MaxClockSkew (24 heures est une valeur par défaut confortable).
5. Réinitialisation 2 en mode réel, avec les mêmes contrôles.
6. Répétez pour les comptes krbtgt_NNNNN des RODC et pour chaque autre domaine de la forêt.

Quel que soit le mot de passe fourni, le DC génère sa propre valeur aléatoire pour krbtgt : il n'y a donc rien à stocker dans un coffre.

Planifiez un renouvellement de routine au moins tous les 180 jours, ainsi qu'après le départ de tout administrateur Tier 0, après une restauration d'AD à partir de supports de sauvegarde ayant échappé à votre contrôle, et après toute suspicion de DCSync ou d'exposition de NTDS.dit.

Mode incident

Lorsque vous disposez d'éléments indiquant une compromission du krbtgt (un DCSync depuis une source inattendue, des indicateurs de golden ticket, une sauvegarde de DC dérobée), l'ancienne clé doit disparaître maintenant, pas demain.

1. Retirez d'abord à l'attaquant la capacité de lire la nouvelle clé : réinitialisez ou désactivez les comptes Tier 0 compromis, supprimez les droits DCSync illégitimes (voir trouver les droits DCSync) et isolez les hôtes compromis.
2. Effectuez la réinitialisation 1, attendez uniquement que la réplication converge sur tous les DC (des minutes, pas des heures), puis effectuez la réinitialisation 2.
3. Acceptez l'impact : tous les TGT du domaine deviennent invalides. Les utilisateurs se réauthentifient au prochain accès à une ressource ou à la prochaine ouverture de session ; les services de longue durée peuvent nécessiter un redémarrage.
4. Répétez la double réinitialisation à la fin de la remédiation, une fois certain que la persistance a été éliminée.

Forcer la réplication entre les réinitialisations compte davantage en mode incident, car vous ne disposez pas de la marge de temps nécessaire pour absorber un lien lent :

# Pousser l'objet krbtgt vers tous les DC depuis l'émulateur PDC
$pdc = (Get-ADDomain).PDCEmulator
$krbtgt = (Get-ADUser krbtgt).DistinguishedName
Get-ADDomainController -Filter 'IsReadOnly -eq $false' | ForEach-Object {
    Sync-ADObject -Object $krbtgt -Source $pdc -Destination $_.HostName
}

Vérifier

# La version de clé et pwdLastSet doivent être identiques sur chaque DC accessible en écriture
Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    Get-ADUser krbtgt -Server $dc -Properties msDS-KeyVersionNumber, PasswordLastSet |
        Select-Object @{n='DC';e={$dc}}, msDS-KeyVersionNumber, PasswordLastSet
}

# Les métadonnées de réplication indiquent quand et où la modification du mot de passe a été initiée
Get-ADReplicationAttributeMetadata -Object (Get-ADUser krbtgt).DistinguishedName `
    -Server (Get-ADDomain).PDCEmulator -Properties unicodePwd, pwdLastSet |
    Select-Object AttributeName, LastOriginatingChangeTime, LastOriginatingChangeDirectoryServerIdentity, Version

Les RODC ne détiennent pas le secret krbtgt du domaine : vérifiez de la même manière leurs propres comptes krbtgt_NNNNN après les avoir renouvelés. Côté sécurité, une réinitialisation du krbtgt produit les événements 4724 (tentative de réinitialisation de mot de passe) et 4738 sur le DC où elle a été exécutée. Déclenchez une alerte sur ces événements en dehors des fenêtres de changement planifiées : une réinitialisation inattendue du krbtgt est soit une erreur, soit un attaquant qui efface ses traces. Prévenez le SOC à l'avance des renouvellements planifiés, pour que le renouvellement lui-même ne déclenche pas d'incident.

Ce que cela casse

• Une réinitialisation 2 trop précoce invalide des TGT légitimes : les utilisateurs voient des refus d'accès ou des demandes d'identifiants jusqu'à leur reconnexion, et les services qui détiennent des tickets échouent jusqu'à leur redémarrage.
• Un retard de réplication entre les réinitialisations provoque des échecs d'authentification intermittents, selon le DC qu'un client atteint. C'est pourquoi les contrôles de convergence ne sont pas optionnels.
• Les sessions et services de longue durée qui mettent en cache des TGT pendant des jours (certains services Linux avec k5start, serveurs d'applications avec tickets renouvelables, sessions VPN authentifiées par Kerberos) peuvent nécessiter un redémarrage après la réinitialisation 2.
• Le mode incident invalide tous les TGT d'un coup : attendez-vous à un pic d'appels au support et préparez la communication à l'avance.
• Des mots de passe krbtgt antérieurs à AES signifient que le premier renouvellement est aussi la première fois que krbtgt dispose de clés AES, ce qui peut révéler des clients qui ne géraient que RC4. Voir désactiver RC4 dans Kerberos.

Pour aller plus loin : le domaine Kerberos et authentification, identifier les actifs Tier 0 pour repérer tout ce qui pourrait laisser fuiter la nouvelle clé, et le plan de restauration de forêt, dans lequel la double réinitialisation est une étape obligatoire.