Golden tickets and the krbtgt account: why and how to reset krbtgt safely

What a forged TGT is

Because the krbtgt key signs every TGT, anyone who obtains that key, usually by compromising a domain controller or using directory replication rights, can create TGTs for any user with any group memberships and lifetimes. Domain controllers accept them because the signature checks out. This is called a golden ticket.

The only way to invalidate forged tickets is to change the krbtgt key. Resetting user passwords does nothing, because the forgery does not depend on them.

What detection can see

Forged tickets can carry anomalies: lifetimes far beyond the domain policy, a TGS request (4769) with no matching TGT request (4768) for that account, nonexistent or disabled accounts, or encryption types the domain no longer issues. Recent Windows updates added PAC validation changes that make some forgeries fail. Microsoft Defender for Identity and similar tools look for these patterns.

Prevention is stronger than detection here: protect domain controllers and the accounts that can replicate directory secrets as the highest tier.

Lab: rotate krbtgt twice

The krbtgt account keeps its current and previous key, and DCs accept tickets signed with either. So reset it once, wait until the change has replicated to every DC and until existing tickets expire (ten hours by default, so most teams wait 10 to 24 hours), then reset it again. The second reset removes the old key and with it any ticket forged from a stolen copy.

Microsoft publishes a New-KrbtgtKeys.ps1 script that checks replication and supports a simulation mode. In the lab, run it in simulation, then do a real first reset, check replication with repadmin, wait, and do the second.

Snippet

Get-ADUser krbtgt -Properties PasswordLastSet, msDS-KeyVersionNumber | Select PasswordLastSet, msDS-KeyVersionNumber
# Microsoft script: New-KrbtgtKeys.ps1 (run in simulation mode first)
repadmin /replsummary
repadmin /showobjmeta * "CN=krbtgt,CN=Users,DC=lab,DC=internal" | Select-String unicodePwd

Make it routine

Many organizations have never reset krbtgt, so its key dates from when the domain was created. Rotating it every 180 days, and immediately (twice) after any suspected domain controller compromise, limits how long a stolen key is useful.

Read-only domain controllers have their own krbtgt_##### accounts that need rotation too.

Diagram

Safe krbtgt rotation

Check
Confirm healthy replication across all DCs.
Command
```
repadmin /replsummary
```
Reset 1
Change the key; old key still accepted.
Wait
Let replication finish and tickets expire, typically 10 to 24 hours.
Reset 2
Change again; the stolen key is now useless.

Check yourself

1. Why does resetting users’ passwords not stop a golden ticket?

2. Why must krbtgt be reset twice?

3. What should you confirm before the first reset?