Following up on Twitter conversations (@passingthehash, @scriptjunkie1, gentilkiwi, etc) on the new KRBTGT Password Reset Script and Skip Duckwall’s (@passingthehash) blog post on how KRBTGT password changes work.
Microsoft KB2549833 states that the KRBTGT password is set automatically to a random string when a new password is entered.
This occurs because there is special logic when changing the password for krbtgt. While the Active Directory Users and Computers (dsa.msc) snap-in allows you to enter a password, it won’t be used when changing the password. Instead, the Active Directory creates a very long string of random bits to use as the password.
Benjamin Delpy posted on Pastebin the RPC calls performed when the KRBTGT password is changed.
Thanks to the information in the links above, we know that after setting the KRBTGT password to a known value, the DC automagically changes the password to a system-generated password.
More information on KRBTGT.
Skip wonders in his post (linked above) what would happen if an Active Directory admin changed the KRBTGT password manually on several Domain Controllers to “speed up” replication. Any AD admin worth his/her salt knows this a *bad* idea.
I decided to try this out in an isolated lab environment with 4 DCs (Windows Server 2008 R2 DFL):
- DC01: Windows Server 2008 R2 [5 FSMOs]
- DC02, Windows Server 2008 R2 (not patched)
- DC04: Windows Server 2012
- DC05: Windows Server 2012 R2
I wrote a quick PowerShell script that stops all Domain Controller replication in Active Directory, changes the KRBTGT password to a known value (“Password99!”), and restarts replication. After re-enabling replication across all DCs, I forced replication to ensure all DCs were communicating correctly. I was able to successfully log on as a user and connect to the SYSVOL share on each Domain Controller.
The KRBTGT password hash is the same as the Administrator account password which is set to “Password99!”
This didn’t change even after rebooting all DCs.
I ran through this test twice with the same result. It seems that at least in my isolated lab testing that changing the KRBTGT password when replication isn’t working can result in the password not being changed by the system. Setting the KRBTGT password with replication occurring normally results in a random, system-generated password.
NOTE: This is an isolated lab test and may not be representative in a lab environment.
Password Hash on DC04 after manual KRBTGT password change to “Password99!” before AD replication is re-enabled.
Password Hash on DC05 after manual KRBTGT password change to “Password99!” before AD replication is re-enabled.
Password Hash on DC01 after manual KRBTGT password change to “Password99!” before AD replication is re-enabled.
What’s interesting is that the password is the same as what’s set (this merits further investigation).
Password Hash on DC02 after manual KRBTGT password change to “Password99!” before AD replication is re-enabled.
After AD replication is re-enabled, this is what the KRBTGT password converged to.
Here’s a comparison of the repadmin output for the KRBTGT account password attribute (unicodePwd) after the password change.
The first block shows that the originating DC for the password change is the DC targeted. Since Replication is disabled, the password change doesn’t replicate out.
The second block shows that the password change on DC01 trumped the others.
The AD credential dump shows the auto-generated password hash is different from the Administrator one (before replication).
After full replication, the KRBTGT password hash is the same as the Administrator password hash, meaning that the password is the same.