The periodic reset of the KRBTGT password is now recommended by Microsoft to be carried out every 180 days. Resetting the password periodically reduces the risks of a Kerbroasting attack being successful.

To ensure the KRBTGT password is fully reset you MUST perform this reset operation twice. And you MUST wait a bare minimum of 10 hours between password resets. The 10 hours are the default Maximum lifetime for user ticket and Maximum lifetime for service ticket policy settings, hence in a case where the Maximum lifetime period changes, the minimum waiting period between resets should be greater than the configured value.

It is therefore strongly recommended to wait 24 hours between resets, rather than just the minimum recommended 10 hours.

Resetting the KRBTGT account password twice is essential because Active Directory stores the previous two passwords for Kerberos ticket validation. The first reset creates a new password but keeps the (potentially) compromised one in history; the second reset eliminates the old password entirely, rendering active forged “golden tickets” invalid.

It is not recommended to automate the process of resetting the KRBTGT password due to the risk of the process going wrong and resulting in service unavailability.

Do not attempt to reset the KRBTGT_AzureAD account password without fully understanding the process and what is required, there is a specific process that differs from the below for resetting this particular account password.

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises

How to complete the reset of this particular KRBTGT_AzureAD account is beyond the scope of this article; as is the reset of the KRBTGT_XXXXX (Number) accounts used by Read Only Domain Controllers.

Find Last Change Date (Powershell)

Find when the KRBTGT password was last changed with:

Get-ADUser "krbtgt" -Property Created, PasswordLastSet

You should see an output such as the following which shows that the KRBTGT password was last reset on 13th December 2012 at 09:21:05 in the morning.

Find Last Change Date (Script)

Find when the KRBTGT password was last changed with the below script, this script has the added bonus that it will seek out and find all of the KRBTGT accounts you may have in your domain and report on those.

Be aware that you only have one KRBTGT account per Active Directory Domain, the additional accounts will only exist if you have Read Only Domain Controllers (RODC) and/or Active Directory Directory Sync to Microsoft 365.

krbtgt_getinfo.ps1

import-module activedirectory
$ADForestRootDomain = (Get-ADForest).RootDomain
$AllADForestDomains = (Get-ADForest).Domains
$ForestKRBTGTInfo = @()
ForEach ($AllADForestDomainsItem in $AllADForestDomains)
{
[string]$DomainDC = (Get-ADDomainController -Discover -Force -Service “PrimaryDC” -DomainName $AllADForestDomainsItem).HostName
[array]$ForestKRBTGTInfo += Get-ADUSer -filter {name -like “krbtgt*”} -Server $DomainDC -Prop Name,Created,logonCount,Modified,PasswordLastSet,PasswordExpired,msDS-KeyVersionNumber,CanonicalName,msDS-KrbTgtLinkBl
}
$ForestKRBTGTInfo | Select Name,Created,logonCount,PasswordLastSet,PasswordExpired,msDS-KeyVersionNumber,CanonicalName | ft -auto

Gets the output of:

As you can see we can see a number of KRBTGT accounts, the one called “KRBTGT” is domain’s Ticket Granting Ticket account, it is this which we want to reset (typically), the other two called KRBTGT_35708 and KRBTGT_4536 are used by RODC, we typically won’t need to reset these, but you may also wish to. The last one KRBTGT_AzureAD is a special use KRBTGT account for Active Directory ADSync.

What we can also learn from this is that the msDS-KeyVersionNumber is 3, which based on the formula: n – 2, where “n” is the number shown in the msDS-KeyVersionNumber attribute, 3-2 = 1, the password has been changed once.

Active Directory Security Tip #8: The Domain Kerberos Service Account – KRBTGT

Find Maximum TGT Lifetime (in Hours)

Unless the lifetime has been changed by someone, this will be set to the default 10 Hours. To verify this the following PoweShell may be used. The GUID is apparently the same across any forest and domain, but add your Domain you want to inspect at the end:

[xml]$gpo = Get-GPOReport -Guid '{31B2F340-016D-11D2-945F-00C04FB984F9}' -ReportType Xml -ErrorAction Stop -Domain domain.com

$MaxTgtLifetimeHours = (($gpo.gpo.Computer.ExtensionData | Where-Object { $_.name -eq 'Security' }).Extension.ChildNodes | Where-Object { $_.Name -
eq 'MaxTicketAge' }).SettingNumber

Write-Host "$MaxTgtLifetimeHours Hours"

You should now get a number the output showing the Maximum TGT Lifetime in hours.

msDS-SupportEncryptionTypes on KRBTGT Account

There is no need to set msDS-SupportedEncryptionTypes of the krbtgt account i.e,. it can have the value 0 (0x0), it will always default to AES as long as Domain Function Level is 2008 or higher and the KRBTGT password was reset (twice) since then.

