What the hell is KRBTGT?

First off, KRBTGT stands for “Kerberos Ticket-Granting Ticket”.

Kerberos is the protocol used by Windows servers to communicate with Active Directory, and Kerberos communication takes place via “tickets”. A ticket-granting ticket is itself a Kerberos ticket, that itself allows proven authenticated communications to take place via another ticket.

The KRBTGT account is in-fact a default Active Directory (AD) system user account, the password of which is used to prove that a server, application, or user is indeed authenticated against Active Directory and is authorised to send Kerberos tickets to that Active Directory.

The proper technical explanation, if you really care for it:

The actual initial authentication of requests in Active Directory happens using a service on the domain controllers called the Kerberos Key Distribution Centre, and the AD account password's NTLM hash is used to authenticate with the Key Distribution Centre (before you ask, computer accounts have passwords too). Once authorised with the Key Distribution Centre, it then - as the name implies - "distributes" (sends) the KRBTGT password hash back to use in the next Kerberos ticket, a Ticket-Granting Ticket, by that account. The hash is actually used in creating and encrypting the Ticket-Granting Ticket. Basically, the KRBTGT hash being used to encrypt the Ticket-Granting Ticket proves that the Key Distribution Centre has OK'd the authentication of the account.

This is where the danger happens with a compromised KRBTGT account.

The Ticket-Granting Ticket is authenticated against another service (also running on the domain controller), the Ticket-Granting Service, which also gets sent the details on what specifically the user wants to access. The Ticket-Granting Service decrypts the Ticket-Granting Ticket, and if the KRBTGT password hash is correct, an encrypted security token is sent back to the requestor, and additionally further onwards to the server hosting the resources the user wants to access. The Ticket-Granting Service security token proves that the Ticket-Granting Service has OK'd the request for access.

That final server (the one that hosts the resources - be that an application, like Active Directory, or a resource, like a file share) then verifies the Ticket-Granting Service security token, and grants access to it's resources for a period of time (which is 10 hours unless the Kerberos Time-To-Live has been changed).

All in all, it takes three separate services to authenticate. It's a complex, but also somewhat secure process that forms the backbone of authentication for millions of organisations around the world.

Extra note: The Kerberos Time-to-Live can be decreased, Microsoft explain how to do this here: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket

TLDR; The KRBTGT account is critical for the correct function of Active Directory. It proves - without doubt - to Active Directory that you're authenticated and what you're asking to do is a valid request.

Problems with the KRBTGT account will cause major AD issues, such as unable to logon, unable to join the domain, broken trust relationships, service accounts not working, etc etc. All in all a bad time!

There is a separate KRBTGT account for each Active Directory domain, on a per-domain basis. Therefore, in a forest of domains, each domain has it's own separate KRBTGT account.

If it's so important, why would we want to regularly change the password for the KRBTGT account?

All authenticated Kerberos tickets flying around the domain toward the domain controllers are cryptographically signed and encrypted with the hash of the KRBTGT account, this proves to a domain controller that the tickets are authenticated and valid for that Active Directory domain.

Malicious actors have been known to exploit this functionality of the Kerberos protocol to do something called a “Golden Ticket attack” whereby a compromised KRBTGT hash allows an escalation of privilege attack. Essentially knowing that password will allow them to create a maliciously crafted Kerberos ticket (a Ticket-Granting Ticket, specifically) to do anything they want in the domain, access any resource they know the name for, or even become a domain administrator, and all the power that comes with that.

To counter this, it is considered best practice to change the KRBTGT account password at least twice annually to help prevent against Golden Ticket attacks. Furthermore, it should be completed when any privileged administrator leaves the organisation.

This article from CrowdStrike does a great job explaining what exactly a golden ticket attack is, and why it's so powerful to malicious actors: https://www.crowdstrike.com/cybersecurity-101/golden-ticket-attack/

Two separate password resets on this account are actually required due to the fact that the KRBTGT hashes used on Kerberos tickets are valid for both the current and the previous KRBTGT password. This is for functional reasons - otherwise the password change would break everything as no one could create a valid ticket.

Do not reset the KRBTGT password without reading the entire article, I've warned you.

In order to achieve this on a regular basis, I recommend setting up a recurring automatic ticket in your ticket system. Doing the entire process totally automated is of course possible, but I wouldn't choose to do that due to the potential for disaster.

In a circumstance where AD has been compromised, or a Golden Ticket attack is suspected, the first step should be to twice reset the KRBTGT account password, whilst being aware of the extreme system impact that doing so would have.

Where is this KRBTGT account?

The KRBTGT account is located in the default Users container, and it is only visible to administrators after ticking the “Advanced Features” option in Active Directory Users & Computers (ADUC) console. It MUST remain disabled.

If this has been enabled or moved, definitely move it back and disable it before going any further.

WARNING: The disastrous effects of resetting the KRBTGT password incorrectly

⚠️ Pay attention. ⚠️

🚫 Resetting the password of account KRBTGT twice (2x) very quickly in sequence WILL break the connections between AD Domain Controllers and Servers, Apps and Users. To clarify, this means doing it twice in less than 10 hours (which is the out-of-the-box Kerberos Ticket Lifetime as defined in Default Domain Policy) .

REALLY DO NOT DO THIS, it should only be done during forest/domain recovery (isolation) and/or a cyber attack (taking back control) - there's a note on what to do in that scenario below.

✅ Resetting the password of account KRBTGT just one time (1x), allowing AD replication to occur end-to-end, and then, and only then, resetting it the second time AFTER the 10 hours Kerberos Ticket Lifetime will not impact DCs nor servers, applications and users.

A quick important note on Active Directory Functional Level

Microsoft states that resetting the KRBTGT account password is only supported in a Windows Server 2008 Domain Functional Level (DFL) or higher Active Directory domain environment.

It's important to know that when the DFL is raised from 2003 to 2008 (or higher), the KRBTGT account password is changed once automatically, and this also counts toward the number of resets in succession.

Frankly, if your AD DFL is at the 2008 functional level in 2024, you probably have a whole bunch of other issues, but get that raised today so you can do this – and get the ever-useful AD Recycle Bin that's part of the 2012 functional level.

How to check when the KRBTGT password was last changed

To check when the KRBTGT password was last changed, you can view the AD account attribute pwdLastSet in Attribute Editor.

Steps to take to change the KRBTGT password

Do not reset the password simply using Active Directory Users & Computers (ADUC) console. Use the below mentioned script.

I'll remind you of the important details we've already covered:

🚫 DO NOT RESET THE KRBTGT ACCOUNT PASSWORD MORE THAN ONCE PER 10 HOUR PERIOD.

⚠️ YOU MUST RESET THE KRBTGT PASSWORD TWICE, AT LEAST 10 HOURS BETWEEN RESETS.

⚠️ ONLY EVER RESET THE PASSWORD TWICE IN QUICK SUCCESSION IN RESPONSE TO A GOLDEN TICKET ATTACK OR AD COMPROMISE/RECOVERY SCENARIO.

The routine KRBTGT password reset procedure:

Download the KRBTGT password reset script from GitHub. The script name is Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1.

First, log on to the Domain Controller with the PDC Emulator role.

Place the script into a directory on the server. Make a note of the location so that you can reference it for your engineers in the scheduled ITSM ticket you're going to set up in your ticketing system.

Run Windows PowerShell as a Domain Administrator. Change the path to the scripts folder and run the script.

The KRBTGT password reset script will ask if you want to read the script’s information, functions, behaviour, and impact. For your own sanity, choose Yes and go through the information.

When you finish reading through the information, you will see 9 options to select.

The ones that we will use are:

• 5 – Simulation Mode | Use KRBTGT PROD/REAL Accounts – No Password Reset/WhatIf Mode!
• 6 – Real Reset Mode | Use KRBTGT PROD/REAL Accounts – Password Will Be Reset Once!

Note: Option 5 will do nothing to the environment and will only show you all the details of what will happen.
It's important to run option 5 first! It will check that all Active Directory health requirements for performing this task are met.

Only option 6 will actually reset the KRBTGT password.

Option 5 - Simulation mode

1. Press option 5.
2. Choose the domain to reset.
3. Select which KRBTGT account you want to target. Select 1.
4. Type Continue and press Enter.
5. If everything is looking good, proceed to the next step.

If you get an error when attempting to change the password due to complexity requirements, check this Microsoft Learn article: https://learn.microsoft.com/en-US/troubleshoot/windows/win32/change-krbtgt-password-may-fail

Option 6 - Real reset mode

1. Complete Simulation mode without error first!
2. Run the script again, doing the same steps as above. But, this time, press option 6.
3. The output will show that a new password is set for the account KRBTGT.
4. The KRBTGT account password reset script has successfully set a new password for the KRBTGT account.

Now, verify KRBTGT account password has been reset

1. Start Active Directory Users and Computers (ADUC). Enable Advanced Features.
2. Find the user object KRBTGT and view the Properties.
3. Click the tab Attribute Editor.
4. Find the attribute pwdLastSet .
5. Verify that the value has just been changed.

Continue, at least 10 Hours later

10 HOURS LATER MINIMUM, I've said this so many times but it's so critical, so I'll keep mentioning it.

In all honesty, remove the risk and do the second reset the following day.

After the Kerberos ticket lifetime has expired, you now need to repeat the process to change the KRBTGT password. Double check the KRBTGT account pwdLastSet attribute after the second password reset to confirm you've completed the whole procedure.

Okay, cool. So you're actually going through a disaster situation right now and need to emergency reset the account?

Only ever follow the below guidance in response to a cyber attack or compromise, or in an AD disaster recovery scenario.

⚠️ All existing authentication sessions will be dropped.

⚠️ You will need to restart every single computer on the domain in order to restore Active Directory domain functionality.

The process to perform the emergency KRBTGT password reset is identical to the routine password, except in this case you WANT to break authentication of any existing tickets, so you must reset the password twice in quick succession.

Troubleshooting: KRBTGT password reset error messages

✅The following error in event viewer is expected after the KRBTGT password has been successfully changed:

During TGS processing, the KDC was unable to verify the signature on the PAC from krbtgt. This indicates the PAC was modified.

If the following error is shown, then the KRBTGT account password needs to be changed, as the current password doesn’t meet the required encryption standard on the domain.

The Kerberos Key Distribution Center lacks strong keys for account krbtgt.
You must update the password of this account to prevent use of insecure cryptography.

Conclusion

Hopefully this article has helped you to get your head around the KRBTGT account and the reset procedure. It's something that all system administrators should be aware of, and regularly checking.

If you remember one thing, remember not to reset the account password twice too quickly.

Ryan Drake
Infrastructure Insider - Editor-in-Chief

Copyright 2024, All Rights Reserved.

No AI writers or writing assistants here.
GPT free.