BitLocker and Active Directory

Paul Fragale coming to you again from the digital world we live in. Today, I want to share with you some information about BitLocker and storing the recovery keys in Active Directory (AD). What is actually created in AD? What happens when I decrypt a drive and re-encrypt it? What about additional drives? What if the drive was encrypted before I implemented the Group Policy to copy the recovery information to AD?

So let’s dive right in. For this post we are going to focus only on the Windows Vista\2008 implementation. Group Policy is required to configure a client to send the BitLocker recovery information to Active Directory. To set this up please take a look at Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information. A key point to remember is that, it needs to be done before encrypting any drives. If a drive is encrypted before the policy is applied to the computer, it will not upload the BitLocker recovery information to AD. The only solution currently is to decrypt and then re-encrypt the drive after the policy is applied.

Once group policy is configured, then you can then perform the encryption process on a computer. Since you will want to assure yourself that the recovery information is stored in Active Directory, you can check manually. Upon encrypting the drive a new child object is created under the Computer Object in Active Directory. The name of the BitLocker recovery object incorporates a globally unique identifier (GUID) and date-time information, for a fixed length of 63 characters. The class for the BitLocker recovery object is ms-FVE-RecoveryInformation. Inside this child object are the attributes required for bit locker recovery. Here is what you should see under the computer object once you have encrypted a drive.

Here is a view of what is included in that object using LDP:

A description of these attributes can be found in Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information.

Ok, now that you know have an idea of what to look for in Active Directory after implementing BitLocker, let us discuss the administration pieces. What does happen if I decrypt a drive? Well first of all, AD is just a storage container. There are zero functions AD will perform to validate, maintain or update this information. This is completely handled by BitLocker. BitLocker does not notify AD of a drive decryption so the ms-FVE-RecoveryInformation object does not get removed. So if the user re-encrypts the drive, then Bitlocker will sync new information to AD. So what you will see is two entries for the same drive. And taking that a step further you will also see a new entry for each drive encrypted on that system.

Some key things to remember:

1. Every drive encrypted creates a new child object. This includes additional drives.

2. The Group Policy for storing the recovery information in Active Directory needs to be configured and applied to any computer before encrypting the first drive.

3. If you decrypt a drive the Bitlocker recovery information in Active Directory will remain. It is not updated. If a drive is later re-encrypted, then a new child object will be created. The existing ms-FVE-RecoveryInformation object is not deleted or modified.

4. Active Directory is just a storage location for Bitlocker recovery information. All functions are handled by the Bitlocker application on the computer where the drive is encrypted.

Well that is all I have for now. Hopefully this helps answer some of the more common questions about implementing BitLocker into your Active Directory.

Until next time,

Paul ‘Fragale