It is more important are msDS-SupportedEncryptionTypes of all other accounts (via GPO for windows clients) and ultimately the DefaultDomainSupportedEncTypes of all DCs, see: Microsoft Windows Active Directory RC4 Changes – CVE-2026-20833

KRBTGT AES Keys Generated

As per this article: https://adsecurity.org/?p=483, the following is mentioned:

Note: Changing the KRBTGT password is only supported by Microsoft once the domain functional level is Windows Server 2008 or greater. This is likely due to the fact that the KRBTGT password changes as part of the DFL update to 2008 to support Kerberos AES encryption, so it has been tested.

So because the domain and forest is now running beyond the 2008 functional level, we are at the time of writing on 2016 Functional Level (for Domain and Forest), the DFL triggered a reset of the password, therefore it has AES credentials (effectively), so although we appear to be good, we’ll reset the password anyway. We’re concerned about this because of the retirement of the RC4 Cipher in April 2026, in our case it appears the KRBTGT has the necessary AES credentials, but a reset of the KRBTGT password will just ensure doubly that this is the case.

KRBTGT Password Reset Procedure

The password reset can be completed manually (its not a complicated procedure), the Microsoft article: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-reset-the-krbtgt-password explains how to complete these steps. We are going to use a script that has been written for just this purpose.

Like with many things, you just do what Ali says: https://www.alitajran.com/krbtgt-password-reset/

Step 1 – Considerations for Multi-Domain and Forest Trusts

Because we only have a single domain within the forest we do not need to follow the process of resetting the KRBTGT in each child domain first (citation).

No considerations could be found that referenced a problem with resetting the KRBTGT and any effect on the Forest Trust to the hinxtonit.com Forest (and domain).

Step 2 – Ensure Backups of Active Directory Exist

Ensure you have valid Active Directory backups available and recently taken and tested so you can perform a restoration of the whole of Active Directory if it were so to be required.

Step 3 – Check Active Directory Health and Replication Status

To manually check the replication status you can use the commands to look for any issues identified:

repadmin /showrepl
repadmin /replsummary
repadmin /queue

Other useful commands can be found in: https://activedirectorypro.com/repadmin-how-to-check-active-directory-replication/

Step 4 – Reset the KRBTGT Account Password – 1st Time Pass

From an Active Directory Domain Controller, using a user accont with Domain Admin privileges perform the following steps:

1. Select Start, point to Control Panel, point to Administrative Tools, and then select Active Directory Users and Computers.
2. Select View, and then select Advanced Features.
3. In the console tree, double-click the domain container, and then select Users.
4. In the details pane, right-click the krbtgt user account, and then select Reset Password.
5. Clear (untick) the User must change password at next logon check box, and then click OK. Important!
6. In New password, type a new password, retype the password in Confirm password, and then select OK.

The password that you specify isn’t significant because the system generates a strong password automatically independent of the password that you specify. But you may want to make a record of it anyway.

Apparently a maximum length of 128 characters.

The following PowerShell will generate a random secure password which you may want to use, but being that the system generates another one that it actually uses its kind of irrelevant.

[Reflection.Assembly]::LoadWithPartialName(“System.Web”)
$RandPassLength = [int] 128
Write-Output “Generating Random Password of $RandPassLength Characters”
$RandomPassword = [System.Web.Security.Membership]::GeneratePassword($RandPassLength,2)
$RandomPassword

Step 5 – Verify Password Reset after 1st Time Pass

Verify the KRBTGT account password has been changed by running the PowerShell command:

Get-ADUser "krbtgt" -Property Created, PasswordLastSet

And observing that the date and time of the PasswordLastSet attribute have changed to the date and time of the 1st password change attempt.

Event Viewer

Examine the Windows Event log, specifically the Security log and look for the following event IDs, potentially in this order:

4724 (An attempt was made to reset an account’s password)
4738 (A user account was changed)

You are looking to verify that the KRBTGT account password has been successfully reset.

A Custom View might help here, for example:

Splunk

Examine the Windows Event log via Splunk, specifically the Security log and look for the following Event IDs:

4724 (An attempt was made to reset an account’s password)
4738 (A user account was changed)

You can also if you wish filter for the Target Account Name and Keywords if you have a busy number of account passwords resets taking place due to normal course of business.

index="wineventlog" LogName="Security" EventCode IN ("4724","4738") earliest=-2d@d latest=now Target_Account_Name=krbtgt Keywords="Audit Success"

You are looking to verify that the KRBTGT account password has been successfully reset.

Step 6 – Verify Replication Successful

Verify that Active Directory Domain Controller replication has been successful following the first password change.

repadmin /showrepl
repadmin /replsummary
repadmin /queue

Additionally verify there are no obvious issues with authentication following the change of the password.

