Rotation mot de passe krbtgt, compte de confiance, controleur de domaine : les trois secrets Active Directory qui ne se renouvellent jamais tout seuls

Active Directory donne l'impression d'être un système qui entretient ses propres secrets. Les ordinateurs joints au domaine changent leur mot de passe selon un calendrier, les relations d'approbation se renouvellent en arrière-plan, et personne n'ouvre jamais de ticket à ce sujet. Cette impression explique exactement pourquoi l'hygiène de la rotation mot de passe krbtgt, compte de confiance, controleur de domaine est la lacune la plus silencieuse de la plupart des parcs Active Directory : l'un de ces trois secrets n'a aucune rotation automatique, et les deux autres ne se renouvellent qu'aussi longtemps que rien n'est discrètement cassé. Cet article détaille ce que fait réellement chaque mécanisme, comment vérifier les trois en quelques minutes, et comment les corriger sans provoquer une panne d'authentification à l'échelle du domaine.

Rotation mot de passe krbtgt, compte de confiance, controleur de domaine : qui renouvelle quoi

Le piège vient d'une déduction parfaitement raisonnable. La documentation des stratégies Microsoft indique que « in Active Directory-based domains, each device has an account and password. By default, the domain members submit a password change every 30 days » (Domain member: Maximum machine account password age). Les machines s'entretiennent réellement elles-mêmes, si bien que les administrateurs généralisent : l'annuaire gérerait tout seul ses secrets.

Deux des trois éléments ci-dessus sont effectivement automatiques. Mais « automatique » signifie ici automatique tant que tout va bien, et le secret le plus précieux du domaine n'a jamais été automatique, depuis le début.

krbtgt : le mot de passe qu'Active Directory ne change jamais pour vous

Le compte krbtgt est l'endroit où réside le matériel de clés Kerberos du domaine — chaque TGT du domaine est chiffré et signé avec sa clé. Microsoft décrit ce compte exactement en ces termes : il « supports key storage in all Kerberos Key Distribution Centers (KDCs) », et « [t]o renew the Kerberos keys for TGT encryption, periodically change the krbtgt account password » (Accounts security posture assessment). Rien dans l'annuaire n'effectue ce changement à votre place : il n'existe ni minuteur Netlogon ni paramètre de stratégie derrière ce compte, seulement un administrateur qui exécute la réinitialisation manuellement.

C'est là tout le problème. En l'absence de rotation, le rayon d'impact d'une seule copie historique de la base de comptes ne se réduit jamais, et Microsoft en énonce la conséquence : « If the KRBTGT account's password is compromised, an attacker can use its hash to generate valid Kerberos authentication tickets, allowing them to perform Golden Ticket attacks and gain access to any resource in the AD domain. Since Kerberos relies on the KRBTGT password to sign all tickets, closely monitoring and regularly changing this password is essential to mitigating the risk of such attacks. » Sa propre base de référence met un chiffre sur ce regularly : Defender for Identity propose une recommandation nommée Change password for krbtgt account, qui « lists any krbtgt account within your environment with password last set over 180 days ago ». Les algorithmes utilisés par ces clés sont l'autre moitié de l'histoire, traitée dans notre guide sur le repli Kerberos RC4.

Ce qu'un attaquant fait de cette clé est traité en détail dans notre guide sur l'attaque Golden Ticket — cet article porte sur l'hygiène de rotation qui fait expirer le ticket forgé au lieu de le laisser vivre indéfiniment.

Mots de passe de confiance : automatiques d'un seul côté

Les approbations inter-domaines se renouvellent bel et bien, et elles le font sans que personne n'ait à le demander. La documentation Microsoft sur les mécanismes internes des approbations décrit le fonctionnement : « Both domains in a trust relationship share a password, which is stored in the TDO object in Active Directory. As part of the account maintenance process, every thirty days, the trusting domain controller changes the password stored in the TDO » (How Domain and Forest Trusts Work — un document archivé de Windows Server 2003, toujours la description publique la plus détaillée du processus).

Trois détails de ce document ont une portée opérationnelle :

• Un seul côté pilote le processus. « A domain controller in the trusted domain never initiates the password change; it is always initiated by the trusting domain PDC emulator. »
• L'ancien mot de passe est délibérément conservé. Si l'authentification avec le nouveau mot de passe échoue, le contrôleur de domaine approbateur « tries to authenticate using the old password », et si cela réussit, il « resumes the password change process within 15 minutes » — c'est pourquoi l'ancienne et la nouvelle valeur cohabitent toutes deux dans le TDO.
• La réplication a une échéance stricte. « Trust password updates need to replicate to the domain controllers of both sides of the trust within 30 days. If the trust password is changed after 30 days and a domain controller then only has the N-2 password, it cannot use the trust from the trusting side and cannot create a secure channel on the trusted side. »

