A best practice guide on how to configure BitLocker (Part 2)

by Martin Kiaer [Published on 23 Jan. 2007 / Last Updated on 23 Jan. 2007]

A look at BitLocker from an Active Directory point of view and a look at BitLocker and TPM configuration using Group Policies and how to perform key recovery.

If you missed the first part in this article series please read A best practice guide on how to configure BitLocker (Part 1).

In the first part of this series, we took a look at how you could make the most of BitLocker and also some caveats you should be aware of before you start using these features. In this second part of the series we’ll take a look at BitLocker from an Active Directory point of view and look at BitLocker and TPM configuration using Group Policies and how to perform key recovery.

Disclaimer

I think it is safe to say, that BitLocker in an Active Directory based environment will probably be the most used scenario. By using BitLocker in an Active Directory based environment, you get all the security benefits from BitLocker combined with all the security, availability and scalability that comes with Active Directory.

But, before we get started, you should be aware of a few disclaimers:

  1. Microsoft hasn’t released their BitLocker Deployment Kit yet, so unfortunately we’re unable to provide you with the official links or copies of the scripts used in this article
  2. Also, we haven’t seen the official BitLocker deployment material that will soon be released, but the scripts we are using are provided by Microsoft. Please note however, that the names and the number of scripts covered in this article, may change when the BitLocker Deployment Kit is released
  3. As soon as Microsoft releases the various scripts and white paper which we mention within this article, it will be updated with the respective links and so on, so that it corresponds with filenames etc. We will let you know when the article is updated through our blogs, so stay tuned!

Prerequisites

Before we get started, let us look at some prerequisites that should be satisfied, enabling you to control BitLocker from Active Directory.

  • You will need to extend the schema in Active Directory
  • If you want to control TPM recovery information from Active Directory, then you need to change the permission on the Computer class object in Active Directory
  • BitLocker Active Directory schema extensions are only supported on domain controllers running Windows Server 2003 with SP1 or newer, Windows Server 2003 R2 and Windows Server “Longhorn”
  • BitLocker is only supported to run on Windows Vista Enterprise, Windows Vista Ultimate, and Windows “Longhorn” Server

Note: While I’m writing this article, Service Pack 2 for Windows Server 2003 has hit RTM. SP2 will not include the BitLocker schema updates. You still have to the run the BitLocker schema extension script explained in this article, after you have installed SP2 on your Windows Server 2003 based setup.

Scripts that are needed

It’s time that we get started, so let us look at the files required to get BitLocker integrated with a Windows Server 2003 based Active Directory:

The following files are required so that your Windows Server 2003 based Active Directory is ready to support BitLocker.

  • BitLockerTPMSchemaExtension.ldf
  • Add-TPMSelfWriteACE.vbs

Use the files below to help verify your BitLocker configuration in Active Directory. We’ll use one of them in our example later on in this article.

  • List-ACEs.vbs
  • Get-BitLockerRecoveryInfo.vbs
  • Get-TPMOwnerInfo.vbs

Extend the schema in Active Directory

After you have verified the prerequisites and verified the scripts, you’re ready to extend your Active Directory so that you can store your BitLocker and TPM recovery information in Active Directory.

The way it works, is that the BitLocker recovery information is stored in a sub-object of the Computer object in Active Directory, which means that the Computer object serves as the container for one or more BitLocker recovery objects associated with a particular Computer object. The reason why I say one or more BitLocker recovery objects is because it is possible to have more than one recovery password associated with a BitLocker-enabled computer, for example if you have encrypted more than one volume on the same computer.

The name of the BitLocker recovery object has a fixed length of 63 characters that consists of the following information:

<Object Creation Date and Time><Recovery GUID>

This can be important to know, if you have more than one recovery key associated with a specific computer, and decide to remove some of the recovery keys for security purposes.

But it doesn’t end here. There’s more information stored with the Computer object. If you’re the lucky owner of a computer with a TPM chip (Trusted Platform module) version 1.2, then you’re also able to store the TPM recovery information in Active Directory. Please note however, that there is only one TPM owner password that can be assigned per computer. When the TPM is initialized or when you change the TPM password, then it gets stored as an attribute of the same Computer object used by BitLocker