repadmin.exe /showattr *.domain.com“
cn=krbtgt,cn=users,dc=domain,dc=com” /atts:pwdLastSet

Here we can see what the status is of all the Domain Controllers, some are still seeing the old password reset time, which means they have not yet been replicated to, so the KRBTGT is still on the old password.

Normal Domain Controllers

If things are out of date, you can force it with the below, although waiting is usually enough. Then recheck with the above command.

repadmin /syncall /APeD

Read-Only Domain Controllers

If things are out of date on the Read Only Domain Controller, you can use the below, then recheck with the repadmin command to verify the replication status. Because Read Only Domain Controllers pull a copy of the Active Directory, not have it pushed to it (like normal Domain Controllers).

repadmin /syncall /AeD

Note that this can take a while to complete….

Because it is local to the RODC, you can specify that instead in the command:

repadmin.exe /showattr dmzdc.domain.com
 "cn=krbtgt,cn=users,dc=domain,dc=com" /atts:pwdLastSet

Step 7 – Reset the KRBTGT Account Password – 2nd Time Pass

From an Active Directory Domain Controller, using a user accont with Domain Admin privileges perform the following steps:

ATTENTION: Do not proceed with the following steps until at least 24 hours have passed since the last KRBTGT account password reset. Failure to wait at least 10 hours (or whatever the maximum ticket lifetime is) will result in valid Kerberos Tickets being invalidated incorrectly and loss of availability.

Step 8 – Verify Password Reset after 2nd Time Pass

Repeat the tasks that were detailed in Step 5 to verify that the KRBTGT password was successfully reset for the second time.

Step 9 – Verify Replication Successful

Repeat the tasks that were details in Step 6 to verify the Active Directory replication is successful and authentication is working as expected.

Conclusion

And that, is it, you have successfully reset the KRBTGT account password.

KRBTGT Password Reset Process Explained

We borrow some information from the Microsoft article: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/faqs-from-the-field-on-krbtgt-reset/2367838, i’ve re-written for additional clarity.

Why does the KRBTGT need to be reset twice?

KRBTGT keeps a password history of 2, so by resetting it twice to invalidate all tickets issued using the KRBTGT password. Effectively once the password is reset for the second time all tickets issued using that particular KRBTGT password are invalid; hence why spacing out the two resets by at least the ticket lifetime is so important.

What happens when the KRBTGT account password is reset for the first time?

1. After the first reset, the new KRBTGT account password is replicated to all of the Domain Controllers within the domain.

2. All new tickets issued will use this new password (we’ll call it KRBTGT Password 1).

3. Any old tickets issued via the old KRBTGT password (we’ll call it KRBTGT Password 0) should continue to work as normal because the password they were issued with still exists in the KRBTGT account’s password history (being that is a history of 2).

4. When these old tickets expire, they’ll request new (or renewals) that will use the new KRBTGT Password (i.e. KRBTGT Password 1).

5. So at this point the current KRBTGT password will be our new password: KRBTGT Password 1 and the old one: KRBTGT Password 0.

What happens when the KRBTGT account password is then reset for the second time?

1. After the KRBTGT password is second reset for the second time, this is replicated to all the Domain Controllers within the domain.

2. All new tickets issued from that point onwards will now use the new new password, which we’ll call KRBTGT Password 2.

3. Any old tikcets issued via the previous KRBTGT password (i.e. KRBTGT Password 1) should continue to work as normal because the password they were issued with still exists in the KRBTGT account’s password history (being that is a history of 2).

4. Now the current KRBTGT passwords will be KRBTGT Password 2 and KRBTGT Password 1, where KRBTGT Password 0 is no more, being it has rolled off the end of the password history.

5. When these old tickets expire, they request new (or renewals) that will use the new new password, i.e. KRBTGT Password 2.

6. As mentioned in step 4, the old KRBTGT password, i.e. KRBTGT Password 0 is now invalid (being it rolled off the end of the password history). Any tickets issued with this password (i.e. KRBTGT Password 0) would now be invalid, but there shouldn’t be any because you waited until the lifetime of these tickets expired before you changed the KRBTGT password for the second time….right?

What can this break?

Some old and/or non-Windows clients don’t request new tickets until the expiry of their existing tickets. But this is okay, because when a non-Windows client goes back to get a new ticket after its ticket’s expiry time is reached (i.e. after 10 hours – if the default is being used), then because the previous KRBTGT password is still in the password history the renewal can be authenticated and the new ticket issued with the new KRBTGT password. – Ergo don’t reset the KRBTGT password in too quick a succession.

There are other concerns like what if a Domain Controller fails midway between the reset, or if you attempt to restore a single DC from an older backup before the 1st reset will fail, in this situation promote a new Domain Controller instead.

Reset Active Directory KRBTGT Password