When promoting a new Active Directory domain, a Krbtgt user account is created automatically. Many AD administrators, on the other hand, are unfamiliar with this account, which is critical for security and the overall operation of the domain. Let’s see what we can do! When the first domain controller is installed, the krbtgt account with RID 502 is created in the Users container. This account is disabled, with only Domain Users and Denied RODC Password Replication Group added to its AD security groups. You can’t change the account’s name, enable it, or delete it. This account is required for the AD domain’s KDC and Kerberos services to function properly.
On each domain controller AD, the KDC service (Kerberos Distribution Center) processes all requests for Kerberos tickets. The password for the krbtgt account is used to establish a secret key that is used to encrypt and decrypt TGT tickets (issued by all KDCs in the domain).
In most cases, the krbtgt account password does not change from the time AD is deployed, and if a hacker obtains the hash of this password (for example, using mimikatz or similar utilities), he can create his own Golden Ticket Kerberos, bypassing the KDC and authenticating to any service in the AD domain using Kerberos.
Because each Read-Only Domain Controller (RODC) has its own krbtgt account, the hash of the krbtgt account password is not kept on the RODC domain controllers.
Using PowerShell, you can get information about the krbtgt account, including the date of the last password change:
Get-AdUser krbtgt -property created, passwordlastset, enabled
The krbtgt password has not changed since the AD domain was created, as seen in our sample.
You should change the password of the domain account krbtgt on a regular basis for security reasons and to avoid an attack of the type Golden Ticket Attack (once a year and when any domain administrator leaves your company). Because the current and previous passwords of the krbtgt account are saved in the domain, you must change the password twice (with a sufficient delay to perform replication in the entire domain). Even if the attackers issued a Golden Ticket with a long validity term, it will become unusable if the password krbtgt is changed.
The password for the krbtgt account changes automatically when the domain’s functional level is raised (for example, from Windows Server 2012 R2 to Windows Server 2016).
You can change the krbtgt password as for any regular user through the ADUC snap-in (Reset Password), or you can use a ready PowerShell script
Reset the krbtgt account password/keys (https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51), which not only changes the account password, but additionally launches and tracks the replication of this password in the domain.
Use a strong password for krbtgt!
If you make a second change of the krbtgt account password during replication delays, you may face problems with some domain services (for example, Exchange). To minimize risks after changing the krbtgt password, you need to restart the Kerberos Key Distribution Center service on all domain controllers manually via the services.msc console (select the Kerberos Key Distribution service and click “Restart”).
Or (much easier), restart the KDC service using PowerShell Get-Service:
$DCs=Get-ADDomainController
Get-Service KDC -ComputerName $DCs | Restart-Service