The Active Directory Maintenance Task Most Hospitals Are Not Doing: Rotating the krbtgt Password

There is an account in every Active Directory domain that most administrators never think about. It was created automatically when the domain was built. It cannot be deleted. Its password has probably never been changed. And it is the single most powerful account in your environment.

The account is called krbtgt. It is the service account for the Kerberos Key Distribution Center (KDC), and it is responsible for encrypting and signing every single Kerberos Ticket Granting Ticket (TGT) issued in your domain. The account is disabled by default and cannot be enabled, and it is not used for interactive logon. But that does not mean it is inactive. Every time a user logs in, every time a service authenticates, every time a workstation accesses a file share, the krbtgt account's password hash is involved behind the scenes.

If an attacker obtains the password hash for this account, they can forge their own Kerberos tickets that look completely legitimate to every domain controller in your environment. These forged tickets, known as Golden Tickets, can grant administrative access to any resource in the domain, persist even after user passwords are changed, and remain valid until the krbtgt password itself is rotated.

The security recommendation is straightforward: rotate the krbtgt password at least every 180 days. There is no single Microsoft KB article that mandates exactly 180 days for every environment, but the interval is consistently reinforced across the security ecosystem. The CIS Benchmarks for Windows Server include this as a specific control. Microsoft Defender for Identity flags any krbtgt account with a password older than 180 days as a security finding. The DoD STIG for Active Directory domain controllers requires the same. And Microsoft's own community guidance and support documentation consistently reference 180 days as the recommended maximum.

And yet, in environment after environment, the krbtgt password has not been changed since the domain was created. Sometimes that means it has been sitting untouched for five, ten, or even fifteen years.

Why Most Organizations Do Not Do This

The honest answer is that most AD administrators do not know this is something they are supposed to do. The krbtgt account is not something you interact with in day-to-day administration. It does not show up in your normal user management workflows. It does not expire. It does not generate alerts (unless you have Defender for Identity or a similar tool configured). It just sits there, quietly doing its job, with the same password it has had since the domain was stood up.

There is also a reasonable hesitation factor. The krbtgt account touches every Kerberos authentication in the domain. The idea of resetting its password sounds risky, and the consequences of doing it wrong can be severe. So most administrators take the "if it is not broken, do not touch it" approach.

The problem is that an unchanged krbtgt password is not "not broken." It is an open window that you just have not noticed yet.

What a Golden Ticket Attack Actually Looks Like

To understand why the krbtgt password matters, it helps to understand what an attacker can do with it.

In a standard Kerberos authentication flow, when a user logs in, the domain controller issues a TGT encrypted with the krbtgt password hash. That TGT is the user's proof of identity for the duration of their session. When they need to access a resource (a file share, a database, an application), they present their TGT and get a service ticket for that specific resource.

In a Golden Ticket attack, an attacker who has obtained the krbtgt hash does not need to go through the domain controller at all. They can craft their own TGT offline, set whatever username they want, assign themselves any group memberships (including Domain Admins), set the ticket lifetime to whatever they choose (attackers commonly set it to 10 years), and present it to any domain controller. The DC has no way to tell the difference between this forged ticket and a legitimate one because it is encrypted with the same key.

The result is persistent, undetectable access to every resource in the domain. Changing user passwords does not help because the attacker is not using user passwords. Disabling accounts does not help because the attacker can forge tickets for any account, including ones that do not exist. The only way to invalidate a Golden Ticket is to rotate the krbtgt password, which changes the encryption key and makes all previously forged tickets useless.

How to Check Your krbtgt Password Age

Before you do anything, find out when your krbtgt password was last set:

Get-ADUser -Identity "krbtgt" -Properties PasswordLastSet, Created |
    Select-Object Name, PasswordLastSet, Created

If the PasswordLastSet date matches (or is very close to) the Created date, the password has never been changed since the domain was built. If it was changed at some point but the date is more than 180 days ago, it is overdue for rotation.

The Safe Rotation Process

