Long term data, I’d like to introduce you to my friend "Life Cycle Management"
Posted by BPuhl on March 14, 2008
Left Hand – So like all the good little Active Directory administrators out there, we here in MS IT run some scripts against our forests every month or so, to delete old/stale machine accounts. This is sufficiently important, that Joe even has a dedicated tool to do just this function. Within MS IT, where we let all auth’d users join machines to our domain, and we have labs that are flattening and rebuilding machines at incredible rates (thousands per day), we can end up with a lot of stale machine accounts. So…we whack ’em.
Right Hand – So like all good little IT shops (that are ridiculously aggressive at deploying technology), we’re starting to enforce BitLocker drive encryption on users laptops. Weeeee….finally we get some security when our users decide to get on the airplane, while their laptop is still trying to finish it’s drink at the bar (our users would never drink themselves, but most laptops are lushes). And being that we’re an enterprise and all, it’s a good thing that the BitLocker team created an enterprise management solution for BitLocker recovery key retrieval – it stores them in Active Directory….
….as an attribute on the machine account…
Right hand, I’ve got somebody that I’d like you to meet. This is the left hand.
So seriously you think, how big of a problem could this be? Well, like most things, it’s kind of an edge case, but the problem is that you’re almost guaranteed to hit the edge case many times per year (so then is it really an edge case still?) What’s required is that somebody has a laptop. With BitLocker configured on the drives. And they are off the network for 45+ days. And they cannot remember their BitLocker key when they fire up their laptop. How often do you think THOSE planets will align? Seriously, I don’t know…but here are some things that I am fairly sure of:
- When some of the more senior folks hit a certain level, they take a sabbatical, of a couple of months at least. We have a lot of senior people in the company.
- Many people will save up vacation, until the end of a significant event, like a ship cycle. A product RTM’s, and 6 or 8 week vacations start
- Most new parents will take a full 8 weeks infant care leave, and some will even take up to 12.
- We’ve got more than our fair share of road warriors who never VPN into the network, and fairly frequently get their machine accounts whacked
These are just a few of the groups that I can think of that start to fall into this category. Next, we need some of these people to not use their laptops long enough that they forget how to unlock their drives, lose the thumb drive with the keys on it, or whatever… And finally, they need to make a big enough deal about not getting into their machine, that we either need to restore their comp accounts in AD to get their recovery key, or else we need some other system that can store these things.
At this point, you’d probably figure that there wouldn’t be that many restores required. And hey, we do restores every month (whether we need to or not) just to exercise our DR processes, so shouldn’t be a huge operational hit. right? right. Well, let’s hope so.
One of the things that we are trying to do though, is avoid turning our DA’s into help desk techs. And that’s basically what would happen, because the user would call the help desk, the HD would have to call us, we’d have to go dig up the recovery key info – even if it’s just mounting a backup into snapshot viewer – and then send that back to the HD. So one additional idea that we’re playing around with, is why not have MIIS/ILM synch the data off into a SQL database, and then stick a web front end on it and provide the application to the help desk? One additional benefit to this, is that we could actually keep what would amount to a rolling change history of all keys associated with that computer account, additional volumes, etc….
The jury’s still out on whether or not we should fund this project, but it was an interesting exercise to go through for an hour this morning.
Oh yeah, an interesting side-effect of this idea. Historically, we’ve always said that we wanted the data in AD to be mastered somewhere else, and have that authoritative source synch the data into AD. Could this be a case where we actually want AD to be the authoritative source, and have it’s data synch’d (sunk?) out? Pretty much yes, but the reason isn’t for the authoritativeness of the data, but rather for capturing it’s changes and for extended retention.