Microsoft Finally Releases Guidance and a Script to Change the KRBTGT Account

So Microsoft recently released a zipfile which contains both a document and a powershell script that can be used to change the KRBTGT in a domain.  Before doing anything, RTFM that comes with it and obviously run it in a test environment and make sure that it doesn't eat kittens in your environment...

The basic functionality of the powershell script is that it changes the KRBTGT and it will force replication to update the KRBTGT account and validate that it has replicated.

I haven't (and likely won't ) spend a lot of time on the script itself.  However, one of the things that came up on Twitter from @scriptjunkie1 was that the password being set wasn't using a decent random source, so the password wouldn't be as random as it could be.

However, based on conversations I've had with folks at Microsoft, this password doesn't matter.  This is of course undocumented and honestly, this could potentially lead to problems with clever administrators, however I will get to this a little later...

So, in this case I set up a throwaway Windows 2008 R2 domain controller.  I used Mimikatz to dump the KRBTGT hash.

So, by default, the KRBTGT account has a random 32 byte unicode password assigned to it that is completely unprintable, so it's easiest to just see the hash...

I am using this 8 character complex, yet terrible, password.  If an actual account was set to this, the NT hash would look like the above screen.

Using the 'net user' command, we can set the password for the KRBTGT account, but as you can see above, the hash from setting the password to '1qaz@WSX' is not the same hash from above.  Ok, what happens if we do it again? 

So, the hash changes again.  Even though we set it to the same password, it changes again to a random password / hash.

One thing to note, even though the password is completely ignored, it needs to clear whatever the password policy is in play on the domain.

So, why is this behavior a bad thing?  Well Microsoft's unofficial stance is that they want people to use strong passwords (even though it's completely ignored).  However, a clever administrator would INCORRECTLY believe that they could type in the same password on each DC and shortcut the replication process.

So would this completely brick your environment if you did this? Honestly I don't know.  Late last year @mubix talked about an environment where the KRBTGT was changed on a semi-constant manner and it didn't break the environment.  So (offline) myself and a few others fiddled with it a bit and it looks like that could work, but only because when the tickets are invalidated the credentials that are cached in memory are immediately resubmitted and new tickets are issued.

So what happens if you fsck up the KRBTGT across multiple domain controllers?  Honestly I don't know and don't really have a good way to easily test this. Do you really want to find out in your environment?


Correction 1:

Benjamin Delpy (@gentilkiwi) says that the KRBTGT password is a 32-byte random password (which would actually be 16 unicode chars).  Since he's poked around in memory on DC's far more than I have, I'm going with his answer :-)  Corrected in the post