Why is the Active Directory krbtgt account password reset twice during eradication?

## What the krbtgt key is In a Kerberos realm backed by Active Directory, the key distribution centre issues a ticket-granting ticket to an authenticated principal and protects that ticket with a key derived from the password of a special domain account named `krbtgt`. When the principal later asks for a service ticket, the KDC unwraps the TGT with that same key and trusts what it finds inside, including the user identity and the group security identifiers that end up in the access token on the target service. That design is what makes the key so valuable to an intruder. An adversary who has obtained the krbtgt key material, typically after reaching domain-controller-level privilege, can construct a TGT offline for any principal they like: a non-existent user, a real user, with domain-admin group membership and an arbitrary lifetime. This forged ticket is what the industry calls a golden ticket. It requires no further contact with the compromised account, and crucially it is unaffected by resetting the passwords of the users it impersonates, because the KDC never re-checks a password when it unwraps a TGT. ## Why one reset is not enough Active Directory retains two keys for the krbtgt account: the current one and the immediately previous one. The previous key is kept so that tickets issued shortly before a change keep working while the change propagates. The consequence during eradication is direct: after a single reset, the stolen key is now the previous key, and it still validates. A golden ticket forged with it is still accepted. A second reset pushes the stolen key out of that two-deep history. Only then is the forgery dead. Note that you do not choose the password; the directory generates the krbtgt secret itself, so the operation is a reset rather than a password you pick. ## Why you wait in between The two resets are not back to back. The first change has to replicate to every domain controller in the domain. If you reset again before convergence, a controller still holding the pre-reset key ends up two generations behind and cannot validate tickets issued by its peers, which produces broad authentication failures. The safe rule is to confirm replication has reached every controller, including any that were offline or on a slow link, and in practice to allow the maximum ticket lifetime as well (ten hours by default for a TGT) so that legitimate tickets minted under the old key have aged out. On a large or partially reachable forest that turns a two-command job into a planned operation with verification between the steps. ## What the double reset does not fix - **Silver tickets.** A forged service ticket is protected with the key of the target service account or computer account, not with the krbtgt key. Resetting krbtgt twice leaves those forgeries intact. Any service or computer account whose key the adversary harvested has to be reset in its own right. - **Trust keys.** Where domain or forest trusts exist, the inter-realm trust key is a separate secret and needs separate treatment if the adversary could have taken it. - **A key stolen again.** The reset is meaningless if the adversary still holds the privilege that let them extract the key in the first place. If they retain code execution or replication rights on a domain controller, they will simply take the new key. This is why krbtgt sits late in the containment sequence, after the access paths that reach domain controllers have been cut, and why the operation is planned rather than done reflexively at the first sign of trouble. - **Everything outside Kerberos.** Certificates, application credentials, cloud tokens and federation signing keys are untouched. ## Blast radius and how it is felt A krbtgt reset invalidates every TGT in the domain, so principals re-authenticate. For interactive users this is mostly transparent, but long-running services, scheduled processes and applications holding delegated credentials can throw errors during the window, and anything mid-transaction may fail. Do it with a change record, with the application owners told a window is coming, and with someone watching authentication failure rates on both sides of each reset. Verification afterwards is behavioural rather than declarative: watch for ticket-related failures settling back to baseline, and watch for renewed use of the impersonated identities, which would tell you the adversary still has a path to the key.