Every Domain Controller in an Active Directory domain runs a KDC (Kerberos Distribution Center) service which handles all Kerberos ticket requests. AD uses the KRBTGT account in the AD domain for Kerberos tickets. The KRBTGT account is one that has been lurking in your Active Directory environment since it was first stood up. Each Active Directory domain has an associated KRBTGT account that is used to encrypt and sign all Kerberos tickets for the domain. It is a domain account so that all writable Domain Controllers know the account password in order to decrypt Kerberos tickets for validation. Read Only Domain Controllers (RODCs) each have their own individual KRBTGT account used to encrypt/sign Kerberos tickets in their own sites. The RODC has a specific KRBTGT account (krbtgt_######) associated with the RODC through a backlink on the account. This ensures that there is cryptographic isolation between trusted Domain Controllers and untrusted RODCs.

The KRBTGT is shrouded in mystery and most AD admins will not mess with it or change its membership. It shouldn’t be a member of Domain Admins, Administrators, or any other groups other than “Domain Users” and “Denied RODC Password Replication Group”. Note that the “Denied RODC Password Replication Group” is a new group added when you run ADPrep before installing the domain’s first 2008/2008R2/2012 DC. This group supports Read-Only Domain Controllers (RODC) ensuring that certain accounts never have their passwords stored on a RODC.


The SID for the KRBTGT account is S-1-5-<domain>-502 and lives in the Users OU in the domain by default. Microsoft does not recommend moving this account to another OU.

Changing the KRBTGT account password can be painful – it has to be changed twice to ensure there is no password history maintained. If your domain/forest has been compromised, you must reset the KRBTGT account password twice. It must be changed twice since the account’s password history stores the current password and the last one . If this isn’t done, it is very likely the attacker can get back on the network at some point and generate custom TGTs (aka Golden Tickets) using the KRBTGT account password hash. The KRBTGT password hash which usually has never been changed (other than when the domain functional level was raised from 2003 to 2008/2008R2/2012/2012R2). Ensure you change the KRBTGT account password for every domain in your forest. Don’t leave an attacker any backdoors.

The krbtgt password can be reset when you suspect intrusion or when a RW DC is stolen. Use the script above to reset only ONCE the password.

For the second password reset it is very important to wait a period of time: >  [10h (TGT lifetime) + TGS lifetime 600minutes + latence de replication AD + Time Skew ] and it is also recommended to force the AD replication and to stop/start the KDC service on all RW DC.

In short, you can wait 24 hours between the FIRST RESET and the SECOND RESET.

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.

Microsoft posted a KRBTGT account password PowerShell script on TechNet that will change the KRBTGT account password once for a domain, force replication, and monitor change status.

Note that changing the KRBTGT account password in a 2008 (or higher) DFL will not cause replication issues.

  • Changing the KRBTGT account password once, waiting for replication to complete (and the forest converge), and then changing the password a second time, provides a solid process for ensuring the KRBTGT account is protected and reduces risk (Kerberos and application issues).
  • Changing the KRBTGT account password twice in rapid succession (before AD replication completes) will invalidate all existing TGTs forcing clients to re-authenticate since the KDC service will be unable to decrypt the existing TGTs. Choosing this path will likely require rebooting application servers (or at least re-starting application services to get them talking Kerberos correctly again).

Microsoft has two TechNet articles which describe scenarios where changing the KRBTGT account password may be necessary:

When changing the KRBTGT account password make certain you use a solid password.

UPDATE: Note that when you set the KRBTGT password, even if you set it to “KerberosIsMyPal!” it will be automatically changed to a complex password in the background. This means that the password you enter when changing the password doesn’t matter, only that the password changes.

To reset the krbtgt account password:

To perform this procedure, you must be a member of the Domain Admins group, or you must have been delegated the appropriate authority.

To reset the krbtgt user account password twice:

  1. Log on to a computer that has Active Directory Users and Computers installed. It is installed by default on a domain controller.
  2. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.
  3. Navigate to the organizational unit where the krbtgt user account is stored. By default, this organizational unit is named Users.
  4. Right-click krbtgt, and then click Reset Password.
  5. In the New password box, type the new password.
  6. In the Confirm Password box, retype the password.
  7. Clear the User must change password at next logon check box, and then click OK.
  8. Repeat steps 4-7 to reset the password again.
  9. Close Active Directory Users and Computers.

Verification: After you reset the krbtgt password, ensure that event ID 6 in the Microsoft-Windows-Kerberos-Key-Distribution-Center event source is written to the System event log. 

To perform this procedure, you must be a member of the local Administrators group, or you must have been delegated the appropriate authority.

To open the System event log:

  1. Log on to a domain controller.
  2. Click Start, and then click Control Panel.
  3. Double-click Administrative Tools, and then click Event Viewer.
  4. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  5. Expand Windows Logs, and then click System.
  6. Ensure that Event ID 6 from the Microsoft-Windows-Kerberos-Key-Distribution-Center event source is shown.

Here’s PowerShell code to generate a 128 character, complex password:

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

Script code to identify KRBTGT account info (including the key version number – tracks password changes) for every domain in the AD forest:

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


the KRBTGT account is critical for AD domain Kerberos authentication and if not properly protected, enables an attacker to create their own Kerberos TGT “Golden Tickets.” These special TGTs provide the attacker with access to anything and everything Kerberos enabled on the network without having to add themselves to AD groups.

Web References

Script to reset the KRBTGT: