Introduction
The krbtgt account is the service account for the Key Distribution Center (KDC) in Active Directory. It is created automatically when a domain is built and is used to encrypt and sign all Kerberos Ticket Granting Tickets (TGTs).
If the krbtgt account password is compromised, attackers can forge golden tickets that provide unrestricted domain access. To prevent this, Microsoft recommends periodically resetting the krbtgt password, or immediately after any domain compromise.
This guide explains how to:
- Check when the
krbtgtpassword was last changed - Simulate and perform the reset safely
- Validate replication and password updates
- Follow best practices for AD security hygiene
⚙️ Why You Should Reset the KRBTGT Password Twice
Kerberos authentication maintains two password versions — the current and the previous one.
Resetting krbtgt once starts key rollover; resetting it twice (after replication completes) ensures that all Kerberos tickets — including any malicious ones — become invalid.
Reset 1: Introduces a new key.
Reset 2: Finalizes the key change after replication propagation.
🧩 Prerequisites
Before proceeding, ensure the following:
- You’re logged in as a Domain Admin or Enterprise Admin.
- All Domain Controllers (DCs) are replicating successfully. Check with:
repadmin /showrepl * - You’re working on a Writable Domain Controller (RWDC).
- The ActiveDirectory PowerShell module is installed (
RSAT-AD-PowerShell). - You schedule this during a maintenance window.
🔎 How to Check When KRBTGT’s Password Was Last Set
Before you decide to reset the password, check when it was last changed and whether that timing aligns with your security policy (for example, “no more than 180 days old”).
✅ Using Active Directory Users and Computers (ADUC)
- Open Active Directory Users and Computers.
- In the View menu, select Advanced Features.

- Navigate to the Users container (or wherever
krbtgtresides).

- Find the krbtgt user object (SID ends with -502).
- Open its Properties → Attribute Editor tab.

- Locate the attribute
pwdLastSet— this shows the timestamp when the password was last reset.

- Compare that date against your internal rotation policy.
✅ Using PowerShell
You can also check via PowerShell:
Get-ADUser "krbtgt" -Properties PasswordLastSet |
Select-Object Name, PasswordLastSet

