A Reddit user raised this great question today that I am not aware of. So I did a little research and here is the breakdown of what it is.
What is KRBTGT?
The KRBTGT is a local default account that acts as a service account for the Key Distribution Center (KDC) service. It’s created automatically when a new domain is created.
- It cannot be deleted
- its name cannot be changed
- it cannot be enabled
- it only belongs to the following two groups
- Domain Users
- Denied RODC Password Replication Group
KDC service handles all Kerberos ticket requests so KRBTGT account in AD plays a key role that encrypts and sign all Kerberos tickets for the domain.
You can also use the PowerShell code to get the account’s detail as well:
Get-AdUser krbtgt -property created, passwordlastset, enabled, sid, distinguishedname
How it works:
- User logs on with AD user name and password to a domain-joined computer (usually a workstation).
- The user requests authentication by sending a timestamp (Pre-auth data) encrypted with the users password-based encryption key (password hash).
- User account ([email protected]) requests a Kerberos service ticket (TGT) with PREAUTH data (Kerberos AS-REQ).
- The Kerberos server (KDC) receives the authentication request, validates the data, and replies with a TGT (Kerberos AS-REP).
Why do you need to update its password?
99.99% of the time, the KRBTGT account’s password has not changed since the AD Domain was set up. But since it’s a domain account, all writable DCs know the account password in order to decrypt Kerberos tickets for validation.
Because of that, the attackers may use the KRBTGT account to persist on the network even if every other account has its password changed. During an incredibly awesome talk (Video) at the Black Hat 2014 security conference in Las Vegas, NV in early August, Skip Duckwall & Benjamin Delpy spoke about a method (using Mimikatz) to generate your own Kerberos tickets (aka the Golden Ticket).
And that’s why Microsoft now recommends that the KRBTGT password change on a regular basis.
How to change the password?
Microsoft posted a KRBTGT account password PowerShell script on TechNet that will change the KRBTGT account password once for a domain, force replication, and monitor change status.
Note that changing the KRBTGT account password in a 2008 (or higher) DFL will not cause replication issues.
There are two KRBTGT Password Change Scenarios:
- Maintenance: Changing the KRBTGT account password once, waiting for replication to complete (and the forest converge), and then changing the password a second time, provides a solid process for ensuring the KRBTGT account is protected and reduces risk (Kerberos and application issues).
- Breach Recovery: Changing the KRBTGT account password twice in rapid succession (before AD replication completes) will invalidate all existing TGTs forcing clients to re-authenticate since the KDC service will be unable to decrypt the existing TGTs. Choosing this path will likely require rebooting application servers (or at least re-starting application services to get them talking Kerberos correctly again).
Regarding your “Maintenance Change”, if the Kerberos password is changed before all user and service tickets expire (10 hours by default), then all workstatiions and servers will need to be rebooted. The recommendation is to review Group Policy Default Domain Policy\ Computer Configuration\ Policies\Windows Settings\Security Settings\ Account Policies\Kerberos Policy: Max lifetime for service and user tickets setting. After changing the password once, wait until this time period elapses then reset a second time.
I’ll expand, regarding the “Breach Recovery” you have to wait until all DCs have replicated before you make the second change. After they have been validated to be in sync, make the change again to invalidate any open kerberos tickets. At that point, all systems on the network will disconnect and require reauthentication / reboots.
A few more thoughts on this article:
“A Reddit user raised this great question today that I am not aware of. So I did a little research and here is the breakdown of what it is.” I would suggest doing more research and updating your article. As a Microsoft MVP, people may take your article at face value. If someone follows as is, its dangerous for their domain.
“Note that changing the KRBTGT account password in a 2008 (or higher) DFL will not cause replication issues.” A warning needs to be made here, that Functionality Level 2008 is REQUIRED to be able to support changing the KRBTGT password. if the functionality level is say 2003, Kerberos only supports using the current password, not the previous password. Changing the password with 2003 will not only result in replication issues, it will invalidate all tickets on the domain, forcing everyone and all servers to reboot. That’s a much greater impact than just breaking replication. Changing the password with older functionality level than 2008 is tantamount to the Breach Recovery mode.
Notes should also be made about RODCs using a separate password than RWDCs.
Thanks for the extra info. i highly doubt author cares past they view count.