Tag Archive: krbtgt

Some interesting sites:

Windows 10 security hardening:


Delegate WMI access to domain controllers:

This post originally came about after several customers asked how to remove users accounts from Domain Admins and the Administrators group in the domain. These accounts are needed to monitor the systems, so we needed to find a way to get them to read the instrumentation of the system with non-elevated privilege.



Reference articles to secure a Windows domain:


Microsoft audit Policy settings and recommendations:


Sysinternals sysmon:


On ADsecurity.org:

Beyond domain admins: https://adsecurity.org/?p=3700

Gathering AD data with PowerShell: https://adsecurity.org/?p=3719

Hardening Windows computers, secure Baseline check list: https://adsecurity.org/?p=3299

Hardening Windows domain, secure Baseline check list:

Securing Domain Controllers to Improve Active Directory Security

Domain hardening in general:


List of items
Setting Up Jump server
Domain joining of all windows boxes
Proper account Management Based on privileges
Usage of service accounts to run application instead of local system accounts
Review of existing AD accounts/Deletion of Unnecessary Accounts/ Review Ou structuring/GPO etc
HoneyToken Account Creation in Local boxes as well domain
GPO changes for disabling guest accounts across system,restricted RDP mode,Password Policy changes,disabling internet in member servers
GPO for Jump server implementation based on PAW GPO settings
Rename existing builtin Administrator account and lockdown
Sysmon deployment and WEF setup (WEC for symon events)
Ping castle review to assess the AD security
FGPP implementation
LAPS Implementation
Process for proper cleanup of unused AD accounts
Reset of krbtgt account,domain admins account,It administrators account


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)

To verify KRBTGT password replication:

The password for this account is used to create a symmetric key that is used to encipher all the Ticket Granting Tickets (TGTs) in Kerberos, issued by Read/Write Domain Controllers.

Raising the Domain Functional Level (DFL) to Windows Server 2008 triggers a one-time reset of the password, and thus the symmetric key used.

Note:  The Kerberos Service is equipped with a fall-back mechanism so it can stull decipher the tickets enciphered with the old key, derived from the old password. With the default values, Kerberos clients may use these tickets for a period as long as 7 days.

Use the following one-liner (either in an elevated command prompt or elevated PowerShell window) to check when each of the Domain Controllers in the Active Directory domain have seen the password change:

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

This will check the value for the pwdLastSet attribute for the KRBTGT account on each of the Domain Controllers in the respective Active Directory domain and return the value.

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

Get-ADUSer -filter {name -like “krbtgt*”} -Server $DomainDC -Prop Name,Created,logonCount,Modified,PasswordLastSet,PasswordExpired,msDS-KeyVersionNumber,CanonicalName,msDS-KrbTgtLinkBl

whole script:

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: