Freigeben über

BitLocker Drive Encryption Configuration Guide: Backing Up BitLocker and TPM Recovery Information to Active Directory

  • Artikel

Overview

This document describes how to configure Active Directory® to back up recovery information for Windows® BitLocker™ Drive Encryption (BitLocker) and the Trusted Platform Module (TPM). Recovery information includes the recovery password for each BitLocker-enabled volume, the TPM owner password, and the information required to identify which computers and volumes the recovery information applies to. Optionally, you can also save a package containing the actual keys used to encrypt the data as well as the recovery password required to access those keys.

Note

Active Directory is known as Active Directory Domain Services in Microsoft® Windows Server® 2008.

Backing up recovery passwords for a BitLocker-protected disk volume allows administrators to recover the volume if it is locked. This ensures that encrypted data belonging to the enterprise can always be accessed by authorized users.

Backing up the TPM owner information for a computer allows administrators to locally and remotely configure the TPM security hardware on that computer. As an example, an administrator might want to reset the TPM to factory defaults when decommissioning or repurposing computers.

Important

You can save recovery information in Active Directory if your domain controllers are running Microsoft® Windows Server® 2003 with Service Pack 1 (SP1), Windows Server 2003 R2, or Windows Server 2008. You cannot save recovery information in Active Directory if the domain controller is running a version of Windows Server earlier than Windows Server 2003 with SP1.

If you are running Windows Server 2008, follow the same process described for Windows Server 2003 with SP1 or later, with one exception: you do not need to update the schema as described later in this document. However, you must still run the Add-TPMSelfWriteACE.vbs script in order to back up the TPM recovery password in a domain upgraded from Windows Server 2003 to Windows Server 2008.

Important

Perform these steps in a test or pre-production environment prior to rolling out to production environments.

Required files

The following sample scripts and LDF file available from Microsoft are required to configure Active Directory for backing up recovery information:

  • Add-TPMSelfWriteACE.vbs
  • BitLockerTPMSchemaExtension.ldf
  • List-ACEs.vbs
  • Get-TPMOwnerInfo.vbs
  • Get-BitLockerRecoveryInfo.vbs

To download the files, see https://go.microsoft.com/fwlink/?LinkId=78953. The contents of these files and other useful information are included in the following appendices:

Note

If you tested a pre-release or beta version of Windows Vista, and configured your Active Directory installation with earlier versions of the scripts or schema extensions, you must use ensure that you use the final, released versions of these files. In addition, if you ran an earlier version of List-ACEs.vbs, you must remove the previously-added BitLocker-related access control entries (ACEs) before proceeding.

Background

This section provides information about how BitLocker and TPM recovery information can be backed up in Active Directory.

By default, no recovery information is backed up. Administrators can configure Group Policy settings to enable backup of BitLocker or TPM recovery information. Before configuring these settings, as a domain administrator you must ensure that the Active Directory schema has been extended with the necessary storage locations and that access permissions have been granted to perform the backup.

You should also configure Active Directory before configuring BitLocker on client computers. If BitLocker is enabled first, recovery information for those computers will not be added to Active Directory. For more information, see the section Questions and Answers later in this document.

Storage of BitLocker recovery information in Active Directory

Backed up BitLocker recovery information is stored in a child object of the Computer object. That is, the Computer object is the container for a BitLocker recovery object.

Each BitLocker recovery object includes the recovery password and other recovery information. More than one BitLocker recovery object can exist under each Computer object, because there can be more than one recovery password associated with a BitLocker-enabled volume.

The name of the BitLocker recovery object incorporates a globally unique identifier (GUID) and date and time information, for a fixed length of 63 characters. The form is:

<Object Creation Date and Time><Recovery GUID>

For example:

2005-09-30T17:08:23-08:00{063EA4E1-220C-4293-BA01-4754620A96E7}

