Perform Key Distribution Center Service [krbtgt] Password reset

The KRBTGT account plays a crucial role in Microsoft’s implementation of Kerberos. That is, it is the default authentication protocol for Windows. A deep understanding of how the KRBTGT account functions can significantly impact the security and compliance of your network. In this article, we shall discuss the need for and how to Perform Key Distribution Center Service [krbtgt] password reset. Please see “NT LAN Manager: How to prevent NTLM credentials from being sent to remote servers“, and Bidding Farewell to NTLM in favour of Kerberos.

Note: The KRBTGT is an automatically provisioned by default when an Active Directory domain is set up. Its primary objective is to authenticate Kerberos tickets as the Key Distribution Center (KDC) account. As you can see from the image below, this account is rarely touched by System (Domain) Admins. The Last Password was when this DC was setup.

Therefore, properly managing this account helps prevent vulnerabilities that attackers could exploit to impersonate users and compromise your network. By securing the KRBTGT account, you reduce the risk of unauthorized access and protect your organization from potential threats.

Note: The KRBTGT may appear disabled via the Active Directory User and Computer console (ADCU). When viewing the “krbtgt” via the ADCU. The KRBTGT account appears disabled in AD.

Here are some related guides: How to configure Kerberos for Ansible Authentication, and KDC reply did not match expectations while getting initial credential. You could also see how to “Fix cannot find KDC for realm while getting initial credentials and kinit configuration file does not specify default realm“.

Advanced [Role of the KRBTGT Account]

Note: The KRBTGT account does not directly interact with users or administrators but instead works behind the scenes as part of the Kerberos ticket issuance process. All Ticket Granting Tickets (TGTs) issued by the KDC are encrypted using the password of the KRBTGT account

In a Windows domain environment, the Kerberos Key Distribution Center (KDC) manages authentication between clients and services as discussed above and consists of these two components:

• The Authentication Service (AS) handles authentication and issues Ticket Granting Tickets (TGTs).
• The Ticket-Granting Service (TGS) provides service tickets based on the TGTs issued by the AS.

Therefore, when a user logs into a domain-joined computer. They authenticate to the KDC using their credentials. The KDC verifies these credentials and if successful. It issues a Ticket Granting Ticket (TGT) for a specific period of time. This is also referred to as TTL or Time to Live which has a default timeframe of 10 hours.

The KRBTGT account’s password is used to encrypt and decrypt these TGTs. This ensures that tickets issued by the KDC are securely signed and can be verified by other services within the domain.

Note: All TGTs issued by the KDC are signed with the KRBTGT account’s password. This cryptographic signature allows services to verify the authenticity of the tickets presented by users or other services requesting access.

How does the KRBTGT work

These steps have been discussed here extensively, therefore, I will only add some images here. Please, see Active Directory Authentication methods: How do Kerberos and NTLM work. Also, see Kerberos Delegation: A Comprehensive Guide

Diagram 2 also shows the Kerberos Authentication steps as diagram 1

Best Practice suggestion for protecting krbtgt

To ensure proper protection, the KRBTGT account should follow Microsoft’s recommended security guidelines, including regular password resets. Also, considering when a DC is set up. The password of the Key Distribution Center Service Account “KRBTGT” is as old as the DC.

With a recommended (periodical) password changed for this account. This will help prevent any potential compromise to the KRBTGT master key. This password change does not have any negative consequence on the domain as the previously TGTs issued in the last 10 hours will remain valid. This is similar to how gMSA works as the password is managed by the DC and changed periodically as well by the DC.

The take away here is that, this KRBTGT password change is only done manually on one DC as the password is then replicated to all DCs within the domain based on the replication time configured. Here you will find more information.

Note: The password history value for the krbtgt account is 2, meaning it includes the 2 most recent passwords. By resetting the password twice you effectively clear any old passwords from the history. So there is no way another DC will replicate with this DC by using an old password.

If you are concerned that this is a potential breach. Then we can change the ‘KRBTGT” account password twice. There are best practices for this, and if you must perform this on the fly (same day).

Please be careful and ensure it is replicated to all DCs’ and also determine what could go wrong. This is because, the KRBTGT remembers the last two passwords when using Kerberos.

Please see Active Directory: How to Setup a Domain Controller, and how to convert distribution group to security group. Here is a guide on “PetitPotam attack on Active Directory Certificate Services: How to mitigate NTLM Relay PetitPotam attack on AD CS.

Reset the Perform Key Distribution Center Service [krbtgt] password

Note: Most Domain Administrators seldomly do this. Perhaps because they have some policies in place to prevent certain tools such as mimikats from running.

Resetting the password of the KRBTGT account is an important security practice, especially in the context of potential domain compromises.

Note: However, it should be done in a staged manner (e.g., twice, with some time between resets) as suggested in the best practice section above. This is because the KDC relies on the current and previous KRBTGT password to decrypt tickets.

Option 1: Reset the krbtgt password

Note: If you use a customized password filter (such as passfilt.dll) on a DC, then you might receive an error when you try to reset the krbtgt password. here is a workaround for this issue.

Launch the Server Manager, click on Tools and select Active Directory Users and Computers.

Select View, and then select Advanced Features.

In the console tree, double-click the domain container, and then select Users.In the details pane, right-click the krbtgt user account, and then select Reset Password.

Note: In New password, type a new password, retype the password in Confirm password, and then select OK.

Please see Setup DS923+ Synology NAS as a Backup Repository for VBR, and Migrate Veeam Configuration Database to PostgreSQL Server. Also, see how to Enable Autologon and Autostart for user session.

Option 2: Reset the krbtgt password via script

This script helps reset the password while preventing authentication errors caused by delayed replication of the new KRBTGT hash key across your environment. Please take a look at another script.

First KRBTGT Password Reset

Run the following PowerShell commands to reset the password for the KRBTGT account. This command resets the password while ensuring minimal disruption across the domain.

# 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 }

As you can see, the kbrtgt has been set.

Wait for Ticket Expiration

Wait for the existing Kerberos tickets to expire (typically 10 hours) before proceeding with the second reset. You can also check the default ticket expiration policy by running.

Get-ADDefaultDomainPasswordPolicy | Select-Object MaxTicketAge

Second KRBTGT Password Reset

Once the tickets have expired and replication has occurred across the environment. Please perform the second reset to fully transition to the new KRBTGT password.

# Reset the KRBTGT password again
Set-ADAccountPassword -Identity $krbtgt -Reset

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

Please see Docker Setup: Monitoring Synology with Prometheus and Grafana, and how to Force BitLocker Recovery: Perform BitLocker Recovery via the Self-Service Portal and Helpdesk.

Is Kerberos more Secure than NTLM?

In NTLM authentication, the hashed user password is stored on the client, DC, and application server, making it vulnerable to tools like Mimikatz. An application server must directly validate access with the DC.

With Kerberos, the hash is stored in fewer places, so stealing the KRBTGT password requires access to the KDC on the DC to create a Golden Ticket.

FAQs relating to Key Distribution Center Service Account [krbtgt]

I hope you found this article very useful on “Perform Key Distribution Center Service [krbtgt] password reset”. Please feel free to leave a comment below.