Allowing end users to use BitLocker encryption at will is a risky proposition. I strongly recommend storing BitLocker recovery passwords in Active Directory to avoid data loss as a result of lost startup keys or forgotten PINs.
BitLocker, a security feature introduced by Windows Vista, makes it possible to encrypt a workstation's system drive. As great as this option is, a forgotten PIN or a lost startup key can render the volume permanently inaccessible. In this article, I will show you how to cope with such a situation.
When you initially use BitLocker to encrypt a volume, it requires you to either enter a PIN or create a startup key. A startup key is typically loaded onto a USB flash drive and can be inserted any time that you boot the machine. Hopefully, you have memorized your PIN or made backup copies of your startup key, but there's always the possibility that they will be lost. When this happens, you have to use an alternate mechanism for gaining access to the system.
The way to regain access to your system is to access the BitLocker Recovery Password. When you first enable BitLocker, you are asked where you want to save the recovery password. In fact, Vista gives you the option of saving the recovery password on a USB disk, saving the password in a folder or printing the password.
When you try to boot a BitLocker encrypted system without your startup key or you forget your PIN, you will see a screen similar to the one that's shown in Figure A. All you have to do to gain access to the system is enter the 48-digit recovery password. The process of entering the password is tedious to say the least, but it should get you into the system. Once you gain access, you can decrypt the volume, remove BitLocker and then set BitLocker back up from scratch so you can generate a new PIN or startup key.
Figure A
The BitLocker recovery password is 48 digits long.
Although this method for getting back into a protected system works, it has one fatal flaw: It puts the recovery password into the hands of the user who encrypted the volume. This is often the same user who forgot the PIN or misplaced the startup key. What are the odds, do you think, that the user has the recovery password in his possession and stores the recovery password in a responsible manner?
If you believe in Murphy's Law, then the odds are pretty high that the user won't have the recovery password. Fortunately, you can look up BitLocker recovery passwords through the Active Directory Users and Computers console. In order to do that, however, the domain must be configured to store BitLocker passwords and the encrypted workstation must be a domain member.
In order to store BitLocker passwords in Active Directory, all of your domain controllers must be running Windows Server 2003 with Service Pack 1 or higher. The procedure for configuring the Active Directory to store BitLocker passwords is much too long to include in this article, but you can find the procedure here.
If you ever need to retrieve a recovery password from Active Directory, you have to install the BitLocker Recovery Password Viewer. Unfortunately, Microsoft does not make this utility available for download. You can get the password viewer for free by calling Microsoft's support department. The phone number is (800) 936-5700.
Once you install BitLocker Recovery Password Viewer, you can view the recovery password directly through the Active Directory Users and Computers Console. All you have to do is right click on the computer object you want to retrieve the password for and choose the Properties command from the resulting shortcut menu. You will see the password displayed on the resulting properties sheet.
Allowing end users to use BitLocker encryption at will is a risky proposition. I strongly recommend storing BitLocker recovery passwords in Active Directory to avoid data loss as a result of lost startup keys or forgotten PINs.
About the author: Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox.