The common name (cn) for the BitLocker recovery object is ms-FVE-RecoveryInformation. Each ms-FVE-RecoveryInformation object has the following attributes:

  • ms-FVE-RecoveryPassword
    This attribute contains the 48-digit recovery password used to recover a BitLocker-encrypted disk volume. Users enter this password to unlock a volume when BitLocker enters recovery mode.
  • ms-FVE-RecoveryGuid
    This attribute contains the GUID associated with a BitLocker recovery password. In BitLocker's recovery mode, this GUID is displayed to the user so that the correct recovery password can be located to unlock the volume. This GUID is also included in the name of the recovery object.
  • ms-FVE-VolumeGuid
    This attribute contains the GUID associated with a BitLocker-supported disk volume.
    While the password (stored in ms-FVE-RecoveryGuid) is unique for each recovery password, this volume identifier is unique for each BitLocker-encrypted volume.
  • ms-FVE-KeyPackage
    This attribute contains a volume's BitLocker encryption key secured by the corresponding recovery password.
    With this key package and the recovery password (stored in ms-FVE-RecoveryPassword), you can decrypt portions of a BitLocker-protected volume if the disk is corrupted. Each key package will work only for a volume that has the corresponding volume identifier (stored in ms-FVE-VolumeGuid). You must use a specialized tool to make use of this key package.

If you tested BitLocker and Windows Vista prior to its release, you should note the following changes that were made to the attributes of the recovery object since pre-release or beta versions of Windows Vista:

  • GUIDs added to the global catalog to facilitate forest-wide searches (isMemberOfPartialAttributeSet)
  • Use of the confidential bit for GUID attributes (bit 128 of searchFlags) removed
  • Size of each attribute restricted to minimize replication slowdowns in the case of a flooding attack on the Active Directory database (rangeUpper)
  • Updated attribute descriptions for clarity (adminDescription)
  • Additional bit set to save attribute values when creating copies of objects (bit 16 of searchFlags)
  • Additional bit set to create a per-container index for GUID attributes (bit 2 of searchFlags).

For more details about attribute syntax, see the schema extension file in Appendix D: BitLockerTPMSchemaExtension.ldf File Contents.

Storage of TPM recovery information in Active Directory

There is only one TPM owner password per computer. When the TPM is initialized or when this password is changed, the hash of the TPM ownership password gets backed up as an attribute of the Computer object.

The common name (cn) for the TPM attribute is ms-TPM-OwnerInformation.

Configuring Active Directory

Complete the following tasks to configure Active Directory to back up BitLocker and TPM recovery information.

Check general prerequisites

Check the following prerequisites:

  1. All domain controllers accessible by BitLocker-capable clients are running Windows Server 2003 with SP1 or later. On each domain controller, click Start, right-click My Computer, and then click the General tab.

Important

If the General tab lists Windows Server 2003 but no service pack information, you need to upgrade. For more information about upgrading to Windows Server 2003 with SP1, see https://go.microsoft.com/fwlink/?LinkID=43106.

Important

The use of domain controllers running Windows Server 2000 or Windows Server 2003 without SP1 to back up BitLocker or TPM recovery information has not been tested and is not supported. Furthermore, these earlier operating systems lack the Active Directory confidential flag feature used to protect access to BitLocker and TPM recovery information. The confidential flag is a feature available in Windows Server 2003 with SP1 and later. With this feature, only domain administrators and appropriate delegates have Read access to attributes marked with the confidential flag. The BitLocker and TPM schema extension marks selected attributes as "confidential" using the "searchFlags" property. For more information about this flag, see "How the Active Directory Schema Works" at https://go.microsoft.com/fwlink/?LinkID=38556. BitLocker does not impose any requirements on domain or forest functional levels. However, domain controllers running operating systems earlier than Windows Server 2003 with SP1 should be removed from mixed-functional level environments (or upgraded), because backed up BitLocker and TPM information will not be protected on those domain controllers.

  1. You have either Enterprise Admin or Schema Admin privileges in the target forest or are using an account that has been granted appropriate permissions to extend the schema for the target forest.
  2. You have obtained the following files:
    • BitLockerTPMSchemaExtension.ldf
    • Add-TPMSelfWriteACE.vbs

