krbtgt account: how to reset it safely and evict Golden Tickets

The krbtgt account holds the key that signs every Kerberos ticket-granting ticket in an Active Directory domain, so whoever holds that key can mint tickets for anyone, and only a correctly executed password reset takes it back. Most domains have never reset it, and many that try get the sequence wrong: one reset instead of two, a second reset before replication has finished, or RODC krbtgt accounts forgotten entirely. This guide is the operational how-to: when to reset, how to prepare, the double reset step by step, how to check replication between the two resets, what breaks and how to recover, and how to prove it worked. It is written for Active Directory administrators, identity engineers and incident responders. The attack techniques themselves (Golden Ticket, Silver Ticket, DCSync) are covered in the Golden Ticket, Silver Ticket and DCSync Guide; this page goes deeper on the reset itself.

Key takeaways

• Two resets, never one. Microsoft states the krbtgt password history is 2, so a single reset leaves tickets signed with the previous key valid. Only the second reset removes the key an attacker may hold.
• The wait between resets is the safety margin. Microsoft's forest recovery procedure says to wait at least 10 hours, the default maximum user and service ticket lifetime, and longer if your Kerberos policy sets a longer lifetime. Replication of the first reset must also be complete.
• RODCs have their own krbtgt accounts. Each read-only domain controller uses a separate krbtgt_<number> account that the standard procedure does not touch. Rotate those separately.
• Routine and incident resets are different jobs. A planned annual rotation is low drama if you follow the timing. An emergency reset during a compromise is part of a wider recovery and only works once the attacker has lost the access that gave them the key.
• Measure it. krbtgt password age per domain and per RODC, replication health before and after, KDC event 9 after each reset, and Golden Ticket detection alerts are the evidence that the job was done.

What the krbtgt account is and why its key matters

Microsoft describes KRBTGT as a local default account that acts as the service account for the Key Distribution Center (KDC) service. It is created automatically with each domain, has the well-known relative identifier 502, cannot be deleted or renamed, and cannot be enabled. Its password is set by the system and is used to derive the secret key that encrypts and signs ticket-granting tickets (TGTs). Microsoft compares a krbtgt reset to renewing a root CA certificate with a new key and immediately distrusting the old one: almost every subsequent Kerberos operation is affected.

That is why the key is so valuable to an intruder. With it, a forged TGT for any account, carrying any group memberships, is accepted by every writeable domain controller in the domain (MITRE ATT&CK T1558.001 Golden Ticket). Disabling a user, resetting user passwords or removing group memberships does not invalidate those forged tickets. The usual ways the key is stolen are DCSync by an account holding replication rights (T1003.006), theft of the ntds.dit database from a domain controller, a backup, a virtual machine snapshot or install-from-media files, and direct compromise of a domain controller.

Do not delete RODC krbtgt accounts during recovery if you intend to recover those RODCs: Microsoft's procedure explicitly warns against it.

When to reset: routine rotation versus incident response

Microsoft's default accounts documentation says the krbtgt password should be changed on a regular schedule, as with any privileged service account, and that a reset is also best practice during forest recovery so that a restored domain controller does not replicate with a compromised one. Most organisations settle on an annual planned rotation, with additional resets after specific events.

The incident case needs a warning. Microsoft says an organisation suspecting krbtgt compromise should consider professional incident response services, because restoring ownership is domain-wide, labour intensive and part of a larger recovery effort. If the intruder still holds Domain Admin, replication rights or a domain controller, they can read the new key the moment you set it. Contain first, then reset. See the Active Directory Domain Compromise Response Playbook and the Identity Recovery Guide.

Preparation: what to check before the first reset

Most failed krbtgt resets are replication problems discovered too late. Before touching the account:

1. Inventory domain controllers: list every writeable DC and RODC in each domain, and remove metadata for any retired DC that still appears in the directory. The archived Microsoft New-KrbtgtKeys.ps1 repository notes that the script fails when it cannot reach a retired DC that is offline but still in Active Directory, and recommends cleaning such DCs up with ntdsutil.
2. Prove replication health: run repadmin /replsummary to find DCs failing inbound or outbound replication and repadmin /showrepl for the last inbound attempt per partition. Fix every failure before you start. A DC that cannot replicate will keep the old key and fail Kerberos for its clients.
3. Record the baseline: capture pwdLastSet on krbtgt and each krbtgt_<number>, plus the account's replication metadata with repadmin /showobjmeta, so you can compare versions after each reset.
4. Read the Kerberos policy: check Maximum lifetime for user ticket and Maximum lifetime for service ticket under Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy in the Default Domain Policy. The default is 10 hours. If either is longer, your wait between resets must be longer.
5. Check password filters: Microsoft warns that a customised password filter such as passfilt.dll on a DC can make the reset fail, and points to KB 2549833 for the workaround.
6. Find long-lived Kerberos consumers: applications, appliances and Linux hosts that cache tickets for long periods, and services that do not handle ticket renewal well. List the owners so they can be contacted if authentication errors appear.
7. Plan communications and a window: a routine reset has little visible impact when the wait is respected, but schedule it outside peak hours, and have the service desk briefed on the symptoms described below.

