Every Active Directory environment has one account whose password nobody ever changes. I don't mean service accounts — those at least show up in an audit report. I mean the account that sits quietly in the middle of the user list, that nobody logs in with, that nobody complains about, and for exactly that reason nobody touches: krbtgt.
That account's password is your domain's master key. Behind every Kerberos ticket that proves your users' identity, there it is. In most of the environments I've worked in, that password had never changed since the day the domain was built.
My reason for writing this today isn't only security hygiene. Through 2026, Windows changed its Kerberos defaults step by step, and that change turned the long-deferred krbtgt rotation from an optional improvement into a scheduled task. Let me start at the end: by the time you finish this article you'll have a measurement command and a date.
What krbtgt actually does
In Kerberos a user doesn't prove their identity to the file server directly. They first get a Ticket Granting Ticket — a TGT — from the domain controller (KDC), then present that TGT to request a separate service ticket for each service. All the trust in this two-step design collapses into one question: how does the KDC know a TGT isn't forged?
The answer is simple. The TGT is encrypted with the krbtgt account's key. The user can't read it, can't modify it, can't mint one — they only carry it. When it comes back, the KDC opens it with its own key and trusts the authorization data inside.
The asymmetry here matters. A user's password opens a door; the krbtgt key opens the machine that manufactures doors. Whoever holds it can write a ticket for a user that doesn't exist, with any group membership, valid for any length of time. In attacker literature this is called a Golden Ticket.
Why changing the password is the only cure
When a server is compromised, our reflexes are well drilled: isolate the machine, apply the patch, change the passwords. With a Golden Ticket that reflex isn't enough, because what the attacker holds isn't a session — it's the key itself. You could delete the domain admin account, pretend it never existed, and they would keep minting tickets.
Microsoft Defender for Identity's alert family for this behaviour shows how many faces the attack has: ticket usage against a nonexistent account (2027), ticket anomaly (2032), ticket anomaly using RBCD (2040), encryption downgrade (2009), and time anomaly (2022). That last one is my favourite piece of detection logic: the forged TGT gets caught because its validity exceeds the maximum lifetime the domain allows. The attacker gets caught for being too generous to themselves.
One distinction is worth drawing sharply here, because folklore tends to blur into the source at this point: MDI's alert page does not prescribe "reset krbtgt" for each of these five alerts; the only prevention step it documents is patching legacy servers, for 2009. But the same object sits at the root of all five. If the key leaked, the cure runs through changing it — and, as you'll see below, not once but twice.
Twice, ten hours apart: where the numbers come from
The folklore of this job carries the phrase "reset krbtgt twice," usually without the reasoning. Both numbers behind it are written plainly in Microsoft's forest recovery documentation.
First: the krbtgt account's password history value is 2. Active Directory keeps the two most recent passwords for this account, and the old key can still be used to validate a ticket. Reset once and the attacker's key is in the past — but still accepted. Reset twice and the history is cleared. The documentation frames the reason through replication: by resetting the password twice you close off any way for another DC to replicate with this DC using an old password. Forged tickets dying is a consequence of the same mechanism.
Second: you must wait 10 hours between the two resets. Those 10 hours aren't an arbitrary safety margin; they're the default value of the "Maximum lifetime for user ticket" and "Maximum lifetime for service ticket" Kerberos policy settings. That is, the natural lifespan of the legitimate tickets circulating in your environment. Skip the wait and you pull the rug out from under users still holding valid tickets.
The critical detail: if you changed that policy, the wait changes too. The documentation is explicit — where the maximum lifetime has been changed, the minimum waiting period between resets should be greater than the configured value. If your domain drops tickets to 4 hours, 10 hours is more than enough; if someone raised it to 24 hours because "users keep re-authenticating," a 10-hour wait walks you straight into the outage you were trying to avoid. Don't set the schedule before you measure the policy.
One detail surprises first-timers: what you type into the password field doesn't matter. The system generates a strong password on its own, independent of what you specify.
2026 changed the stakes: RC4 is off
Everything so far was equally true five years ago. Here's what's new: the krbtgt key isn't only a secret — it's also a set of encryption algorithms.
When an account's password changes, Windows regenerates that password's material for every supported algorithm. That's the rule in Microsoft's RC4 guidance: accounts created before AES-SHA1 support whose passwords were never reset are missing AES-SHA1 keys, and changing the password generates them.
Now apply that sentence to the oldest account in your domain — but don't assume, measure. In plenty of environments krbtgt's key material was regenerated at some point along the way; events such as functional level upgrades can change this account's password without anyone noticing. One line tells you where your own domain stands:
Get-ADUser krbtgt -Properties PasswordLastSet, msDS-SupportedEncryptionTypes, whenCreated |
Format-List Name, whenCreated, PasswordLastSet, msDS-SupportedEncryptionTypes
If PasswordLastSet and whenCreated show the same day, this account's password has never changed since the domain was built. Compare the msDS-SupportedEncryptionTypes value against the table in the RC4 guidance — 0x18 means AES 128 and AES 256 only.
The calendar is settled too. The change under CVE-2026-20833 rolled out in three phases: the initial deployment phase started with updates released on and after 13 January 2026, bringing audit warnings; the 14 April 2026 updates changed the KDC's default DefaultDomainSupportedEncTypes to AES-SHA1 (0x18), dropping RC4 from the assumed supported types; and updates released in or after July 2026 removed support for the RC4DefaultDisablementPhase registry value used to roll back. So as of September 2026, the phase lever is no longer in your hands.
A correction, so you read this right: none of it means RC4 is fully gone from your domain. What changed is the default — RC4 is now used only if you explicitly configure an account or the KDC to permit it. You can still allow it per account through msDS-SupportedEncryptionTypes, or at the KDC through DefaultDomainSupportedEncTypes. But now you have to do it deliberately, one decision at a time; the silent fallback is over.
The practical consequence: krbtgt rotation, which sat for years in the "important but not urgent" box, is now part of authentication continuity.
Where to look before you rotate
There's an official way to measure the wider environment too: the MSDS-SupportedEncryptionTypes and Available Keys fields in event 4768 (TGT request) and 4769 (service ticket request) tell you which account holds which keys. Microsoft published the List-AccountKeys.ps1 and Get-KerbEncryptionUsage.ps1 scripts that mine these events as open source.
Read two warnings alongside them. The documentation notes these are processed values, and that RC4 is shown in Available Keys regardless of usage; on Windows Server 2022 and earlier, msDS-SupportedEncryptionTypes always shows DES and RC4 regardless of your settings. Also, krbtgt doesn't appear in these events as the account — it appears in the Service Information section, as the target of the AS-REQ. If you're after krbtgt's own key set, the one-liner above gives a more honest answer.
Learn to recognise the failure mode too: after RC4 is switched off, when a client can't authenticate, event 4769 on the KDC shows failure code 0xE. That maps to KDC_ERR_ETYPE_NOTSUPP — the KDC doesn't support the requested encryption type. It surfaces as failing to reach an SMB share or failing to open a remote session with New-PSSession; both look like network problems at first glance, and both will eat your afternoon.
The rotation itself has three traps:
Read-only domain controllers. RODCs have their own krbtgt accounts, named in the krbtgt_<number> format. If you plan to recover RODCs during a forest recovery, you must not delete those accounts. The procedure documented for writeable DCs doesn't apply to RODCs directly; if you have RODCs, plan them as a separate work item rather than squeezing them into the main rotation.
Custom password filters. If a customised password filter such as passfilt.dll runs on a DC, you might get an error when resetting the password. Microsoft's documented workaround is a change in the filter's own code — testing for random data, or special-casing the krbtgt account name. If you wrote the filter it's a coding task; if you bought it, it's a ticket with the vendor. Either way it's a dependency to clear in advance, not something to solve at midnight.
Dead but undeleted DCs. The New-KrbtgtKeys.ps1 script Microsoft recommended for years was archived on GitHub on 8 March 2024, and the archive notice states that development of the project has come to an end. The same notice carries an honest warning: the code, while functional, did not handle retired DCs that were offline but had not been completely removed from Active Directory — and it points to maintained forks. If your environment still has an object for a domain controller that was unplugged years ago, replication validation can mislead you. If you go the script route, clean up the metadata first and use the maintained version the notice points to, not the archived one.
A routine rotation and a post-breach rotation are not the same job
Everything above describes planned maintenance. If you suspect a breach the equation changes, and planning without separating the two leads you to the wrong decision in both.
In a planned rotation your priority is continuity: you wait one full ticket lifetime between the two resets, users notice nothing, the day passes normally. The wait isn't a cost here — it's how the job is done correctly.
If you believe an attacker holds the key, those same 10 hours mean something else entirely: forged tickets stay valid for the duration. Waiting for the second reset hands the attacker another half day. Set the trade-off honestly. It's clear who pays the price of invalidating live tickets early: long-lived service sessions, scheduled tasks that pick up a TGT in the morning and carry it all day, application pools reluctant to re-establish authentication, and integrations that run across cross-domain trust relationships. In my view the call during a known breach should be fast invalidation — provided that list was drawn up before the incident. If you're starting to wonder "what will break" mid-incident, you skipped the preparation.
Know the point of no return, too: after the second reset the old key is gone from the history. You still have a safety net after the first reset; after the second you don't. If you're going to validate, validate in that window.
One last check before the second reset, especially in multi-site environments: replication convergence. The new key must have reached every writeable domain controller. If a DC at a remote branch fell behind — slow site link, or it was simply switched off that day — your second reset leaves it holding a key set nobody recognises. Read the waiting period from replication state rather than the clock; continue because every DC has the new key, not because the hours have elapsed.
A decision framework
Work through your environment in this order:
-
Measure. Run the one-liner above. If
PasswordLastSetandwhenCreatedfall on the same day, this job is yours. - Read the policy. What's the maximum ticket lifetime in your Kerberos policy? The default is 10 hours, with a 7-day renewal default. If it was changed, your waiting period changes with it.
- Take inventory. Any RODCs? Any retired DCs whose objects still exist? Which accounts carry your trust relationships? Is replication healthy?
- Pick the window. At least one full ticket lifetime sits between the two resets — in practice, maintenance spanning two working days. The reset itself is documented and plain: in Active Directory Users and Computers, enable Advanced Features, reset the password on the krbtgt account, then do it once more when the waiting period is up. If you go the script route, use the maintained version the archive notice points to.
- Set the date. All three RC4 phases are behind us; there's no milestone left to wait for. Run the measurement this week, put the first reset in your next maintenance window and the second on the following working day. After that, start at twice a year and settle into whatever tempo the organisation can sustain — the real benefit of rotation is its regularity. Microsoft doesn't mandate an interval, so choosing one is your job; trying it for the first time during an incident means learning at the worst possible moment.
One more preference: plan this not as a standalone "security project" but as one line item among identity-hygiene work, like moving to the Active Directory tier model. Security tasks that stand alone get deferred; the ones that belong to a programme get done.
The account nobody wants to touch
While preparing this article I wanted a real data point from an environment I manage: I was going to ask a domain controller when the krbtgt password was last changed. A read-only query, one line of PowerShell.
The bridge platform I built myself refused to run it and pushed it to approval. I tried twice and produced two approval records. My own security gate told my own query: you're touching that account, not without operator approval.
I wasn't annoyed; it was the right call. But it also summarises this article's subject a little too well. krbtgt is the kind of account that even systems consider risky to look at. Because everyone keeps their distance, because no audit report ever lights up red for it, because no user ever complains about it, that password stays exactly as it was on the day the domain was built.
Your domain's oldest secret isn't its best-kept one; it's just the forgotten one. As someone who has lived through the cost of depending on a single domain controller, I can tell you: in infrastructure, "it has never caused a problem" isn't a record of reliability. It's an assumption that simply hasn't been tested yet.
Top comments (0)