This is the 287th article in the Spotlight on IT series. If you'd be interested in writing an article on the subject of backup, security, storage, virtualization, mobile, networking, wireless, cloud and SaaS, or MSPs for the series PM Eric to get started.
The first time I implemented BitLocker in an enterprise scenario, it was sort of an afterthought — added to a new laptop rollout and Windows 7 imaging project. At that point all I knew of BitLocker was that I’d enabled it on my trusty pocket flash drive, and it was mildly annoying. That first run was a whirlwind. Three enterprise implementations later, I can tell you one thing for sure: You’ll want to take some time to plan this out.
BitLocker is deceptive. It seems simple in that you can go to the control panel and enable it, choose your method of backing up your Recovery Key, and go about your business feeling safe in your encrypted state. However, to back up, manage and be able to retrieve those Recovery Keys in an enterprise environment, you need to consider a plethora of things. There’s no definitive guide out there that I’ve found, so here is a brief overview of the changes you’ll need to make before you dive in.
Client hardware
If you plan to encrypt the OS drive on client PCs, you’ll want to make sure they have a TPM 1.2 chip built in. Without it, you need to use a USB Startup Key, and that’s just a pain for anyone. On top of just having a TPM, it needs to be initialized and ready for ownership — which may require changes in each client machine’s BIOS. You’ll also need to make sure that the OS drive is partitioned with a 350mb System Reserve partition.
Infrastructure changes
You’ll definitely need to make at least one change to Active Directory, which adds an Access Control Entry to allow each computer to write to its own AD object, allowing the Recovery Keys to be written to AD. In order to view these keys, you will need to install the BitLocker Recovery Password Viewer, and even then, only domain admins will be able to see the Recovery Keys. If you’re still working with 2003 Domain Controllers (clock’s ticking guys — upgrade!), you’ll need to extend the AD schema as well.
You’ll need to edit Group Policy to tailor the BitLocker requirements to fit your needs and sort out how to best apply it in your infrastructure.
You can integrate BitLocker into your task sequences in both the Microsoft Deployment Toolkit (MDT) and System Center Configuration Manager (SCCM) as part of your future deployments. With MDT and SCCM you can use an “Enable BitLocker” step to automate full-disk encryption. SCCM gives you the additional optional “Pre-Provision BitLocker” step, which does used-space only encryption that allows for extremely fast rollouts of encrypted machines.
Other considerations
Microsoft BitLocker Administration and Monitoring (MBAM — no, not Malwarebytes) is part of the Desktop Optimization Pack (MDOP), and I cannot recommend it highly enough if you’re considering BitLocker. Consider the licensing cost of roughly $10 a seat for all of MDOP, which gives you access to many other useful tools. (That’s a whole different discussion, but go check it out and drool over App-V and AGPM, just to name two). MBAM eases a whole lot of BitLocker pain points, but mainly:
- Compliance reporting — Essential if any hardware goes missing to verify your data is protected
- Self-service web portal — For users to access their Recovery Keys if needed
- Help Desk We Portal — Allows non-domain admins to access Recovery Keys, and allows for some TPM management, along with Audit Reporting to show who has accessed Recovery Keys
- MBAM Client on client PCs — In addition to providing a more user-friendly interface, and taking care of TPM prep, the client allows Recovery Keys to be used only once, and will generate and back up a new one once the existing key is used, ensuring no valid keys are in the wild
Now, the only time BitLocker strands you in Recovery Mode is due to hardware changes. As one last consideration, I’d sleep more soundly at night knowing my users weren’t local administrators. BitLocker isn’t the only reason, but having someone muck around in Device Manager, intentionally or not, could lead to recovery mode at their next reboot (which of course will be at some mission-critical moment, and it will be all IT’s fault).
One last consideration is to educate the users on what they may see. If you require a PIN at startup, that’s a significant change from the usual AD credentials prompt that will probably freak them out.
If using MBAM, be sure everyone knows where the Self-Service Portal is and how to retrieve their Recovery Keys. Also, let your help desk know what to expect when a user calls about being in Recovery Mode (or if they forget their PIN), and be sure they know the steps necessary to retrieve the Recovery Key for the user and walk them through the process.
Above all, remember that BitLocker is, well, mean. It defaults to protecting your data, even from you. You need to have an infrastructure in place to ensure that Recovery Keys are always backed up and accessible. If you are unable to access a BitLocker protected drive, and the Recovery Keys are MIA, your only option is to reformat. All data is lost.
Take your time and plan this out. Given the variety of steps necessary, you could easily be delayed significantly if your company requires change management approvals. Good luck!