The double reset, step by step

Microsoft's forest recovery procedure uses Active Directory Users and Computers: enable View, Advanced Features; open the domain's Users container; right-click krbtgt and choose Reset Password; type any value and confirm. Microsoft notes that the password you type is not significant, because the system generates a strong password automatically. The same result can be achieved with a controlled script, which is the better choice in larger domains because it checks replication for you.

1. Run a dry run first: if you use the New-KrbtgtKeys.ps1 family of scripts, its informational mode (mode 1) lists all reachable writeable DCs and RODCs and makes no changes. Its simulation mode (mode 2) creates a temporary canary object and checks that it replicates to every DC in scope. Mode 3 resets a disabled test account (krbtgt_TEST, or krbtgt_<number>_TEST for an RODC, created by mode 8) and monitors replication of that change. Do not move on until the simulations are clean.
2. First reset: reset krbtgt once on a single writeable DC, ideally the PDC emulator or a well-connected hub DC. The script's real reset mode (mode 4) does this for the production account and then compares pwdLastSet on each remote DC until it matches.
3. Confirm the KDC picked it up: Microsoft says to check that event ID 9 from the Key-Distribution-Center source is written to the System event log after a reset.
4. Confirm replication: on every DC, the krbtgt account's pwdLastSet and its replication metadata version (repadmin /showobjmeta) must match the originating DC. Force synchronisation with repadmin /syncall only if needed, and investigate any DC that lags.
5. Wait: at least 10 hours, or longer than your configured maximum ticket lifetime. During the wait, existing TGTs signed with the old key still validate because the previous key is kept in history, and they expire naturally.
6. Second reset: repeat the reset on the same originating DC. The second reset removes the original key from the two-entry history, so any ticket signed with the key an attacker may hold now fails.
7. Confirm again: event ID 9, pwdLastSet and metadata on every DC, as after the first reset.
8. Repeat for RODCs: for each RODC, reset its krbtgt_<number> account (found through msDS-KrbTgtLink on the RODC computer object) on a writeable DC and confirm the change reaches that RODC. The script handles RODC-specific accounts in the same modes.
9. Repeat per domain: every domain in the forest has its own krbtgt. A forest root reset does nothing for child domains.

The emergency variant

During an active compromise, some responders shorten the wait between resets to cut off a forged-ticket attacker sooner. That is a deliberate trade-off: every TGT in the domain becomes invalid at once and clients fail Kerberos until they obtain a new TGT. Microsoft's default accounts page says you must assume all computers and users will be affected and that rebooting a computer is the only reliable way to restore its functionality. Only choose the short interval when the risk of continuing forged access outweighs a domain-wide outage, the attacker's foothold has been removed, and the service desk and application owners are ready.

What breaks, and how to recover

NTLM-authenticated connections are not affected, according to Microsoft, which explains why some services keep working while others fail. There is no rollback for a krbtgt reset: the old key cannot be restored. Recovery is always forward, by fixing replication and making clients obtain new tickets.

Detection and measurement

A reset is only useful if you can show it happened everywhere and that forged tickets now fail. Collect the following from domain controllers and your identity threat detection tooling. Event semantics are covered in depth in the Active Directory Security Monitoring and Event IDs Guide.

Metrics that show the programme is working:

• krbtgt age: days since the last completed double reset, per domain and per RODC account, against a target such as 365.
• Replication readiness: number of DCs failing repadmin /replsummary on the day before a planned reset (target zero).
• Completion evidence: percentage of DCs confirming the new pwdLastSet within the planned window after each reset.
• Impact: service desk tickets and application incidents attributed to each rotation, which should fall as the runbook matures.
• Detection coverage: percentage of DCs feeding 4768, 4769 and 4724 to the SIEM or identity threat detection sensor.

Decision guidance: tooling, timing and organisation size

