Even with RODC’s, AD Is Still A Distributed System
Posted by BPuhl on February 21, 2009
Yes, it’s true, Active Directory is still a distributed system. (this is the part where you say, “Well, yeah, duh!”) But with Server 2008 and Read Only Domain Controllers, the distributed system changes some. Sure, there’s that “unplanned feature” in ROGC’s that I blogged about last time, but this time it’s different.
Remember back in the day, we had to train application developers that although all DC’s were essentially equal, they were only ‘loosely consistent’, so it wasn’t reasonable to think that you could make a write on one DC, and then immediately query another DC and expect the data to be there. Made sense, but recently in MSIT we found that even our own developers were sort of taking some of this ‘loose consistency’ for granted.
A couple months ago, we had an escalation from one of our regional sites, that all BitLocker installations to laptops in the site (which of course, has an ROGC in it), were failing. Not only were their failing, but they were failing with long and painful latency – in other words, just irk’ing everyone.
With a bit of digging and some investigation with the associated PG’s, we found that when BitLocker was configured on the machine in a site, it would write the recovery key into AD (like we wanted). Of course, there was only an ROGC in the site, it needed a writeable, so the client went out of site and wrote the attribute. Of course, BitLocker is one of those things that you always want to make sure you have the key for, right? So in an attempt to be safe and secure (not to mention, recoverable), the BitLocker process then reads the key back from the DC to make sure that it was written. Makes sense, but you can see what happens here – The attribute was written to a (full)DC in one site, and is read from the ROGC in the local site – which hasn’t replicated in the change. Ooops.
So after batting this around a few times, here were some of the suggestions:
- Before configuring BitLocker, run a script that sets the siteName registry key to a site that has a writeable DC
- Rehome the subnets for the sites which are going to deploy BitLocker to a site which has a full DC for the domain, and then move them back
- “Install this patched version” so that the BitLocker installation behaves better
It’s pretty obvious, the first and second are essentially hokey workarounds to a problem, aren’t anything that will scale to an enterprise deployment by any means, and/or solve the immediate need, but don’t take into consideration the ongoing effect of machines coming up in the site.
Instead we have been “testing” out a pre-release patch for this problem, and it’s working great. Until it’s released, if you run into this problem, you’ll need to do one of the first 2 options above. But it’s probably still worth a call to your local Microsoft guy to let him know that you want the patch.