Le secret lui-même n'est pas un attribut de mot de passe ordinaire : Microsoft précise que les secrets d'approbation « are represented by special attributes on the interdomain trust accounts », trustAuthIncoming côté approuvé et trustAuthOutgoing côté approbateur, et qu'ils « are maintained by the domain controller which is the primary domain controller (PDC) emulator Flexible Single Master Operation (FSMO) role in the trusting domain » (UserAccountControl property flags).

Ce que vous pouvez lire, en revanche, c'est le compte d'approbation inter-domaines qui accompagne le TDO. Selon MS-ADTS, les approbations dont le trustDirection est entrant ou bidirectionnel disposent d'un compte utilisateur associé dans le conteneur d'utilisateurs par défaut, et les deux objets sont liés par le nom NetBIOS du partenaire : le flatName du TDO correspond au sAMAccountName du compte, moins le $ final. Le point de contrôle de l'ANSSI Trust account passwords unchanged for more than a year lit précisément le pwdLastSet de ce compte, et son verdict mérite d'être cité : une valeur périmée « may be indicative of deleted trust relationships while their corresponding trust accounts are still present », et lorsque l'approbation est toujours active, « the cause for the lack of an automatic renewal should be investigated ».

Si vous auditez les approbations de façon plus large, associez cette lecture à nos articles sur les chemins d'attaque des relations de confiance et l'audit du filtrage SID et de l'authentification sélective.

Mots de passe machine des contrôleurs de domaine : automatiques jusqu'à ce que quelque chose les bloque

Les contrôleurs de domaine sont eux aussi membres du domaine, et leurs comptes d'ordinateur se renouvellent selon le même calendrier Netlogon qu'un poste de travail. La KB 154501 de Microsoft l'énonce clairement : « Starting with Windows 2000-based computers, the machine account password automatically changes every 30 days » (Disable machine account password changes). La stratégie qui régit cet intervalle autorise un « user-defined number of days between 1 and 999 », avec une valeur par défaut effective de 30 jours, aussi bien sur les contrôleurs de domaine que sur les serveurs membres et les postes clients.

Un contrôleur de domaine dont le mot de passe machine n'a pas bougé depuis des mois n'est donc pas un choix de configuration — c'est un signal. Le point de contrôle de l'ANSSI Domain controllers with passwords unchanged for more than 45 days est sans ambiguïté : « Some domain controllers have not changed their password for more than 45 days, indicating their secrets are not renewed », et « the reason for this change not to occur properly must be investigated as it may be indicative of a compromise. »

Les coupables habituels sont locaux à la machine :

• DisablePasswordChange positionné à 1 sous HKLM\System\CurrentControlSet\Services\Netlogon\Parameters, ce qui empêche la machine de jamais soumettre un changement — c'est celui-ci qui gèle le secret propre du contrôleur de domaine.
• Une valeur MaximumPasswordAge poussée très loin, ou une GPO qui redéfinit discrètement l'une ou l'autre valeur.
• Le service Netlogon arrêté, ou un canal sécurisé déjà rompu.

Une valeur de registre est souvent accusée à tort ici. RefusePasswordChange positionné à 1 « causes the domain controller to refuse password change requests only from workstations or member servers that run Windows NT version 4.0 or later » — il gèle les mots de passe machine de vos membres, pas celui du contrôleur de domaine lui-même. Vérifiez-le lorsque des objets membres cessent de se renouveler : avec RefusePasswordChange, « the replication traffic will stop, but not the client traffic », alors que DisablePasswordChange arrête les deux.

L'avertissement de Microsoft sur la désactivation de ce mécanisme mérite d'être répété : « If you disable machine account password changes, there are security risks because the security channel is used for pass-through authentication. If someone discovers a password, he or she can potentially perform pass-through authentication to the domain controller. » La documentation de stratégie ajoute l'autre moitié : « Significantly increasing the password change interval (or disabling password changes) gives an attacker more time to undertake a brute-force password-guessing attack against one of the machine accounts. »