• Manual or scripted: a single-site domain with two or three healthy DCs can be reset by hand from Active Directory Users and Computers with repadmin checks. Multi-site domains, domains with RODCs and forests with several domains are better served by a script that checks every DC, because a missed DC is the most common cause of outage. The Microsoft repository was archived in March 2024 and is no longer maintained; its maintainers point to community forks, so review any script's code before running it with Domain Admin rights.
• Interval between resets: use the full wait (at least the maximum ticket lifetime, after confirmed replication) for every planned rotation. Shorten it only in an incident and only with the acceptance of a domain-wide re-authentication.
• Small organisations: a calendar reminder, a one-page runbook and a check of pwdLastSet are enough. The biggest risk is that nobody remembers the account exists.
• Large organisations: make the rotation a change-managed Tier 0 operation with named owners, a contact list for Kerberos-dependent applications, automated pre-checks and a post-reset report. Run a rehearsal in a test forest that mirrors the production DC topology.
• Who may reset: Microsoft requires Domain Admins membership or delegated authority. Perform it from a privileged access workstation, never from a general-purpose device. See the Privileged Access Workstations Guide.

Where identity fits

krbtgt is the most privileged non-human identity in an Active Directory domain: a service account whose secret underpins every user and machine logon. It belongs in your NHI inventory with an owner, a rotation schedule and monitoring, alongside the other Tier 0 secrets that are often rotated at the same time after a compromise: the DSRM password on each DC, trust account passwords, AD CS CA keys, the Entra Connect sync account, gMSA root keys and the passwords of service accounts with high privilege. Rotating krbtgt while leaving a compromised Tier 0 service account in place simply hands the new key back to the attacker. See the Kerberos Security Guide and the AD Domain Controller Hardening Guide.

Framework mapping

Common failure patterns

• One reset and done: the previous key stays in the two-entry history, so a stolen key keeps working. The job is only finished after the second reset has replicated.
• Back-to-back resets in a routine rotation: resetting twice within minutes during a planned change causes the outage the wait is designed to avoid, and teaches the organisation to fear the rotation.
• Resetting while the attacker is still inside: an intruder with replication rights or a DC simply reads the new key with DCSync. Remove replication rights from non-DC principals and evict the attacker first.
• Forgetting RODCs and child domains: each krbtgt_<number> and each domain's krbtgt needs its own rotation. Inventories based only on the forest root miss them.
• Ignoring replication errors: a DC that has not replicated for weeks keeps the old key, fails Kerberos for its clients after the reset, and may have been a reason the reset was needed.
• No owner for the next one: the rotation is done once after an audit finding and the account's age quietly climbs back to years. Put it on a schedule with an owner and a metric.

Lessons from incidents

In the Co-op Cyber Attack, attackers reportedly used a help desk password reset to get into the network and then went after Active Directory credential data. The NHIMG analysis recommends alerting on access to ntds.dit and domain controller backups and rotating service accounts, including krbtgt, after a domain compromise. The lesson for the reset is ordering: once directory credential data may have left the building, the krbtgt double reset belongs in the eradication plan, but only after the entry route and the attacker's privileged footholds have been closed.

Practitioner checklist

• Report pwdLastSet for krbtgt in every domain and for every krbtgt_<number> RODC account.
• Remove stale DC metadata and clear every failure in repadmin /replsummary before a reset.
• Read the Kerberos policy ticket lifetimes and set the wait between resets above them, never below 10 hours for a routine rotation.
• Rehearse with a test krbtgt account or a test forest and a simulation run before the production reset.
• Perform the first reset, confirm event 9 and pwdLastSet on every DC, wait, then perform the second reset and confirm again.
• Rotate each RODC's krbtgt_<number> account and each child domain's krbtgt on the same schedule.
• In an incident, contain the attacker and remove non-DC replication rights before resetting, and rotate the other Tier 0 secrets in the same window.
• Alert on event 4724 for krbtgt accounts outside change windows, and keep Golden Ticket detections enabled.
• Record the rotation in the NHI inventory with an owner and a next-due date.

Standards and references

• Microsoft Learn: AD Forest Recovery, Reset the krbtgt password
• Microsoft Learn: Active Directory default user accounts (KRBTGT)
• Microsoft Learn: Maximum lifetime for user ticket
• Microsoft Learn: Defender for Identity security alerts
• Microsoft Learn: Repadmin command reference
• Microsoft (archived): New-KrbtgtKeys.ps1 repository
• CISA and partners: Detecting and Mitigating Active Directory Compromises
• MITRE ATT&CK: Golden Ticket (T1558.001)

Related NHI Mgmt Group resources: Golden Ticket, Silver Ticket and DCSync Guide · Active Directory Domain Compromise Response Playbook · Identity Recovery Guide · MITRE ATT&CK T1558 Steal or Forge Kerberos Tickets Guide