This gives you a quick reference to the last time the password was changed.
If the PasswordLastSet value is older than your defined rotation interval (for example, 180 days) or has never been reset since domain creation, make this a priority task.
🧰 Step 1: Save the PowerShell Script
Create a new PowerShell file named:
Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1
Copy the following script into it.
<#
.SYNOPSIS
Safely resets and validates the krbtgt account password in Active Directory.
.DESCRIPTION
This script checks replication health, validates current krbtgt password reset timestamps,
and performs (or simulates) the double reset process needed to roll Kerberos keys safely.
.PARAMETER WhatIf
Simulates the process without making any changes.
.EXAMPLE
.\Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 -WhatIf
#>
[CmdletBinding(SupportsShouldProcess = $true, ConfirmImpact = 'High')]
param()
Write-Host "Starting krbtgt password reset and validation process..." -ForegroundColor Cyan
try {
Import-Module ActiveDirectory -ErrorAction Stop
} catch {
Write-Error "❌ ActiveDirectory module not found. Install RSAT or import manually."
exit 1
}
# --- Step 1: Identify domain and krbtgt info ---
$domain = (Get-ADDomain).DNSRoot
$krbtgt = Get-ADUser -Identity "krbtgt" -Properties PasswordLastSet, whenCreated
Write-Host "Domain: $domain" -ForegroundColor Yellow
Write-Host "`nkrbtgt account information:"
$krbtgt | Select-Object Name, whenCreated, PasswordLastSet | Format-List
# Validate if password reset is due
$lastReset = $krbtgt.PasswordLastSet
$daysSinceReset = (New-TimeSpan -Start $lastReset -End (Get-Date)).Days
if ($daysSinceReset -gt 180) {
Write-Warning "⚠️ krbtgt password has not been reset in over $daysSinceReset days. Consider rotating it now."
} else {
Write-Host "✅ krbtgt password was reset $daysSinceReset days ago." -ForegroundColor Green
}
# --- Step 2: List DCs and replication status ---
$DCs = Get-ADDomainController -Filter * | Sort-Object Name
$RWDCs = $DCs | Where-Object { -not $_.IsReadOnly }
Write-Host "`nFound $($DCs.Count) DCs ($($RWDCs.Count) writable):"
$DCs | Format-Table Name, IPv4Address, Site, IsReadOnly -AutoSize
Write-Host "`nChecking replication health..." -ForegroundColor Cyan
$repl = Get-ADReplicationPartnerMetadata -Target * -ErrorAction SilentlyContinue
$failures = $repl | Where-Object { $_.ConsecutiveFailureCount -gt 0 }
if ($failures) {
Write-Warning "Some DCs show replication failures!"
$failures | Select-Object Server, Partner, ConsecutiveFailureCount | Format-Table -AutoSize
} else {
Write-Host "✅ Replication appears healthy." -ForegroundColor Green
}
# --- Step 3: Simulation Mode ---
if ($WhatIfPreference) {
Write-Host "`n[SIMULATION MODE] Actions that would be performed:" -ForegroundColor Yellow
Write-Host "---------------------------------------------------"
Write-Host "1. Reset krbtgt password on all writable DCs."
Write-Host "2. Wait for AD replication to complete."
Write-Host "3. Reset password again (second reset)."
Write-Host "4. Verify krbtgt PasswordLastSet timestamp on all DCs."
Write-Host "`nNo changes made (running with -WhatIf)." -ForegroundColor Green
return
}
# --- Step 4: First Password Reset ---
if ($PSCmdlet.ShouldProcess("krbtgt account", "Perform FIRST password reset")) {
$pwd1 = Read-Host "Enter a strong password for the first reset" -AsSecureString
Set-ADAccountPassword -Identity "krbtgt" -NewPassword $pwd1 -Reset
Write-Host "✅ First krbtgt password reset complete." -ForegroundColor Green
}
Write-Host "`n⚠️ Wait for AD replication to complete before proceeding to the second reset." -ForegroundColor Yellow
Pause
# --- Step 5: Second Password Reset ---
if ($PSCmdlet.ShouldProcess("krbtgt account", "Perform SECOND password reset")) {
$pwd2 = Read-Host "Enter a new strong password for the second reset" -AsSecureString
Set-ADAccountPassword -Identity "krbtgt" -NewPassword $pwd2 -Reset
Write-Host "✅ Second krbtgt password reset complete." -ForegroundColor Green
}
# --- Step 6: Validate new password timestamp ---
$krbtgtUpdated = Get-ADUser -Identity "krbtgt" -Properties PasswordLastSet
Write-Host "`nNew krbtgt PasswordLastSet:" $krbtgtUpdated.PasswordLastSet -ForegroundColor Cyan
Write-Host "`nAll operations completed. Verify replication and Kerberos event logs for confirmation." -ForegroundColor Cyan
After executing this script, it will prompt to change the password along with re-validation. and below output will be generated along with all dc’s name and IP Addresses.

🧪 Step 2: Run the Script
Simulation Mode (safe)
.\Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 -WhatIf
✅ Displays what actions would be performed without making any changes.
Actual Password Reset
.\Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1
- Enter a strong password for each prompt.
- Wait for replication between resets.
- Confirm replication using:
repadmin /showrepl *
🧾 Step 3: Validate the Reset
After both resets:
Get-ADUser "krbtgt" -Properties PasswordLastSet |
Select Name, PasswordLastSet
- Ensure the timestamp has updated to the current date/time.
- Confirm replication is complete on all DCs.
- Review DC Security Logs for events 4724 and 4738, confirming password resets.
🧠 Best Practices
- Reset
krbtgtevery 6 months or after a breach. - Always do two resets, waiting for replication in between.
- Use
-WhatIfbefore live execution. - Validate with both ADUC and PowerShell.
- Keep a change log with date, admin, and validation results.
✅ Conclusion
The krbtgt account is fundamental to Kerberos trust.
Regularly checking its pwdLastSet attribute and performing controlled double password resets are essential security hygiene practices that protect against golden ticket persistence.
Use the PowerShell script above to automate and validate the process — with safe -WhatIf simulation, replication checks, and timestamp verification — ensuring your Active Directory remains secure and resilient.