Rotating the krbtgt password is not complicated, but it does require patience. The single most important thing to understand is that you must do it in two resets with a waiting period between them, and rushing the process can cause a domain-wide authentication outage.

Here is why the two-reset process exists and how it works.

How Active Directory Handles krbtgt Passwords

Active Directory keeps two krbtgt passwords at all times: the current one (N) and the previous one (N-1). The KDC will accept TGTs encrypted with either password. This is the built-in safety mechanism that makes rotation possible without instantly invalidating every Kerberos ticket in the domain.

When you reset the krbtgt password:

The current password (N) becomes the previous password (N-1).
The new password becomes the current password (N).
Any TGT encrypted with the old N still works because it is now N-1, which DCs still honor.
Any TGT encrypted with whatever was previously N-1 is now invalid because it has fallen off entirely.

This is why two resets are needed to fully invalidate old tickets. The first reset pushes the old password to N-1 (still valid). The second reset pushes it to N-2 (gone).

Step-by-Step Process

Step 1: Verify AD replication health before you start.

Do not rotate the krbtgt password if your domain has replication problems. The new password needs to replicate to every domain controller, and if replication is broken, some DCs will have the new password while others still have the old one. That mismatch will cause authentication failures.

repadmin /replsummary

If this shows any failures, fix your replication first.

Step 2: Perform the first reset during a low-activity window.

Evening or weekend is ideal. The recommended approach is to use the community-maintained Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 script, which has built-in simulation modes, replication health checks, RODC handling, and safety gates that prevent you from doing the second reset too quickly. Download the script, run it from a domain controller or management server, and start with the simulation option (Option 5) to see exactly what will happen before you commit. When you are ready, use Option 6 to perform the actual reset.

The script handles the password generation for you. The actual password value does not matter because nobody ever types the krbtgt password manually. It is only used internally by the KDC.

If you prefer a more hands-on approach or want to understand exactly what is happening under the hood, you can also reset the password manually with Set-ADAccountPassword:

Set-ADAccountPassword -Identity "krbtgt" -Reset -NewPassword (ConvertTo-SecureString "YourNewComplexPassword1!" -AsPlainText -Force)

The manual method works fine, especially in smaller domains with a couple of DCs, but it does not give you the simulation mode or the built-in safety checks that the script provides. For most environments, the script is the better choice.

Step 3: Verify replication completed.

repadmin /replsummary

Confirm zero failures. Every DC needs to have the new password before you proceed.

Step 4: Wait.

This is the step people skip, and it is the step that matters most. You need to wait long enough for the majority of existing TGTs to expire and be renewed naturally. The default TGT lifetime in Active Directory is 10 hours, and the maximum renewal lifetime is 7 days.

At minimum, wait 10 hours. Ideally, wait 24 hours. Some organizations wait a full week between resets for maximum safety. The longer you wait, the fewer users will have stale tickets when the second reset happens.

One important caveat: this wait period is for routine, planned rotation. If you are performing an emergency rotation because you suspect an active compromise or Golden Ticket attack, the calculus is different. In a breach recovery scenario, doing both resets in rapid succession is the right call because invalidating the attacker's access immediately is more important than avoiding a round of user re-authentication prompts. Everyone getting prompted to log back in is a small price compared to an attacker maintaining persistent domain access.

Step 5: Perform the second reset during another low-activity window.

Run the reset script again (Option 6) or, if using the manual method:

Set-ADAccountPassword -Identity "krbtgt" -Reset -NewPassword (ConvertTo-SecureString "YourNewComplexPassword2!" -AsPlainText -Force)

Step 6: Verify replication again.

repadmin /replsummary

Step 7: Monitor for authentication issues.

After the second reset, any TGT that was still encrypted with the original (pre-first-reset) password will fail. The user or service will need to re-authenticate and get a new TGT. In most cases, this happens transparently. The user might get a brief password prompt and then continue working normally.

If a service breaks, restarting the service will force it to obtain a fresh Kerberos ticket.

What Users Will Actually Experience

In most cases, nothing. If you waited long enough between the two resets (and you should have), the vast majority of TGTs will have already been renewed with the new key. Users whose tickets did cycle naturally will not notice a thing.

The small percentage of users who happen to have a stale ticket when the second reset hits will get prompted to re-enter their credentials. This is not a lockout. It is a re-authentication. They type their password, get a new TGT, and continue working.

To be direct about it: the risk with krbtgt rotation is not the rotation itself. It is doing it with broken replication or without waiting between resets. Those are the scenarios that cause domain-wide authentication problems. Follow the steps, verify replication, wait, and the process is uneventful.

Considerations for Health Care Environments

Health care environments have a few specific scenarios worth thinking about before you schedule the rotation.

Remote Desktop Services and Citrix sessions. Clinicians who stay logged into RDS or Citrix sessions for extended periods may have TGTs that are older than your wait window between resets. If their TGT was issued before the first reset and has not been renewed by the time you do the second reset, their session could get disconnected. They would need to log back in. This is temporary and not destructive, but it is disruptive if it happens during a patient encounter. Schedule both resets during off-peak hours to minimize this.

Kerberos constrained delegation. If your EMR or other clinical applications use Kerberos constrained delegation (where one service authenticates on behalf of a user to a backend resource), those delegation chains may need a service restart after the second reset to pick up fresh tickets. Know which services in your environment use delegation before you start.

FSLogix profile containers. If you use FSLogix for roaming profiles on SMB file shares, the profile mount uses Kerberos. A stale TGT after the second reset could cause a profile to fail to mount at next logon. The user would get a temporary profile and would need to log out and back in to get their normal profile. Again, temporary, but worth knowing about.

Hybrid environments. If you use Microsoft Entra Hybrid Cloud Trust (formerly Azure AD Hybrid Cloud Trust) for Windows Hello for Business, your domain also has a krbtgt_AzureAD account in addition to the standard krbtgt. Do not reset the krbtgt_AzureAD account using the same process. That account's password has to be coordinated between on-premises AD and Entra ID using the AzureADHybridAuthenticationManagement PowerShell module with the Set-AzureADKerberosServer cmdlet and the -RotateServerKey parameter. The standard krbtgt reset scripts will skip this account by design, but it is worth being aware of so you do not confuse the two.

How to Make This Routine

Once you have done the rotation once and seen that the impact is minimal (which it will be if you follow the process), the goal is to make it a recurring task rather than a once-in-a-career event.

Set a calendar reminder for every 180 days. Document the date of each rotation. The process takes about 15 minutes of active work spread across two maintenance windows, and the security benefit is significant.

Some organizations automate the monitoring side using Microsoft Defender for Identity, which will flag the krbtgt password age and alert when it exceeds 180 days. If your environment does not have Defender for Identity, a simple scheduled PowerShell script that checks the PasswordLastSet attribute and sends an email when it exceeds your threshold works just as well.

The Bigger Picture

The krbtgt rotation is one of those maintenance tasks that falls into a category we see frequently in health care IT: things that are well-documented, not particularly difficult, but simply not on anyone's radar because nobody told them it was a thing.

The solo IT admin at a 25-bed Critical Access Hospital has a hundred things competing for their attention on any given day. Password rotation for an account they have never interacted with is not going to make the list unless someone points it out. That is what this article is for.

If you recently worked through the Microsoft RC4 Kerberos enforcement changes and noticed your krbtgt PasswordLastSet date was old, this is the logical next step. And if you have not looked into the RC4 changes yet, that is worth your attention too, because the April 2026 enforcement deadline is imminent.

For health care organizations where Active Directory maintenance tasks like these are difficult to keep up with alongside everything else, this is exactly the kind of ongoing infrastructure hygiene that a managed services partnership can help with. Whether that is an internal process improvement, an MSP relationship, or bringing in specialized support, the important thing is that routine security maintenance does not keep falling to the bottom of the list.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.

Sources