How to Reset the krbtgt Password Safely (Nessus 150484, PingCastle A-Krbtgt)

The Nessus finding “AD Starter Scan – Kerberos Krbtgt” (plugin 150484) and PingCastle rule A-Krbtgt mean the krbtgt account, whose key signs every Kerberos ticket in the domain, has an old password. To fix it, reset the krbtgt password twice, waiting at least the maximum ticket lifetime (10 hours by default) and confirming replication in between.

The reset takes a few clicks. The care goes into timing and replication.

What the scanner is actually detecting

This is an age check on one attribute, not a missing patch. Each tool reads the pwdLastSet value of the domain’s krbtgt account and compares it with its own threshold.

The thresholds disagree, so one domain can pass Nessus and fail Defender for Identity. Microsoft’s field FAQ sets no fixed interval and suggests planning one around backup schedules and security requirements.

Real-world risk

The krbtgt account is disabled and never signs in. The Key Distribution Center (KDC) uses keys derived from its password to encrypt and sign ticket-granting tickets. Anyone who holds that key can forge a ticket for any user with any group membership: the Golden Ticket technique (MITRE ATT&CK T1558.001).

An old password does not let anyone in on its own. The attacker first needs the key, which takes domain-level access: replication rights used for DCSync, code execution on a domain controller, or a copy of NTDS.dit. The age decides how long a stolen key stays useful: as PingCastle’s rule text notes, any backup taken since the last change can be used to mint Golden Tickets.

The limit matters too: if an attacker still controls a DC or holds replication rights, they can read the new key the same way. Microsoft’s FAQ calls the reset one part of a recovery plan, not the plan.

How to confirm it on the host

Run these on a DC or a host with the RSAT Active Directory module:

Import-Module ActiveDirectory
Get-ADUser -Identity krbtgt -Properties PasswordLastSet, msDS-KeyVersionNumber |
    Select-Object Name, Enabled, PasswordLastSet, msDS-KeyVersionNumber

Write down msDS-KeyVersionNumber. It goes up by one with every password change, so after the fix it should be two higher. To see every krbtgt-style account, including RODC accounts:

Get-ADUser -Filter 'SamAccountName -like "krbtgt*"' -Properties PasswordLastSet |
    Select-Object SamAccountName, Enabled, PasswordLastSet

Without the module, net user krbtgt /domain shows the same date on the “Password last set” line. In a multi-domain forest each domain has its own krbtgt, so add -Server child.contoso.com to check the domain named in the finding.

How to reset krbtgt password without breaking authentication

Pre-checks

1. Replication must be healthy. Run repadmin /replsummary and fix any failures first. For detail, use repadmin /showrepl * /csv > showrepl.csv.
2. No ghost domain controllers. Microsoft’s README for its archived script warns that it errors on retired DCs that are offline but still in Active Directory. Complete metadata cleanup for those first.
3. Know your ticket lifetime. In GPMC, open the Default Domain Policy at Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Kerberos Policy > Maximum lifetime for user ticket. The default is 10 hours. If yours is higher, wait longer than that value between resets.

Option 1: the reset script (recommended)

Microsoft published New-KrbtgtKeys.ps1 on GitHub, but the project is no longer maintained. Its README points to maintained successors, including Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 by the engineer who rewrote the Microsoft version. The script resets the password on one writable DC, then checks every reachable DC until the new pwdLastSet value arrives.

Run it from an elevated PowerShell 5.1 or later session (not ISE) with the Group Policy module, as a Domain Admins member. The recommended order is information mode, test krbtgt accounts, canary replication test, test-account reset, then production reset. Mode numbers differ between versions (mode 4 is the real reset in the archived Microsoft copy but a test-account reset today), so choose by name:

# Interactive menu, read the impact notes once
.Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1

# Replication test with a temporary canary object, no password change
.Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 -noInfo -modeOfOperation simulModeCanaryObject -targetedADforestFQDN contoso.com -targetedADdomainFQDN contoso.com -targetKrbTgtAccountScope allRWDCs -continueOps

# One real reset of the krbtgt used by all writable DCs
.Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 -noInfo -modeOfOperation resetModeKrbTgtProdAccountsResetOnce -targetedADforestFQDN contoso.com -targetedADdomainFQDN contoso.com -targetKrbTgtAccountScope allRWDCs -continueOps

Run the last command a second time after the wait. When the script runs with parameters and tickets issued under the previous key could still be valid (maximum ticket lifetime plus twice the maximum clock skew), it skips the reset instead of forcing it.

Option 2: manual reset

Microsoft’s documented procedure covers writable DCs:

1. Open Active Directory Users and Computers and select View > Advanced Features.
2. Open the domain container and select Users.
3. Right-click krbtgt, select Reset Password, enter and confirm a password, then select OK. Microsoft notes the value you type does not matter, because the system generates a strong password on its own.

The PowerShell equivalent, pinned to the PDC emulator:

$pdc = (Get-ADDomain).PDCEmulator
Set-ADAccountPassword -Identity krbtgt -Server $pdc -Reset -NewPassword (Read-Host -AsSecureString "Any value")

