jmbrinkman

Posts Tagged ‘Hercules’

A Heraclean Task? Active Directory, Kerberos and the krbtgt account.

In Active Directory, Kerberos on November 11, 2011 at 10:54

Hercules presenting Cerberus to Eurystheus

Does any of this sound familiar?

  • All domain controllers have been logically corrupted or physically damaged to a point that business continuity is impossible; for example, all business applications that depend on AD DS are nonfunctional.
  • A rogue administrator has compromised the Active Directory environment.
  • An attacker intentionally—or an administrator accidentally—runs a script that spreads data corruption across the forest.
  • An attacker intentionally—or an administrator accidentally—extends the Active Directory schema with malicious or conflicting changes.
  • None of the domain controllers can replicate with their replication partners.
  • Changes cannot be made to AD DS at any domain controller.
  • New domain controllers cannot be installed in any domain.

(Source).

When any of the above is true you know that you have a problem. It’s under these circumstances that a Forest Recovery could be necessary. I’ve never been in such a situation and I sincerely hope I never will be. But let’s assume that you are looking out over the smoking ruins of your Active Directory forest and have found someone else to blame it on – what to do next? Either you will actually have a good restore procedure in place based upon Technet or you will Bing for it 😉

Now the procedure itself is pretty straightforward – make sure all DC’s are down and out and restore one DC from a valid backup starting with your forest root domain. There are a lot of steps in between – but hey – if my forest is down and Microsoft tells me to jump through a flaming hoop in my underwear, smoking a cigar and shouting “Developers, Developers, Developers!” – I will do just that.

One of part of the procedure that has always interested me is where you try to make sure no rogue DC screws up your non-authorative restore by replicating the corrupt right back at you. You might wonder why. Well first of all if anything will enable you to really get an understanding of Kerberos and replication – trying to break it will. Secondly let’s assume you make a mistake during the procedure (or perform any of of the steps in the wrong environment when testing 😉 ). The steps are:

Pre-recovery

Step 3 – Shutting down all other writable domain controllers. That seems logical. If they are shut down they can’t replicate.

Recovery:

Restore the first writable domain controller for the forest root domain, steps 8 to 11

  • Delete server and computer objects for all other domain controllers in the forest root domain.
  • Reset the computer account password for the domain controller you are restoring (twice)
  • Reset the krbtgt password (twice)
  • Reset the trust password (if any – and twice). This steps seems fairly logical as well – it’s basically the same thing as deleting the computer accounts for the DC’s in your forest.

In a note, the procedure on Technet tells us that these steps are needed in order to prevent replication – but not how those steps will prevent it. Let alone what will happen if you fail to perform any of the steps. Others have touched on this subject, Jane Lewis (in 2006..) devoted a very informative blog post to the subject: The KRBTGT Account – What is it ? . However this only tells us about the krbtgt password reset – and doesn’t really tell us how this reset will stop replication. In order to grasp the whole concept we will have to take a closer look at the Kerberos authentication process.

Triple headed monster

Kerberos – named after the hell hound of classic mythology which guarded the underworld making sure only dead people could enter – is a authentication protocol. For a good introduction to Kerberos as used in Windows see Kerberos Explained by Mark Walla or check the IETF RFC’s on the subject. The authentication process consists of three actors: a client, a server and a third party – the Key Distribution Center (KDC). Hence the analogy with a dog with three heads.

AD and Kerberos

Active Directory replication uses Kerberos Mutual Authentication to authenticate before a replication operation can be performed. Now I want to try to describe the scenario where you have just restored the first writable DC in your forest root domain and a rogue DC exists in the same domain which contains newer (but corrupt!) data and wants to replicate that data really really bad.

The above diagram shows two ways authentication might occur – however unless the KDC service on DC2 would be broken or otherwise unavailable I think that a DC, as a Kerberos client, will always connect to it’s own KDC. And since a service ticket will be encrypted with the service key by the KDC – TGS, and the service key for DC1 on DC2 will be different from the service key on DC1 – DC1 will never be able to decrypt it.

So why would you have to reset the krbtgt password as well? If the DC1 and DC2 both have different keys for each other ( DC1 had it’s password reset so it’s not equal to the password known by DC2 and DC1 doens’t have a password for DC2 because we removed it’s computer account from the restored AD) there is no way in Hades they will be able to communicate.

The only scenario I could think of where not resetting the krbtgt password would have any serious consequences would be:

  • DC2 uses it’s TGT ticket from it’s own KDC – AS to connect to the KDC – TGS on DC1
  • DC1 will issue a service ticket to DC2 – encrypted with correct service key and the client key contained in the TGT
  • DC2 will then contact the DC1 in order to trigger replication
  • When DC2 presents the service ticket, decrypt it (and validate the authenticator) and create an access token based upon the SID in the ticket.

Now I’m not sure if: a) a client would ever use a it’s own KDC – AS but another KDC – TGS b) an access token could be created and/or the authorization could be given to a client that no longer exists in AD Now to determine if this scenario is even possible I would have to test this in a LAB and in due time I will – but I’d also love to hear from someone else who already tried something similar or has more theoretical knowledge about how this process works. Of course – even if resetting the krbtgt account has little or no effect it won’t hurt to do it.

Even if you would reset this account on an active and healthy AD you shouldn’t experience any real issues except that all previously created TGT’s are invalid on the DC you changed it on and any new TGT’s issued by the DC you changed it on will be invalid on all other DC’s. This could lead to a service disruption for users at least until the new krbtgt password is replicated through the forest ( and that is something for which I unfortunately have seen “test” results from a production environment). The step is even mentioned in certain kb articles by MS to resolve certain problems with Kerberos authentication – without any warning or information on the risk and impact.

Event ID 14 – Kerberos Key Integrity

Event ID 10 – KDC Password Configuration

But I do get an uneasy feeling performing steps in procedure which is so complicated and crucial without knowing why I am performing said steps – and that’s where the analogy with Heraclean tasks comes into play. Hercules actually had to perform two extra tasks to atone for his sins (slaying his sons after being driven mad by Hera) because he didn’t read the fine print and two of his labours weren’t counted by Eurystheus…which forced to him to confront Kerberos in the first place…

This blog has moved to mutiplechoicesystemsengineer.nl.