Wireless SSID and password
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.
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.
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.