Extend the schema

The following procedure extends the schema to allow information to be saved in Active Directory.

If you have installed a domain controller running Windows Server 2008 Beta 3 or later, doing so has automatically performed the required extensions to the schema, and you do not need to complete this procedure.

If you have installed a domain controller running Windows Server 2008 Beta 2, you must upgrade the schema to sch39 or later, or complete the following procedure.

To extend the Active Directory schema with BitLocker and TPM attributes

  1. Log on with a domain account in the Schema Admins group. This account must be used to extend the schema.

    By default, the built-in Administrator account in the forest root domain is part of the Schema Admins group. For more information, see the section "Granting access rights to make schema changes" in "How the Active Directory Schema Works" (https://go.microsoft.com/fwlink/?LinkID=79649).

  2. Check that your Windows Server installation enables schema updates.

    In Windows Server 2003, Active Directory schema updates are enabled by default. For more information, including the steps required to enable schema updates, see article 285172 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=79644).

  3. Check that you have access to the domain controller that is the schema operations master in the Active Directory forest. Schema updates can only be performed at the schema operations master.

  4. Review BitLockerTPMSchemaExtension.ldf, the LDIF file containing the schema extension.

    For background information about changes made by the schema extension, see Background earlier in this document.

    For reference information about schema extensions, see "How the Active Directory Schema Works" (https://go.microsoft.com/fwlink/?LinkId=79649).

  5. Use the Ldifde command-line tool to extend the schema on the domain controller that serves as the schema operations master. For example, to import the schema extension on a domain named nttest.microsoft.com, log on as a user in the Schema Admins group, and then type the following at a command prompt:

    ldifde -i -v -f BitLockerTPMSchemaExtension.ldf -c "DC=X" "DC=nttest,dc=microsoft,dc=com" -k -j .

    This command should be entered as one line, although it is displayed on multiple lines for readability in this document. The trailing period (".") is part of the command.

    The use of -k suppresses "Object Already Exists" errors if the portions of the schema already exist. The use of -j . saves an extended log file to the current working directory.

For more information about Ldifde parameters, see article 237677 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=79650). Sample output from running this command is included in Appendix B: Sample Ldifde output later in this document.

Set the required permissions for backing up TPM password information

The following procedure adds an access control entry (ACE) so that backing up TPM recovery information is possible.

A Windows Vista client can back up BitLocker recovery information under the Computer object’s default permission. However, a Windows Vista client cannot back up TPM owner information unless this additional ACE is added.

Appendix C: Default Permissions for a Computer Object, later in this document, describes the default Active Directory permissions on the Computer class object that contains the BitLocker recovery information class and the TPM owner information attribute.

To add an ACE to allow TPM recovery information to be backed up

  1. Review Add-TPMSelfWriteACE.vbs, the sample script containing the permission extension.

  2. Type the following at a command prompt, and then press ENTER:

    cscript Add-TPMSelfWriteACE.vbs

This script adds a single ACE to the top-level domain object. The ACE is an inheritable permission that allows SELF (the computer itself) to write to the ms-TPM-OwnerInformation attribute for Computer objects in the domain.

