# Reset krbtgt Password Safely: Two Resets, Replication and RODCs

Source: https://srvscripts.com/guides/reset-krbtgt-password-safely/
Updated: 2026-10-06
Publisher: srvScripts (https://srvscripts.com/)

**Short answer:** Reset the domain’s `krbtgt` password twice, with a wait between the two resets that is longer than your maximum Kerberos ticket lifetime (10 hours by default), and only after confirming every writable DC has replicated the first reset. The first reset is harmless because DCs still accept the previous key; the second reset invalidates all tickets signed with the old keys, which is what kills forged “golden tickets”. RODCs use their own `krbtgt_<number>` accounts that you reset separately.

We ran these commands on 6 October 2026 on a Windows Server 2025 Standard domain controller (build 26100.33438, September 2026 update, Windows PowerShell 5.1) and a Windows 11 Pro member PC in our lab domain `contoso.com`. Where the lab result differed from the documentation, the page says so.

## Why the krbtgt password matters and when to reset it

Every Kerberos ticket-granting ticket (TGT) in an Active Directory domain is encrypted and signed with keys derived from the password of the `krbtgt` account. Anyone who obtains those keys (for example, by dumping the AD database from a compromised DC) can mint TGTs for any user, with any group membership, valid for as long as they like. That is a golden ticket, and it survives password resets of every other account.

Reset the krbtgt password:

- After any suspected compromise of a domain controller, of Domain Admin credentials, or of an AD backup (NTDS.dit or system state).

- As part of Active Directory forest recovery; Microsoft’s forest recovery guide includes it as a standard step.

- When people who had domain-level admin rights leave the organisation.

- Periodically, on the schedule your security policy sets. Many environments have never rotated it since the domain was created; check `PasswordLastSet` below.

Why twice? The krbtgt account keeps a password history of two, and DCs accept tickets signed with either the current or the previous key. One reset leaves the old key valid as “previous”. The second reset pushes it out of history. That is also why the first reset causes no outage: existing tickets still validate against the previous key.

## Before you start: checks that prevent an outage

Run these from a machine with the ActiveDirectory module (RSAT) as a Domain Admin.

```
Import-Module ActiveDirectory

# When was krbtgt last reset, and what key version is it on?
Get-ADUser krbtgt -Properties PasswordLastSet, msDS-KeyVersionNumber |
    Select-Object Name, PasswordLastSet, msDS-KeyVersionNumber

# Every DC in the domain, writable and read-only
Get-ADDomainController -Filter * |
    Select-Object HostName, Site, IsReadOnly, OperatingSystem | Sort-Object Site, HostName

# The PDC emulator (where you will make the change)
(Get-ADDomain).PDCEmulator
```

Then make sure replication is healthy. A DC that has not replicated the first reset will reject tickets after the second one:

```
repadmin /replsummary
repadmin /showrepl * /errorsonly
```

Fix any replication error first; see [dcdiag and repadmin health check](/guides/dcdiag-repadmin-dc-health-check/) and [replication errors 1722 and 8453](/guides/ad-replication-error-1722-8453/). Remove any DC that is permanently offline but still in AD with metadata cleanup ([guide](/guides/demote-domain-controller-metadata-cleanup/)) before you continue.

Finally, confirm the ticket lifetime you need to wait out. The setting is Maximum lifetime for user ticket in the Default Domain Policy under Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy. The default is 10 hours. If yours is longer, the wait between resets must be longer than that value.

Have a current, tested system state backup of at least one DC per domain before changing krbtgt. A reset itself is low risk, but you want a known-good restore point any time you touch domain-wide security principals.

## Option 1: Microsoft’s New-KrbtgtKeys.ps1 script

Microsoft published a script, `New-KrbtgtKeys.ps1` (originally by Jared Poeppelman, rewritten by Jorge de Almeida Pinto), that resets the key in a controlled way and checks replication of the change to every DC. Its value is the checking: it resets on the PDC emulator, then confirms each reachable DC has the new `pwdLastSet` value.

Its modes, from the script’s own help:

| Mode | What it does | Changes anything? |
| --- | --- | --- |
| 1 | Informational: lists RWDCs and RODCs and checks reachability and prerequisites | No |
| 2 | Simulation: creates a temporary canary contact object and measures how long it takes to replicate | Temporary object only |
| 8 | Creates disabled test krbtgt accounts (krbtgt_TEST, and krbtgt__TEST per RODC) | Creates test accounts |
| 3 | Resets the test krbtgt accounts and monitors replication | Test accounts only |
| 4 | Resets the real krbtgt account (or an RODC’s krbtgt) and monitors replication | Yes |
| 9 | Deletes the test krbtgt accounts | Removes test accounts |

A sensible run: mode 1, then 2, then 8 and 3 to rehearse, then 4 for the real reset, wait out the ticket lifetime, run 4 again, then 9 to clean up.

Microsoft has ended development of this script. The repository README (now under the `microsoftarchive` GitHub organisation) says it was maintained in spare time, is no longer updated, and errors on DCs that are offline but still present in AD. It points to community-maintained newer versions. Read whichever version you choose before running it, and run mode 1 first in your own domain.

## Option 2: reset manually with PowerShell or ADUC

The manual method is what Microsoft’s forest recovery guide documents, and it is fine for a small domain if you do the replication checks yourself.

- Connect to the PDC emulator.

- Reset the password once (the value you type does not matter: the DC generates a strong password itself).

- Force and verify replication to every DC.

- Wait longer than the maximum ticket lifetime (more than 10 hours by default).

- Repeat the reset and the replication check.

```
$pdc = (Get-ADDomain).PDCEmulator

# Reset 1 (the DC replaces this with its own strong random value)
$pw = ConvertTo-SecureString ([guid]::NewGuid().ToString() + 'Aa1!') -AsPlainText -Force
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword $pw -Server $pdc

# Push the change to all DCs in all sites
repadmin /syncall $pdc /APed
```

In our single-DC lab the reset worked (the key version went from 2 to 3 and `PasswordLastSet` updated), but `repadmin /syncall` had no partner to push to and ended with error 8440. With two or more DCs you should instead see each partition sync without errors before the second reset.

In Active Directory Users and Computers: enable **View > Advanced Features**, open the **Users** container, right-click **krbtgt** > **Reset Password**, enter any value twice and click OK.

If a custom password filter DLL is installed on your DCs, the reset can fail; Microsoft’s forest recovery article points to KB 2549833 for that case.

## Confirm replication between the two resets

Check that every DC reports the same `PasswordLastSet` for krbtgt before you start the wait:

```
Get-ADDomainController -Filter { IsReadOnly -eq $false } | ForEach-Object {
    $u = Get-ADUser krbtgt -Properties PasswordLastSet, msDS-KeyVersionNumber -Server $_.HostName
    [pscustomobject]@{
        DC              = $_.HostName
        PasswordLastSet = $u.PasswordLastSet
        KeyVersion      = $u.'msDS-KeyVersionNumber'
    }
} | Format-Table -AutoSize
```

All writable DCs should show the same time and key version. Any DC with the old value has not replicated: fix that before you do the second reset, or users authenticating against that DC will fail once the second reset arrives.

You can also check the replication metadata of the password attribute directly:

```
repadmin /showobjmeta * "CN=krbtgt,CN=Users,DC=contoso,DC=local"
```

Look at the `unicodePwd` line on each DC: the version number should match everywhere.

Do the second reset only after the wait. Resetting twice in quick succession invalidates every TGT in the domain at once: users, services and computers have to get new tickets, and some services hold tickets and fail until restarted. Only shorten the wait as a deliberate incident-response decision, after accepting that disruption.

## RODC krbtgt accounts

Each read-only DC has its own krbtgt account named `krbtgt_<number>`, linked from the RODC’s computer object through the `msDS-KrbTgtLink` attribute. TGTs issued by an RODC are signed with that account’s key, so the domain krbtgt reset does not cover them, and an RODC krbtgt reset only affects tickets issued by that one RODC.

```
# List the RODC krbtgt accounts and when they were last reset
Get-ADUser -Filter 'Name -like "krbtgt_*"' -Properties PasswordLastSet |
    Select-Object Name, PasswordLastSet

# Which account belongs to which RODC
Get-ADDomainController -Filter { IsReadOnly -eq $true } | ForEach-Object {
    Get-ADComputer $_.Name -Properties msDS-KrbTgtLink |
        Select-Object Name, msDS-KrbTgtLink
}
```

Reset an RODC’s krbtgt the same way (twice, with the wait), either with mode 4 of the script scoped to RODCs or manually on a writable DC. Never delete `krbtgt_<number>` accounts by hand while the RODC is still in use.

## Check that it worked

- `PasswordLastSet` on krbtgt shows the time of the second reset on every writable DC, and `msDS-KeyVersionNumber` is higher than the value you recorded before the first reset.

- `repadmin /replsummary` shows no failures.

- Users can log on and access file shares and web apps that use Kerberos. A quick test from a client: `klist purge`, then access a share and run `klist` to see a fresh TGT and service ticket.

- No new spike of Kerberos errors in the System log on DCs or application servers in the hours after the second reset.

## Common problems

- **Users or services get access denied right after the second reset.** The second reset was done before old tickets expired, or a DC had not replicated. Fix replication; affected clients recover by getting new tickets (`klist purge`, log off and on, or restart the service).

- **The script stops because a DC cannot be reached.** A DC is offline or decommissioned without cleanup. Bring it online or remove its metadata, then rerun mode 1.

- **Reset fails with a password policy error.** A third-party password filter is rejecting the request; see KB 2549833 as referenced in Microsoft’s forest recovery guide.

- **Old domain functional level.** The New-KrbtgtKeys script notes that Windows Server 2000/2003 DCs cannot validate PACs with the previous key, so reset-related errors are likely. Those DCs should not exist any more; see [raise the AD functional level](/guides/raise-ad-functional-level/).

**Official documentation:** [AD forest recovery: reset the krbtgt password](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-reset-the-krbtgt-password) · [Maximum lifetime for user ticket](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket) · [New-KrbtgtKeys.ps1 (archived repository)](https://github.com/microsoftarchive/New-KrbtgtKeys.ps1)

**Related:** [dcdiag repadmin Health Check: 7 Critical Tests Explained](/guides/dcdiag-repadmin-dc-health-check/) · [Restore Domain Controller Backups: System State and DSRM Steps](/guides/backup-restore-domain-controller/) · [AD Replication Error 1722 and 8453: Fixes](/guides/ad-replication-error-1722-8453/) · [Domain Controller Metadata Cleanup: Safely Demote or Remove a Dead DC](/guides/demote-domain-controller-metadata-cleanup/) · [Active Directory Audit Policy: DC Settings and 35 Key Event IDs](/guides/active-directory-audit-policy/)

**See also:** [Kerberos RC4 Removal: Find and Fix RC4 Accounts (2026)](/guides/kerberos-rc4-removal-audit/) · [Kerberos RC4 Audit Script: Find RC4 Accounts and Tickets](/scripts/kerberos-rc4-audit/) · [BadSuccessor dMSA on Server 2025: Audit OU Rights and Patch](/guides/badsuccessor-dmsa-server-2025/)

## Frequently asked questions

### Does resetting krbtgt log users off?

The first reset does not, because DCs still accept tickets signed with the previous key. A second reset done too early invalidates existing tickets and forces clients and services to get new ones.

### How long should I wait between the two krbtgt resets?

Longer than the Maximum lifetime for user ticket setting, which is 10 hours by default, and only after every writable DC shows the first reset.

### Does a krbtgt reset fix a golden ticket attack?

Two resets invalidate golden tickets made with the stolen key. They do not remove the attacker: if they still control an admin account or a DC, they can steal the new key. Contain the compromise first.

### Do I need to reset krbtgt in every domain of the forest?

Yes. Each domain has its own krbtgt account, and each RODC has its own krbtgt_number account. Reset each one you consider exposed.

### Can I just use Set-ADAccountPassword?

Yes. Any password reset on krbtgt triggers the DC to generate a new random password and keys. The script adds automated replication checks, which you otherwise do yourself.