Code : MO-AD-002 | Version : 1.0 | Date : 15 avril 2026 | Auteur : C. Legrand
¶ MO-AD-002 — Rotation du compte krbtgt (double rotation Golden Ticket)
¶ 1. Objet
Ce mode operatoire decrit la double rotation du compte krbtgt, compte systeme Active Directory qui signe l'integralite des tickets Kerberos (TGT) emis par les controleurs de domaine. La procedure vise a neutraliser toute attaque de type Golden Ticket : une cle krbtgt compromise permet a un attaquant de forger des tickets Kerberos arbitraires, valables jusqu'a ce que la cle soit invalidee par une rotation — et cette rotation doit etre executee deux fois (la premiere ne suffit pas, voir section 4).
Frequence recommandee : tous les six mois (ou 180 jours), ou immediatement apres toute suspicion de compromission : extraction NTDS.dit, attaque DCSync, depart d'un administrateur de domaine.
Contexte initial : le compte
krbtgtdu domainebts.sioa ete cree le 06/09/2022 a 17:38 et n'avait jamais ete tourne avant l'execution de cette procedure en avril 2026, soit 1 316 jours de fenetre d'exploitation potentielle. PingCastle signalait cet etat via la regle A-Krbtgt #37. Ce mode operatoire formalise le traitement de ce risque.
¶ 2. Champ d'application
| Public concerne | Administrateurs du domaine BTS SIO (role Domain Admins) |
| Systemes cibles | Domaine bts.sio, controleurs DC1 (Srv2022, 10.0.112.2) et DC2 (Srv2022Phy, 10.0.112.3) |
| Outils | PowerShell avec module ActiveDirectory, repadmin, WinRM via pywinrm |
| Authentification | Compte Domain Admin (BTS\Administrateur ou equivalent) |
| Duree | Deux interventions d'environ 5 minutes espacees de 10 a 48 heures |
| Presentiel requis | Non : la procedure s'execute integralement via WinRM depuis le poste d'administration, sous couvert d'une connexion VPN WireGuard a l'infrastructure |
¶ 3. Prerequis
- MO-AD-005 execute : sante AD validee (
repadmin /replsummarysans erreur bloquante, servicesNTDS,kdc,NetlogonUP, FSMO accessibles) - MO-AD-006 execute : backup System State de DC1 recent (< 7 jours), verifie par
wbadmin get versions. Une restauration authoritative de l'objetkrbtgtne se fait que depuis ce backup - Acces WinRM (port 5985) aux deux controleurs de domaine avec un compte Domain Admin
- Fenetre d'intervention d'au moins 12 heures entre Phase 1 et Phase 2, idealement 24 a 48 heures
- Pas de sequence d'examens ou de TP critiques sur les deux jours concernes (risque marginal de deconnexion si la Phase 2 est declenchee trop tot)
repadmin /syncall /AdePet certaines sous-commandes derepadminremontent une erreur 110 (RPC timeout) sur le serveurSrv2022Phy(port 5722 bloque, DFSR partiellement casse depuis le 27/03/2026). Cette erreur n'interdit pas la rotation : la replication AD principale passe par les ports 135, 389 et 636 qui sont ouverts, etrepadmin /replsummarymontre une latence inferieure a une minute entre les deux DCs. Le depannage de DFSR/RPC 5722 fait l'objet d'une intervention distincte ; il ne doit pas retarder la rotationkrbtgt.
¶ 4. Theorie : compte krbtgt et attaque Golden Ticket
¶ 4.1 Role du compte krbtgt
Le compte krbtgt est un compte de service AD automatiquement cree a la promotion du premier controleur de domaine. Il est :
- desactive au sens ouverture de session (aucun logon interactif ou reseau possible) ;
- porteur de la cle symetrique utilisee par tous les KDCs du domaine pour signer et chiffrer les TGT ;
- stocke dans
NTDS.ditavec un hash NTLM accessible en lecture au systeme et aux comptes de haut privilege.
Chaque ticket TGT emis par un KDC est signe avec la cle courante de krbtgt. Sa duree de vie par defaut est de dix heures (extensible a sept jours par renouvellement). Tant qu'un TGT est valide, son porteur peut demander des tickets de service (TGS) aupres du KDC sans reauthentification.
¶ 4.2 Attaque Golden Ticket
Un attaquant qui parvient a extraire le hash NTLM de krbtgt (par DCSync, dump memoire LSASS sur un DC, ou lecture NTDS.dit hors ligne) peut alors forger, sur n'importe quelle machine et sans base AD, un TGT arbitraire. Les caracteristiques typiques d'un Golden Ticket sont :
- identite usurpee libre (y compris un compte inexistant ou Administrateur) ;
- appartenance aux groupes souhaites dont Enterprise Admins ou Domain Admins ;
- duree de vie poussee a dix ans (valeur arbitraire choisie par l'attaquant) ;
- validite tant que la cle
krbtgtqui l'a signe est acceptee par les KDCs.
La seule contre-mesure definitive consiste a changer le hash krbtgt. Les tickets forges avec l'ancien hash deviennent alors invalides des qu'ils sont presentes a un KDC dont la cle krbtgt a ete rotatee.
¶ 4.3 Mecanique N / N-1 et necessite d'une double rotation
Active Directory conserve deux versions du hash krbtgt : la version courante N et la precedente N-1. Ce mecanisme evite d'invalider massivement les tickets encore en circulation lors d'un changement de cle. Concretement :
- apres une seule rotation, un ticket signe avec l'ancien hash (N-1) reste accepte le temps de sa duree de vie residuelle. Un Golden Ticket forge avant la rotation continue donc de fonctionner ;
- la deuxieme rotation, executee apres expiration normale des tickets actifs, decale la cle N-1 vers la cle N-2 (jetee par AD). A ce moment, tout ticket signe avec l'ancien hash est rejete.
L'intervalle minimal entre les deux rotations est dicte par la duree de vie des TGTs (dix heures par defaut). Microsoft recommande 10 a 24 heures, et interdit formellement les deux rotations consecutives rapprochees qui « cassent » l'ensemble des tickets en vol.
¶ 5. Procedure Phase 1 : premiere rotation
¶ 5.1 Pre-verifications
Se connecter a DC1 via WinRM depuis le poste d'administration :
python3 -c "
import winrm
s = winrm.Session('10.0.112.2',
auth=('BTS\\\\Administrateur', OLD_PW), transport='ntlm')
print(s.run_ps(open('/tmp/krbtgt_precheck.ps1').read()).std_out.decode('cp850'))"
Contenu du script krbtgt_precheck.ps1 :
$k = Get-ADUser krbtgt -Properties PasswordLastSet, Created
$days = ((Get-Date) - $k.PasswordLastSet).Days
Write-Host "Derniere rotation : $($k.PasswordLastSet) ($days jours)"
repadmin /replsummary
Get-Service NTDS, kdc, DNS, Netlogon | Format-Table
netdom query fsmo
Checklist pre-verifications :
-
repadmin /replsummary: 0 echec, latence < 5 min - Services
NTDS,kdc,Netlogon: etatRunningsur DC1 et DC2 - Cinq roles FSMO localises sur un DC disponible (ici DC1)
- Backup System State DC1 de moins de sept jours (via
wbadmin get versions)
¶ 5.2 Execution Phase 1
Etape 1 — Generation et application du nouveau mot de passe
# Bloc PowerShell injecte via WinRM sur DC1
$charset = 33..126 | ForEach-Object { [char]$_ }
$newPwd = -join ($charset | Get-Random -Count 32)
$secure = ConvertTo-SecureString -String $newPwd -AsPlainText -Force
Set-ADAccountPassword -Identity krbtgt -NewPassword $secure -Reset
$newPwd = $null # ne JAMAIS logger le mot de passe
[System.GC]::Collect()
Le mot de passe n'est pas stocke et n'a pas besoin de l'etre : on ne se sert jamais du mot de passe de krbtgt en clair, seul son hash est utilise par les KDCs. Microsoft recommande une longueur de 24 a 32 caracteres aleatoires.
Etape 2 — Forcer la replication vers DC2
repadmin /syncall /AdeP
Start-Sleep -Seconds 10
repadmin /replsummary
Le drapeau /AdeP force une synchronisation pull sur tous les DCs et attend la fin de chaque replication avant de rendre la main. L'option /e etend a tous les sites.
Etape 3 — Confirmer la propagation sur les deux DCs
foreach ($dc in (Get-ADDomainController -Filter *)) {
Get-ADUser krbtgt -Server $dc.HostName -Properties PasswordLastSet |
Format-Table SamAccountName, PasswordLastSet
}
La valeur de PasswordLastSet doit etre identique sur DC1 et DC2 (a la seconde pres, une fois la replication terminee).
Horodatage de reference : lors de l'execution reelle du Sprint 2, Phase 1 a ete executee le 14/04/2026 a 13:02:38. Conserver ce timestamp (capture d'ecran ou journal de session) est indispensable pour decider du moment de la Phase 2.
¶ 6. Fenetre d'attente de 10 a 48 heures
Entre Phase 1 et Phase 2, ne rien modifier sur les comptes de service ni sur les tickets. Le delai a trois objectifs :
- permettre a tous les TGTs en circulation de se renouveler avec la cle N (celle qui vient d'etre posee) ;
- permettre a la replication AD de propager la nouvelle cle sur l'ensemble des DCs (mesuree en secondes dans une infra saine, mais laisser une marge) ;
- detecter precocement toute regression (services casses,
klistdes postes clients ne renouvelant pas leurs tickets, etc.) avant de figer la rotation.
$h = ((Get-Date) - (Get-ADUser krbtgt -Properties PasswordLastSet).PasswordLastSet).TotalHours
"Heures depuis Phase 1 : {0:N2}" -f $h
¶ 7. Procedure Phase 2 : seconde rotation
¶ 7.1 Garde-fou pre-Phase 2
Avant toute chose, verifier que l'intervalle est respecte :
$h = ((Get-Date) - (Get-ADUser krbtgt -Properties PasswordLastSet).PasswordLastSet).TotalHours
if ($h -lt 10) {
throw "Intervalle insuffisant ($([math]::Round($h,1)) h) : ANNULATION Phase 2"
}
¶ 7.2 Execution Phase 2
Le bloc est rigoureusement identique a la Phase 1 : meme generation aleatoire 32 caracteres, meme Set-ADAccountPassword -Identity krbtgt -Reset, meme repadmin /syncall /AdeP. Cette repetition est l'essence de la procedure : c'est le deuxieme cycle qui jette definitivement la cle N-1.
Verification finale
$before = [datetime]"2026-04-14 13:02:38" # horodatage Phase 1
$after = (Get-ADUser krbtgt -Properties PasswordLastSet).PasswordLastSet
$delta = ($after - $before).TotalHours
"Phase 1 : $before"
"Phase 2 : $after"
"Delta : $([math]::Round($delta,2)) heures"
La valeur de $delta doit etre superieure a 10 heures et inferieure a la duree maximale recommandee (~48 h). Dans l'execution de reference de ce MO, Δ = 29,81 heures (Phase 2 le 15/04/2026 a 18:52:21).
¶ 8. Verifications post-rotation
Apres la Phase 2, valider chaque item ci-dessous :
-
PasswordLastSet krbtgtidentique sur DC1 et DC2 -
repadmin /replsummary: 0 echec, latence < 5 min -
repadmin /showrepl: dernieres replications reussies sur chaque DC - Connexion interactive testee sur un poste du VLAN administratif (logon standard)
- Connexion interactive testee sur un poste du VLAN pedagogique (compte eleve)
- Taches planifiees critiques verifiees (T43 backup System State notamment)
- Capture
klist tgtavec nouveauKerbTicket Encryption Typeet increment dekvno
Cote poste client, forcer le renouvellement pour valider l'operation :
klist purge # vide le cache local
gpupdate /force # force un rafraichissement GPO
klist tgt # doit afficher un ticket frais
utilisateur <-> mot de passepour les authentifications non-Kerberos. Ce cache n'a rien a voir aveckrbtgt: il concerne les mots de passe des comptes utilisateur, jamais la clekrbtgt. Sa presence ne remet pas en cause l'efficacite de la rotation.
¶ 9. Depannage
| Symptome | Diagnostic et correction |
|---|---|
repadmin /syncall /AdeP renvoie Access Denied sur CN=NTDS Settings |
L'erreur n'est pas liee a la rotation mais a des ACL RPC particulieres. Tant que repadmin /replsummary montre 0 echec, la replication passe par les canaux normaux. Voir MO-AD-005 pour diagnostic approfondi. |
| Utilisateurs deconnectes massivement apres Phase 2 | Phase 2 lancee trop tot (moins de 10 h apres Phase 1). Les TGTs actifs n'ont pas eu le temps de se renouveler. Forcer klist purge + gpupdate /force sur les postes ou attendre l'expiration naturelle (≤ 10 h). |
| Service avec compte de service casse | Un compte de service standard utilise son propre mot de passe, pas celui de krbtgt. Si le service casse, c'est qu'il utilisait un TGT stocke en cache : redemarrer le service resoud le probleme. |
Set-ADAccountPassword : « The server is unwilling to process the request » |
Le mot de passe genere ne respecte pas la politique de mot de passe du domaine (FGPP la plus stricte applicable au compte). Regenerer en ajoutant un echantillon garanti de chaque classe de caracteres (upper, lower, digit, special). |
| DFSR SYSVOL casse apres rotation | Non cause par la rotation krbtgt (qui ne touche pas SYSVOL). Verifier dfsrdiag pollad et les journaux DFSR. Voir MO-AD-005 section 6. |
Service kdc arrete sur DC2 |
La Phase 2 echoue silencieusement sur ce DC. Redemarrer : Start-Service kdc via WinRM, puis relancer repadmin /syncall. |
¶ 10. Automatisation : script T21_rotation_krbtgt.ps1
Un script PowerShell parametre est deja disponible, fonctionnant en trois modes :
# Etat courant, sans modification
.\T21_rotation_krbtgt.ps1 -Phase Check
# Premiere rotation (demande confirmation 'oui')
.\T21_rotation_krbtgt.ps1 -Phase Phase1
# Seconde rotation (garde-fou < 10h)
.\T21_rotation_krbtgt.ps1 -Phase Phase2
Une planification semestrielle automatique peut etre posee via Register-ScheduledTask, en s'assurant imperativement que les deux phases soient espacees de plus de 12 heures :
$trig1 = New-ScheduledTaskTrigger -Once -At "2026-10-14T13:00:00"
$act1 = New-ScheduledTaskAction -Execute "powershell.exe" `
-Argument "-File C:\Scripts\T21_rotation_krbtgt.ps1 -Phase Phase1"
Register-ScheduledTask -TaskName "krbtgt-phase1" -Trigger $trig1 -Action $act1 `
-RunLevel Highest -User "BTS\Administrateur"
$trig2 = New-ScheduledTaskTrigger -Once -At "2026-10-15T13:00:00"
$act2 = New-ScheduledTaskAction -Execute "powershell.exe" `
-Argument "-File C:\Scripts\T21_rotation_krbtgt.ps1 -Phase Phase2"
Register-ScheduledTask -TaskName "krbtgt-phase2" -Trigger $trig2 -Action $act2 `
-RunLevel Highest -User "BTS\Administrateur"
-Phase Phase2manuelle reste preferable, avec le garde-fou integre qui verifie l'intervalle.
¶ 11. Rollback
Il n'existe pas de rollback simple pour une rotation krbtgt. Une fois le nouveau mot de passe pose, l'ancien hash n'est plus reconstructible (la generation etait aleatoire et le mot de passe clair jamais conserve). Les solutions en cas d'incident majeur :
- Attendre l'expiration naturelle des tickets actifs (≤ 10 heures) si des sessions utilisateurs sont cassees ;
- Restauration authoritative de l'objet
krbtgtdepuis le backup System State (MO-AD-006) : operation lourde, necessitant le demarrage d'un DC en Directory Services Restore Mode (DSRM). Reserver aux situations ou la rotation a litteralement casse l'authentification sur tout le domaine.
Dans la pratique, le pire scenario observable a la rotation est la deconnexion temporaire des sessions, resolue par un simple klist purge et une nouvelle ouverture de session.
¶ 12. Historique des revisions
| Version | Date | Auteur | Modifications |
|---|---|---|---|
| 1.0 | 15/04/2026 | C. Legrand | Creation initiale — procedure executee au titre du Sprint 2 (T21). Phase 1 : 14/04 13:02:38. Phase 2 : 15/04 18:52:21. |
¶ Voir aussi
- MO-AD-005 — Verifier la sante de l'AD avant intervention (prerequis)
- MO-AD-006 — Backup SystemState (prerequis)
- MO-AD-007 — Audit periodique des comptes et groupes AD (controle que
krbtgtest bien tourne regulierement) - MO-AD-008 — Rotation periodique des mots de passe critiques (complementaire : comptes administrateur classiques)
- PingCastle, regle A-Krbtgt #37 (krbtgt password last set)
- MITRE ATT&CK
T1558.001(Forge Kerberos Tickets: Golden Ticket) - Microsoft Docs « Reset the krbtgt account password » (article
KB2549833)
¶ Références
- Microsoft — Reset the krbtgt account password/keys (documentation Windows Server)
- Microsoft — krbtgt account password reset scripts (KB5020805, décembre 2022)
- ANSSI — Recommandations de sécurité relatives à Active Directory, R39–R41 (2023)
- MITRE ATT&CK — Technique T1558.001 (Golden Ticket)
- PingCastle — Règle A-Krbtgt #29 (ancienneté du mot de passe krbtgt)
- Audit BTS SIO — Constat F-AD-007 / Recommandation R-020