Skip to main content
  • EN

As a Domain Administrator, it's likely you've never performed a KRBTGT password reset. Especially since the account appears disabled when viewed in Active Directory Users and Computers (ADUC).

 

However, the KRBTGT account is not disabled. This is misleading due to the special nature of the KRBTGT account. This is because it operates under special security permissions and restrictions that prevent its normal use. Such as interactive logon or enabling or disabling the account actions. The disabled icon or status is simply an indication that it cannot be used for normal operations

 

This critical account is automatically created when a Domain Controller (DC) is provisioned and is used by the Key Distribution Center (KDC) to issue and sign Kerberos tickets, which are essential for Kerberos authentication.

In this article “Perform Key Distribution Center Service ikrbtgt] Password reset”. We will cover best practices for resetting the KRBTGT account password and explain why regularly resetting it is crucial for maintaining the security of your domain.

Please, see Active Directory Authentication methods: How do Kerberos and NTLM work? Also, see Kerberos Delegation: A Comprehensive Guide. Here is a script to perform your first KBRTGT reset.

# Store the domain information
$domain = Get-ADDomain

# Get the KRBTGT account
$krbtgt = Get-ADUser -Filter { SamAccountName -eq 'krbtgt' }

# Reset the password for the KRBTGT account
Set-ADAccountPassword -Identity $krbtgt -Reset

# Force immediate replication to all domain controllers
(Get-ADDomainController -Filter *).Name | ForEach-Object { repadmin /syncall $_ /APed }

The kbrtgt reset is successful

 

BTW, you can also reset this account via the ADCU

The password that you specify isn’t significant because the system will generate a strong password automatically independent of the password that you specify

 

Thanks @Iams3le for sharing this deep feature.

Good advice @Iams3le  !

This password can be used to sign every Kerberos ticket. Monitoring it closely often mitigates the risk of golden ticket attacks greatly

To mitigate this attack, it is recommended to change the krbtgt password between 40 days and 6 months. If this is not the case, every backup done until the last password change of the krbtgt account can be used to emit Golden tickets, compromising the entire domain.
Retrieval of this secret is one of the highest priority in an attack, as this password is rarely changed and offer a long term backdoor.
Also this attack can be performed using the former password of the krbtgt account. That's why the krbtgt password should be changed twice to invalidate its leak.

Beware: two changes of the krbtgt password not replicated to domain controllers can break these domain controllers You should wait at least 10 hours between each krbtgt password change (this is the duration of a ticket life).

Thanks @Iams3le for sharing this deep feature.

You are welcome!

Good advice @Iams3le  !

This password can be used to sign every Kerberos ticket. Monitoring it closely often mitigates the risk of golden ticket attacks greatly

To mitigate this attack, it is recommended to change the krbtgt password between 40 days and 6 months. If this is not the case, every backup done until the last password change of the krbtgt account can be used to emit Golden tickets, compromising the entire domain.
Retrieval of this secret is one of the highest priority in an attack, as this password is rarely changed and offer a long term backdoor.
Also this attack can be performed using the former password of the krbtgt account. That's why the krbtgt password should be changed twice to invalidate its leak.

Beware: two changes of the krbtgt password not replicated to domain controllers can break these domain controllers You should wait at least 10 hours between each krbtgt password change (this is the duration of a ticket life).

Thank you @Stabz for emphasising on these terms and tying it to backup. With your recommendation, we are sure of our backup integrity. That is, we are not restoring backup with a compromised KRBTGT etc. Other security best practices will be vital to correctly protect the domain. I have covered how to mitigate and prevent tools such as mimikatz from running in the domain as well.

Comment


Terms & Conditions