{"id":1441,"date":"2015-02-18T23:28:00","date_gmt":"2015-02-19T04:28:00","guid":{"rendered":"http:\/\/adsecurity.org\/?p=1441"},"modified":"2015-02-19T21:14:17","modified_gmt":"2015-02-20T02:14:17","slug":"interesting-krbtgt-password-reset-behavior","status":"publish","type":"post","link":"https:\/\/adsecurity.org\/?p=1441","title":{"rendered":"Interesting KRBTGT Password Reset Behavior"},"content":{"rendered":"

Following up on Twitter conversations (@passingthehash, @scriptjunkie1, gentilkiwi, etc) on the new KRBTGT Password Reset Script<\/a> and Skip Duckwall’s (@passingthehash) blog post on how KRBTGT password changes work<\/a>.<\/p>\n

Microsoft KB2549833 states that the KRBTGT password is set automatically<\/a> to a random string when a new password is entered.<\/p>\n

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.<\/p><\/blockquote>\n

Benjamin Delpy posted on Pastebin <\/a>the RPC calls performed when the KRBTGT password is changed.<\/p>\n

[rpc call]
\nSamrSetInformationUser
\nSampStoreUserPasswords
\nSampRestrictAndRandomizeKrbtgtPassword
\nSampGenerateRandomPassword
\nCDGenerateRandomBits<\/p><\/blockquote>\n

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.
\nMore information on KRBTGT.<\/a><\/p>\n

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.<\/p>\n

I decided to try this out in an isolated lab environment with 4 DCs (Windows Server 2008 R2 DFL):<\/p>\n