Rotating the krbtgt password: why twice, and how to do it without breaking anything
In many domains, the krbtgt password has not changed since the forest was created. Yet it is the key that makes a Golden Ticket possible. Rotating it is straightforward, provided you follow the right order and timing.
What the krbtgt account does
The krbtgt account is disabled and is never used to log on. Its key is used by the KDC to encrypt and sign Ticket Granting Tickets. An attacker who obtains that key, for instance through DCSync or a copy of NTDS.dit, can forge TGTs for any account, with any group membership and any lifetime: that is a Golden Ticket. As long as the key does not change, those tickets stay valid, even if every admin account has been reset.
Why reset twice
The KDC keeps both the current and the previous krbtgt password, so that tickets issued just before a change remain usable. A single reset therefore leaves the old key valid. Two resets are needed to fully invalidate a compromised key.
Chaining both resets without waiting is risky, though: legitimate TGTs issued with the original key all become invalid at once, and a domain controller that has not yet replicated the first change ends up out of sync. The symptoms are authentication and resource access failures that are hard to diagnose.
The procedure
- Check replication health across all domain controllers (
repadmin /replsummary). - Reset the krbtgt password once.
- Wait until the change has replicated everywhere, then at least the maximum user ticket lifetime (ten hours by default, longer if the Kerberos policy has been changed).
- Reset it a second time, then check replication again.
Microsoft publishes a PowerShell reset script, New-KrbtgtKeys.ps1, which offers a simulation mode, checks replication and targets a specific domain controller. It is preferable to resetting the account by hand in the console. The password itself is randomly generated: nobody needs to know it.
After a confirmed compromise. The timeline changes: it can be justified to shorten the wait between the two resets considerably, accepting temporary disruption. That is an incident response decision, not routine maintenance.
RODC krbtgt accounts
Each read-only domain controller has its own account, named krbtgt_ followed by a number. It signs the tickets issued by that RODC. These accounts must be part of the rotation, especially if an RODC in a remote site may have been physically compromised. Microsoft's script can handle them.
How often?
There is no universal figure. Rotating at least once a year is a common practice; many organisations do it more often, and some frameworks flag a krbtgt password that is too old. Rotation is in any case required:
- after any suspected domain compromise;
- after a tier 0 administrator leaves;
- after a forest recovery;
- if the domain was raised to the 2008 functional level or higher without a rotation since, because the account may then lack AES keys.
What an audit checks
- The last password change (
pwdLastSet) of the krbtgt account and of the RODC krbtgt accounts. - Whether a documented and tested procedure exists.
- Replication health, the essential prerequisite.