Le secret d'un compte machine sert aussi de matière première aux tickets de service pour tout ce qui tourne sur cet hôte, c'est le mécanisme derrière une attaque Silver Ticket — et sur un contrôleur de domaine, les anomalies autour de l'objet ordinateur méritent le même examen qu'une source de réplication inattendue, l'artifice utilisé par DCShadow. Pour une vision plus large de l'identité machine, consultez notre analyse de la surface d'attaque des objets ordinateur.

Détection

Trois requêtes, exécutées depuis un poste d'administration joint au domaine avec RSAT, couvrent l'ensemble du trio.

1. Les comptes krbtgt, y compris ceux propres à chaque RODC :

Get-ADUser -Filter "SamAccountName -like 'krbtgt*'" -Properties PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet, Enabled

2. Les comptes d'approbation inter-domaines, résolus à partir des TDO eux-mêmes :

Get-ADObject -Filter "objectClass -eq 'trustedDomain'" -Properties flatName, trustDirection |
    ForEach-Object {
        Get-ADUser -Identity ('{0}$' -f $_.flatName) -Properties PasswordLastSet -ErrorAction SilentlyContinue |
            Select-Object SamAccountName, PasswordLastSet
    }

Les mêmes comptes peuvent être listés directement grâce à l'indicateur INTERDOMAIN_TRUST_ACCOUNT — décimal 2048, hexadécimal 0x0800 — via la règle de correspondance LDAP_MATCHING_RULE_BIT_AND, OID 1.2.840.113556.1.4.803 (Search Filter Syntax) :

Get-ADUser -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=2048)" -Properties PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

3. Tous les objets ordinateur des contrôleurs de domaine :

Get-ADDomainController -Filter * | ForEach-Object {
    Get-ADComputer $_.ComputerObjectDN -Properties PasswordLastSet |
        Select-Object Name, PasswordLastSet
}

Lisez le résultat au regard des seuils suivants :

Les signaux correspondants dans les journaux d'événements :

L'événement 4742 « generates only on domain controllers », ce qui rend la collecte côté contrôleurs de domaine suffisante pour cette vérification. Sur une machine suspecte, nltest /sc_query:<domain> renvoie ERROR_ACCESS_DENIED lorsque le canal sécurisé est rompu (Broken trust relationship between a domain-joined device and its domain).

Remediation

🚨 Danger : n'exécutez jamais les deux réinitialisations de krbtgt l'une à la suite de l'autre. Faire la seconde avant que la première n'ait entièrement répliqué invalide les tickets dans tout le domaine et peut faire tomber l'authentification avec eux.

Renouveler krbtgt, par étapes

1. Vérifiez d'abord la réplication. La procédure en deux réinitialisations ne fonctionne que si chaque contrôleur de domaine a reçu le premier nouveau mot de passe avant que le second n'arrive, donc confirmez que la réplication est saine avant de commencer. repadmin /replsummary « identifies domain controllers that are failing inbound replication or outbound replication, and summarizes the results in a report ».
2. Réinitialisez une première fois, en suivant la procédure prise en charge décrite dans AD Forest Recovery - Reset the krbtgt password. Le mot de passe que vous saisissez n'a pas d'importance : « the system generates a strong password automatically independent of the password that you specify ».
3. Attendez. Microsoft : « You should perform this operation twice. You must wait 10 hours between password resets. 10 hours are the default Maximum lifetime for user ticket and Maximum lifetime for service ticket policy settings, hence in a case where the Maximum lifetime period changes, the minimum waiting period between resets should be greater than the configured value. » Considérez les 10 heures comme un plancher plutôt qu'un objectif : dans une forêt vaste ou à réplication lente, laisser une journée complète entre les deux réinitialisations ne coûte rien.
4. Réinitialisez une seconde fois. Les deux réinitialisations sont nécessaires car « the password history value for the krbtgt account is 2, meaning it includes the two most recent passwords » — une seule réinitialisation laisse la clé précédente dans l'historique, toujours utilisable. Microsoft : « By resetting the password twice you effectively clear any old passwords from the history, so there's no way another DC replicates with this DC by using an old password. »
5. Planifiez-le au calendrier. Defender for Identity commence à signaler le compte à 180 jours, ce qui fait d'une rotation semestrielle un choix par défaut défendable. Quel que soit l'intervalle choisi, la rotation n'existe que si quelqu'un en est responsable.

Corriger un mot de passe de confiance périmé