Confirm replication with the verification command below, wait at least 10 hours (or your configured lifetime), then reset again. If a custom password filter such as passfilt.dll blocks the reset, see Microsoft KB 2549833.

RODCs, other domains and Entra Kerberos

• Each read-only DC uses its own krbtgt_<number> account, linked through msDS-KrbTgtLink, and its tickets are only valid at that RODC. The manual procedure does not cover them; the script does with -targetKrbTgtAccountScope allRODCs.
• Every domain in the forest has a separate krbtgt. Reset each domain the finding names.
• If you use Microsoft Entra Kerberos, the krbtgt_AzureAD object is rotated with Set-AzureADKerberosServer and its -RotateServerKey parameter, not by the domain reset.

Make it routine

Choose an interval shorter than the strictest threshold you report against, and do a double reset after any suspected compromise, once the attacker’s access is removed. The maintained script can run from a scheduled task with a reset routine in its XML configuration file. Review the rest of your DC baseline with our Windows Server hardening checklist.

How to verify the fix and rescan

After each reset, confirm every DC holds the same pwdLastSet version:

$dn = (Get-ADUser -Identity krbtgt).DistinguishedName
Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    Get-ADReplicationAttributeMetadata -Object $dn -Server $dc -Properties pwdLastSet |
        Select-Object @{n='DC';e={$dc}}, Version, LastOriginatingChangeTime
}

All rows should show the same Version and time. A DC that errors or lags is the one to fix before the second reset. After both resets, msDS-KeyVersionNumber should be two higher than your baseline.

• Nessus: rerun the AD Starter Scan with the same Active Directory credentials; plugin 150484 needs LDAP enumeration to work.
• PingCastle: run PingCastle.exe –healthcheck –server contoso.com. The A-Krbtgt rationale shows days since the last change.
• Defender for Identity: exposed entities update within minutes, but Microsoft notes scores and statuses refresh every 24 hours.

What can break and how to roll back

There is no rollback: you cannot restore a previous krbtgt password. What protects you is the password history of two. After the first reset, tickets signed with the old key still work; the second reset removes that key, so time it carefully.

• Unreplicated DCs: a DC without the new key cannot decrypt tickets issued by one that has it, causing TGS request failures and failed KDC PAC validation. PingCastle warns that two unreplicated changes can break domain controllers.
• Resets too close together: the second reset drops the original key, so any ticket issued before the first reset that has not yet expired stops working, and users and services get Kerberos errors until they obtain new tickets.
• Non-Windows clients: Microsoft’s FAQ reports that some cannot request new tickets until their existing ones expire.
• DC load: the FAQ notes that LSASS on domain controllers can spike as clients reauthenticate.
• Old DC backups: restoring a single DC from a backup taken before the resets will not work; promote a new DC instead.

To recover, fix replication first. On an affected client, purge the user’s tickets and the computer’s own session (LUID 0x3e7), or reboot it:

klist purge
klist purge -li 0x3e7

Common false positive reasons

• Rescanned too early: the scan read a DC that had not received the change yet, or Defender for Identity has not refreshed its 24-hour status.
• Wrong domain: the finding names a child domain whose krbtgt was never reset.
• Other krbtgt accounts: tools that list every account matching krbtgt may include RODC accounts or krbtgt_AzureAD, which the domain reset does not touch.
• The reverse case: a single reset clears every date check while the old key stays in the history. Only msDS-KeyVersionNumber proves you reset twice.

FAQ

Will a krbtgt reset sign users out?

Not usually. With healthy replication and a gap of at least the ticket lifetime, existing tickets keep working; Microsoft’s FAQ says a gap of 10 hours or more may minimize the impact significantly.

How often should I reset the krbtgt password?

Microsoft sets no fixed interval. Defender for Identity flags more than 180 days, PingCastle more than a year and Nessus more than two years; stay under the strictest one you report against.

Can I still use New-KrbtgtKeys.ps1?

It works, but Microsoft no longer maintains it and its README notes it fails when an offline DC is still in Active Directory. Prefer a maintained successor.

Does a reset remove an attacker who already has Domain Admin?

No. Anyone who can still replicate secrets or run code on a DC can take the new key, so remove that access first. LSASS protection with RunAsPPL is one control that makes credential theft harder.

Tracking this finding across many domains

In a multi-domain forest this finding repeats per domain. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners, with Nessus results brought in by uploading a .nessus export, and merges duplicates within each scanner but not across scanners. Per-finding retest is available for Nessus findings, so plugin 150484 can be rechecked per domain after the second reset.

Sources

• Tenable: Nessus plugin 150484, AD Starter Scan – Kerberos Krbtgt
• Microsoft Learn: AD Forest Recovery, reset the krbtgt password
• Microsoft Learn: Defender for Identity accounts security posture assessments
• Microsoft Tech Community: FAQs from the Field on KRBTGT Reset
• Microsoft on GitHub: New-KrbtgtKeys.ps1 (archived, links to maintained versions)