Krbtgt user account is automatically created when promoting a new Active Directory domain. However, many AD administrators do not have sufficient knowledge of this account, which is very important from security point of view and the entire domain operation. Let’s try to fix it!
The krbtgt account with RID 502 is created in the Users container when the first domain controller is installed. This account is disabled and added only to two AD security groups: Domain Users and Denied RODC Password Replication Group. You cannot change the name of this account, enable it, or delete. This account is key to the operation of the KDC and Kerberos services in the AD domain.
The KDC service (Kerberos Distribution Center) is running on each domain controller AD, which processes all requests for Kerberos tickets. To create a secret key that is used to encrypt and decrypt TGT tickets (issued by all KDCs in the domain), the password for the krbtgt account is used.
In most cases, the krbtgt account password does not change from the moment of AD deployment and if the hash of this password falls into the hands of a hacker (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.
Note. The hash of the krbtgt account password is not stored on the Read-Only Domain Controller (RODC) domain controllers, since each RODC has its own krbtgt account.
You can get information about the krbtgt account and the date of the last password change using PowerShell:
Get-AdUser krbtgt -property created, passwordlastset, enabled
In our example, you can see that the krbtgt password has not changed since the creation of the AD domain.
For security reasons and to counter an attack of the type Golden Ticket Attack, you need to periodically change the password of the domain account krbtgt (once a year and when any domain administrator leaves your company). You need to change the password twice (with a delay sufficient to perform replication in the entire domain), because the current and previous password of the krbtgt account is stored in the domain. Even if the attackers issued the Golden Ticket with a long period of validity, after changing the password krbtgt, this ticket will become useless.
Note. When you raise the functional level of the domain (for example, from Windows Server 2012 R2 to Windows Server 2016), the password of the krbtgt account changes automatically.
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:
$DCs=Get-ADDomainController Get-Service KDC -ComputerName $DCs | Restart-Service