For additional reference information, see "Using Scripts to Manage Active Directory Security" (https://go.microsoft.com/fwlink/?LinkId=79652).

The sample script provided operates under the following assumptions:

  • You have domain administrator privileges to set permissions for the top-level domain object.
  • Your target domain is the same as the domain for the user account running the script.
    For example, running the script as TESTDOMAIN\admin will extend permissions for TESTDOMAIN. You might need to modify the sample script if you want to set permissions for multiple domains, but do not have domain administrator accounts for each of those domains. Find the variable strPathToDomain in the script and modify it for your target domain, for example:
    "LDAP://DC=testdomain,DC=nttest,DC=microsoft,DC=com"
  • Your domain is configured so that permissions inherit from the top-level domain object to targeted Computer objects.
    Permissions will not go into effect if any container in the hierarchy does not allow inherited permissions from the parent. By default, inheritance of permissions is set by Active Directory. If you are not sure whether your configuration differs from this default, you can continue with the setup steps to set the permission. You can then verify your configuration as described later in this document, or by clicking the Effective Permissions button while viewing the properties of a Computer object to check that SELF can write the msTPM-OwnerInformation attribute.

Configure Group Policy to enable backup of BitLocker and TPM recovery information in Active Directory

These instructions are for configuring the local policy on a Windows Vista client computer. In a production environment, you would likely edit a Group Policy object (GPO) that applies to computers in the domain instead.

For more information about configuring Windows Vista GPO in the domain, see the "Managing Group Policy ADMX Files Step by Step Guide" (https://go.microsoft.com/fwlink/?LinkId=79653).

Note

We recommend that you keep the default options when you enable each Group Policy setting. Be sure to read the Explain text before making any changes

To enable the local policy settings to back up BitLocker and TPM recovery information to Active Directory

  1. Log on to the computer as an administrator.

  2. Click Start, type the following in the Start Search box, and then click ENTER:

    gpedit.msc

  3. To enable Group Policy settings to back up BitLocker recovery information to Active Directory:

    1. Open Computer Configuration, open Administrative Templates, open Windows Components, and then open BitLocker Drive Encryption.
    2. In the right pane, double-click Turn on BitLocker backup to Active Directory.
    3. Select the Enabled option.
    4. Verify that the Require BitLocker backup to AD DS check box is selected.

  4. Enable Group Policy setting to back up TPM recovery information to Active Directory.

    1. Open Computer Configuration, open Administrative Templates, open System, and then open Trusted Platform Module Services.
    2. In the right pane, double-click Turn on TPM backup to Active Directory.
    3. Select the Enabled option.
    4. Verify that the Require TPM backup to AD DS check box is selected.

Testing Your Active Directory Configuration

By joining the Windows Vista-based client computers to the domain that you just configured and enabling BitLocker, you can test whether BitLocker and TPM recovery information is backed up to Active Directory successfully.

All user interfaces and programming interfaces within BitLocker and TPM Management features will adhere to your configured Group Policy settings. When these settings are enabled, recovery information (such as recovery passwords) will be automatically backed up to Active Directory whenever this information is created and changed.

If you select the option to require backup, initializing the TPM or enabling BitLocker through any method is blocked until the backup succeeds. In that case, no one will be allowed to turn on BitLocker or initialize the TPM unless the domain controller is configured correctly, the client computer has network connectivity to the domain controller, and no other errors occur during the backup process.

Testing backup with Windows Vista

You should use a Windows Vista-based client computer to test backup.

BitLocker recovery information is backed up when you:

  • Create a recovery password during BitLocker setup, using the wizard available through the Control Panel.
  • Create a recovery password after the disk has already been encrypted, using the manage-bde.wsf command-line tool.

TPM recovery information is backed up when you:

  • Set the TPM owner password during TPM initialization.
  • Change the TPM owner password.

Sample test scenario with Windows Vista

This sample test scenario illustrates how to verify your Active Directory configuration using Windows Vista. The included sample scripts you download assist in the test process.

Important

You should perform additional tests as required to satisfy yourself that everything is working correctly in your environment; do not assume that this scenario will completely test all aspects of your configuration.

Test scenarios can also vary based on your organization's policies. For example, in organizations where users are the Creator Owner of Computer objects they join to the domain, it might be possible for these users to read the TPM owner information for their own Computer objects.

To perform a sample test

  1. Log on to a domain controller as a domain administrator.

  2. Copy the sample script files to a suitable location.

  3. Open a command prompt window and change the default location to the location of the sample script files.

  4. At the command prompt type the following:

    cscript List-ACEs.vbs

    Expected Output: Assuming the default Add-TPMSelfWriteACE.vbs was used and other deprecated ACEs have been removed, there should be only one ACE related to BitLocker and the TPM:

    Accessing

    > AceFlags: 10

    > AceType: 5

    > Flags: 3

    > AccessMask: 32

    > ObjectType: {AA4E1A6D-550D-4E05-8C35-4AFCB917A9FE}

    > InheritedObjectType: {BF967A86-0DE6-11D0-A285-00AA003049E2}

    > Trustee: NT AUTHORITY\SELF

    1 ACE(s) found in DC=nttest,DC=microsoft,DC=com related to BitLocker and TPM

  5. Log on as a local administrator (non-domain administrator) on a Windows Vista client joined to the domain.

  6. Click Start, type the followingin the Start Search box, and then click ENTER:

    tpm.msc

  7. Click either the Initialize TPM or Change Owner Password link.

  8. Set an owner password, and select the option to back up the information by printing or saving to a file as needed.

    Expected Output: The action will succeed without an error message.

  9. Using this same account, open an elevated command prompt window, and then change to the folder in which you have saved a copy of the sample scripts provided with this document.

Note

To open an elevated command prompt window, right-click a command prompt shortcut, and then click Run as Administrator.

  1. At the command prompt type the following:

    cscript Get-TPMOwnerInfo.vbs

    Expected Output: The error “Active Directory: The directory property cannot be found in the cache. “ No information is displayed because a non-domain administrator should not be able to read the ms-TPM-OwnerInformation attribute.

Note

If users are the Creator Owner of Computer objects they join to the domain, it might be possible for these users to read the TPM owner information for their own Computer objects.

  1. Log on as a domain administrator on the same client computer.

  2. Using this domain administrator account, open an elevated command prompt window, and change to the directory in which you have saved a copy of the sample scripts provided with this document.

  3. At the command prompt type the following:

    cscript Get-TPMOwnerInfo.vbs

    Expected Output: A string that is the hash of the password you created earlier.

    As a domain administrator, you should have Read access to the ms-TPM-OwnerInformation attribute.

  4. At the elevated command prompt, type the following to create a recovery password:

    manage-bde -protectors -add -RecoveryPassword C:

    Expected Output: The action will succeed without an error message.

  5. At the command prompt type the following to read all BitLocker child objects of the client computer’s Active Directory object:

    cscript Get-BitLockerRecoveryInfo.vbs

    Expected Output: A domain administrator should see one or more recovery passwords, including the one created in step 14.

    A non-domain administrator will not be able to read these passwords.

  6. Delete any created BitLocker recovery child objects using Active Directory tools such as the Active Directory Users and Computers administrative tool. By default, clients running Windows Vista do not have permissions to delete stale BitLocker recovery passwords.

Troubleshooting Common Problems

The following section discusses some common potential problems and their solutions.

Access permission problems

If you are able to read backed up BitLocker and TPM recovery information using a non–domain administrator account, check that you are running supported installations of Windows Server on all the domain controllers in your network.

Important

Domain controllers running Windows 2000 Server or the initial release of Windows Server 2003 are not supported for backing up BitLocker and TPM recovery information.

Script errors

You might receive an error when you run a script. The following sections explain the causes of and solutions for the most frequent script errors.

Get-TPMOwnerInfo.vbs

When running Get-TPMOwnerInfo.vbs, if an error appears stating "Active Directory: The directory property cannot be found in the cache," you do not have permission to read the TPM owner information attribute object in Active Directory.

General

If an error appears stating "The specified domain either does not exist or could not be contacted,” ensure that the computer is joined to the domain and that network connectivity is available.

If an error appears stating "There is no such object on the server," check that any computer specified by name on the command line is currently connected to the network.

Errors are accompanied by the line number in which the error occurred. Consult the script source code to assist in troubleshooting the issue.

Questions and Answers

This section includes related questions that the BitLocker team has fielded since the first release of this document.

Is this schema part of Windows Server 2008?

Yes, the schema is part of Windows Server 2008. Windows Windows Server 2008 Beta 2 contains the objects that will allow backup of all BitLocker and TPM recovery information in pre-release versions of Windows Vista. The schema update for the released version of Windows Vista matches the changes in Windows Server 2008.

Can I apply the schema update to a Windows Server 2003-based domain controller?

Microsoft supports BitLocker schema extensions only on Windows Server 2003 with SP1 and later and in Windows Server 2008. The first release of Windows Server 2003 does not include the confidential flag feature that appropriately locks down access to backed up recovery information.

Is this schema supported by Microsoft for production use?

Yes, this schema is supported through your normal support channels. For more information about Microsoft support options, see https://go.microsoft.com/fwlink/?LinkID=76619.

Is there an event log entry recorded on the client to indicate the success or failure of the Active Directory backup? 

An event log entry that indicates the success or failure of an Active Directory backup is recorded on the client.

However, this log entry is only useful to an extent. Even though an event log entry says "Success," the information could have been subsequently removed from Active Directory, or BitLocker could have been reconfigured in such a way that the Active Directory information can no longer unlock the drive (such as by removing the recovery password key protector). In addition, it is also possible that the log entry could be spoofed.

Ultimately, determining whether a legitimate backup exists in Active Directory requires querying Active Directory with domain administrator credentials.

What if BitLocker is enabled on a computer before the computer has joined the domain?

You might wonder what happens if BitLocker is enabled on a computer before Group Policy has been applied to enforce backup. Will the recovery information automatically be backed up to Active Directory when the computer joins the domain or when Group Policy is subsequently applied?

This functionality is not available in Windows Vista. Generally, joining a computer to the domain is the first step for new computers within an enterprise.

The BitLocker Windows Management Instrumentation (WMI) interface allows administrators to write a script to back up or synchronize an online client's existing recovery passwords. An administrative account can list the recovery passwords of an unlocked volume by using the GetKeyProtectorNumericalPassword method of the BitLocker WMI interface or the "-protectors -get" parameters of the BitLocker command-line tool (manage-bde.wsf).

What happens if the backup initially fails? Will BitLocker retry?

If the backup initially fails, such as when a domain controller is unreachable at the time when the BitLocker setup wizard is run, BitLocker does not try repeatedly to back up the recovery information to Active Directory.

When an administrator selects the Require BitLocker backup to AD DS check box or the Require TPM backup to AD DS check box, if the backup fails, BitLocker cannot be enabled.

When an administrator clears these check boxes, the administrator is allowing a volume to be BitLocker-encrypted without having the recovery information successfully backed up to Active Directory, however, BitLocker will not automatically retry. Instead, administrators can script a backup, as described in the previous question, to capture the information after connectivity is restored.

Does BitLocker encrypt recovery information as it is sent to Active Directory?

Yes, the transmission of recovery information from a Windows Vista client to Active Directory is protected by using Kerberos. Specifically, the connection uses the authentication flags ADS_SECURE_AUTHENTICATION, ADS_USE_SEALING, and ADS_USE_SIGNING.

For more information about Active Directory authentication flags, see https://go.microsoft.com/fwlink/?LinkId=79643.

Note

Once recovery information is transmitted, Active Directory does not store the BitLocker and TPM recovery information in an encrypted format. However, access control permissions are set so that only domain administrators or appropriate delegates can read the stored information when the server is online. Enterprises concerned about offline attacks on branch office servers should consider enabling BitLocker on those servers, once they are upgraded to Windows Server 2008.