Let us start by extending the schema with BitLocker and TPM objects and attributes.

  1. Make sure that you’re logged on a domain controller as a user that’s part of the “Schema Admins” group in Active Directory. (Normally the built-in Administrator account is a member of this group per default)
  2. Make sure that you can connect to the domain controller in your Active Directory that holds the Schema Master FSMO role
  3. For this article, I’m using an Active Directory domain called domain.local. With that info on hand, I run the following command (see figure 1):

    ldifde -i -v -f BitLockerTPMSchemaExtension.ldf -c "DC=X" "dc=domain,dc=local" -k -j .

    The use of the -k parameter suppresses the error message "Object Already Exists" if the portions of the schema already exist.

    The use of the -j . parameters (yes, the dot is part of the parameter) saves an extended log file to the current working directory, which in our case is C:\LDIF.LOG


Figure 1

  1. Make sure that all the schema extensions are applied by checking the LDIF log file before you continue.
  2. The next thing we need to do is set the permissions on the BitLocker and TPM recovery information schema objects. This step will add an Access Control Entry (ACE) making it possible to back up TPM recovery information to Active Directory. Run the following command (see figure 2):

    cscript Add-TPMSelfWriteACE.vbs


Figure 2

And that’s it. You have now extended the schema in Active Directory and prepared it for BitLocker and TPM support.

You’re now ready to modify the necessary Group Policy settings for both BitLocker and the TPM chip (if your computer supports this feature).

Note: For more information on configuring Windows Vista Group Policy Objects (GPO) on the domain please see the following article series from windowsecurity.com:

  1. From Vista you log on with a domain account that has the rights to modify Group Policies
  2. At the Vista Start | Search command prompt you type GPMC.MSC and press Enter
  3. There are several Group Policy settings you can configure as displayed in figure 3, but the one setting you definitely want to configure is the setting that will enabling backup of BitLocker recovery information to Active Directory:
    • Navigate to Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption
    • Double-click Turn on BitLocker backup to Active Directory Domain Services
    • Select the Enabled radio button


Figure 3

  1. If your client computers support a compliant TPM chip, then you want to enable a Group Policy setting that allows your clients to back up TPM recovery information to Active Directory (see figure 4):
    • Navigate to Computer Configuration > Administrative Templates > System > Trusted Platform Module Services
    • Double-click Turn on TPM backup to Active Directory Domain Services
    • Select the Enabled radio button


Figure 4

Verifying key recovery in Active Directory

The last thing we’ll do is show you how to perform an encryption centrally, where we also make sure that we get a backup of the BitLocker recovery key used by a Vista client computer, which is stored in Active Directory. In our example we’ll use the BitLocker command line utility (manage-bde.wsf).

It should be noted that if you want to use the GUI interface when configuring BitLocker and the TPM chip, then key recovery will still be supported. As long as the Vista machine is a member of domain that satisfies the prerequisites mentioned earlier and the user doing the work is a domain administrator, then the key recovery will happen silently in the background without any user intervention.

BitLocker encryption with TPM support

  1. From the Vista Start Menu, locate the Command Prompt shortcut. Right-click the icon and select Run as administrator
  2. Enter the following command:

    cscript manage-bde.wsf –on –recoverypassword C:
  3. Follow the instructions on the screen to start the encryption process (see figure 5)


Figure 5

  1. While the volume is being encrypted, we can check whether the BitLocker recovery key has been backed up by typing the following command:

    cscript GET-BitLockerRecoveryInfo.VBS

    Notice that the recovery listed in figure 6 below matches the recovery key created in the previous step and listed in figure 5.


Figure 6

Conclusion

In this two-part series, we’ve tried to go beyond the whitepapers and step-by-step articles from Microsoft, and shown you different approaches on how to make the most of BitLocker. These two articles have in no way covered all the areas. There are simply too many. But we have tried to inspire you, so that you have enough information to let you move on and explore all the various (and sometimes hidden) features in BitLocker.

BitLocker is in no way a perfect hard disk encryption tool. It has many shortcomings, such as poor pre-boot authentication and lack of support for multi-factor authentication (besides TPM support and standard USB key) and BitLocker is a bit cumbersome to configure. If you want better multifactor support, Vista support and even full server encryption, then alternatives such as SecureDoc from WinMagic would be a better option. But BitLocker is still a big leap forward compared to what we have seen so far from Microsoft and it will be interesting to see the next version of BitLocker by the end of the year.

If you missed the first part in this article series please read A best practice guide on how to configure BitLocker (Part 1).

External Links

Windows Vista BitLocker Client Platform Requirements

Specs and Whitepapers

Trusted Computing Group (TCG) Website

Microsoft’s BitLocker Blog

Advertisement

Featured Links