In Short:

  • Mainly comes down to the multi-master authentication model
  • We need a secret that is shared by all the domain controllers
  • Because krbtgt is known to all, any domain controller is able to process a request, not just the domain controller that started the kerberos dance.

More Information:

It's defined in RFC 1510 and Microsoft stuck to the script. But in the Active Directory Kerberos implementation there are some additional notes:

  • The account, krbtgt, is created automatically when a new domain is created. 
  • It can't be deleted
  • The name cant be changed
  • The password is created automatically. 

So the krbtgt password is important. It is used to derive a secret key for encrypting and decrypting the TGTs and, its a replicated AD account so all the KDC's are encrypting things with the same password. You can imagine that if the password is different on domain controllers there are going to be problems as users bounce between domain controllers for service tickets. It sounds somewhat unlikely given that the account is replicated until you start to think about ways this could happen: virtualized DC's that revert to an old snapshot when the password was different, DC's that are failing replication that are 'fixed' sometime after a password change operation; <insert other things that shouldn't be going on here>.

So?

I bring this up in the context of krbtgt password rotation

It's actually reasonably simple to do now because Microsoft have released a script that attempts to make the process as smooth and safe as possible: https://www.microsoft.com/security/blog/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/ 

Why would you do that?

If you had reason to believe that the domain had been compromised.

Golden ticket creation is based on the krbtgt account and its straightforward with mimikatz on a compromised domain controller:

privilege::debug
lsadump::lsa /inject /name:krbtgt

then take the hash from " * Primary > NTLM" and use it like this:

kerberos::golden /domain:yourdomain.com /rc4:the-hash /user:goldenticketaccount /id:500 /ptt

Microsoft mention this on the blog hosting the rotation tool:

"One way to help mitigate the risk of a bad actor using a compromised krbtgt key to forge user tickets is by periodically resetting the krbtgt account password. Resetting this password on a regular basis reduces the useful lifetime of krbtgt keys, in case one or more of them is compromised.

In terms of impact to the organization, its possible that you might have something pop up - given that you are changing the password of the principal that encrypted all the live tgt's in the organization. However, after doing this on multiple occasions over the past couple of years (in large environments)  i am yet to see an incident.