1. Déterminez si l'approbation existe toujours. Comparez les comptes de confiance trouvés avec les TDO réellement actifs. La remédiation de l'ANSSI pour les comptes orphelins est directe : « Some trust accounts may remain while their trust relationships have been removed. They should be deleted manually. »
2. Pour une approbation active, vérifiez le canal sécurisé avant de toucher à quoi que ce soit : netdom trust <TrustingDomain> /domain:<TrustedDomain> /verify — le paramètre /verify « verifies the secure channel secrets for a specific trust relationship » (netdom trust).
3. Investiguez avant de réinitialiser. Un mot de passe de confiance qui n'a pas bougé depuis des mois signifie que l'émulateur PDC du domaine approbateur n'a pas pu mener l'échange à son terme — vérifiez la connectivité vers le partenaire, l'état de santé du rôle d'émulateur PDC, et la réplication du TDO des deux côtés, en gardant à l'esprit la règle N-2 évoquée plus haut.
4. Réinitialisez le secret d'approbation uniquement dans une fenêtre de changement planifiée, avec des identifiants des deux côtés : netdom trust <TrustingDomain> /domain:<TrustedDomain> /userd:<TrustedDomain>\admin /passwordd:* /reset. Le paramètre /reset « resets the trust secret between trusted domains or between the domain controller (DC) and the workstation ».

Remettre un contrôleur de domaine en rotation

1. Confirmez que le service est démarré : sc.exe query netlogon.
2. Vérifiez les deux valeurs de registre Netlogon sous HKLM\System\CurrentControlSet\Services\Netlogon\Parameters — la remédiation de l'ANSSI attend que DisablePasswordChange soit à 0 ou absent, et que MaximumPasswordAge soit à 30, et vous demande de confirmer qu'aucune GPO ne les surcharge.
3. Vérifiez que le mot de passe machine correspond à celui de l'annuaire : nltest /sc_verify:<NetBIOSDomainName> doit renvoyer 0 0x0 NERR_Success.
4. Si le contrôleur de domaine est désynchronisé parce qu'il a été restauré depuis un état antérieur, traitez cela comme une réparation de canal sécurisé, pas comme un problème de rotation — Microsoft documente les deux sens du décalage (l'appareil plus récent qu'AD, et AD plus récent que l'appareil).

L'hygiène de rotation s'inscrit aux côtés du reste de votre posture d'identifiants — stratégies faibles, mots de passe sans expiration et stockage en clair sont traités dans notre article sur la sécurité des mots de passe Active Directory, et les trois vérifications ci-dessus s'intègrent directement dans un audit de sécurité Active Directory plus large.

Comment EtcSec détecte cela

Un audit EtcSec vérifie les trois secrets en une seule passe. ANSSI_R28_KRBTGT_NOT_ROTATED (Critique) lit le pwdLastSet de chaque compte krbtgt et signale les domaines qui dépassent la barre des 180 jours. ANSSI_R42_TRUST_PASSWORD_OLD (Élevé) résout chaque objet de domaine approuvé vers son compte d'approbation inter-domaines et signale les mots de passe qui ont cessé de se renouveler — y compris les comptes orphelins laissés par des approbations supprimées. ANSSI_R43_DC_PASSWORD_OLD (Élevé) et COMPUTER_PASSWORD_OLD comparent chaque contrôleur de domaine et objet ordinateur membre à la cadence Netlogon de 30 jours, de sorte qu'un canal sécurisé bloqué remonte comme un constat au lieu d'un ticket de support six mois plus tard. GOLDEN_TICKET_RISK relie le résultat krbtgt à ce qu'un attaquant fait réellement d'une clé qui ne change jamais.

Références

• Microsoft — AD Forest Recovery: Reset the krbtgt password
• Microsoft — Accounts security posture assessment (Defender for Identity)
• Microsoft — How Domain and Forest Trusts Work
• Microsoft — UserAccountControl property flags (KB 305144)
• Microsoft — Disable machine account password changes (KB 154501)
• Microsoft — Domain member: Maximum machine account password age
• Microsoft — MS-ADTS: Essential Attributes of Interdomain Trust Accounts
• Microsoft — 4742(S): A computer account was changed et 4724(S, F): An attempt was made to reset an account's password
• Microsoft (archivé) — New-KrbtgtKeys.ps1, en lecture seule depuis le 8 mars 2024
• ANSSI / CERT-FR — Points de contrôle Active Directory (CERTFR-2020-DUR-001), collection de points de contrôle sur cert.ssi.gouv.fr/uploads/ad_checklist.html — points de contrôle Trust account passwords unchanged for more than a year et Domain controllers with passwords unchanged for more than 45 days