Chapter 3: Operations and Recovery Scenarios

Article
08/22/2008

Published: May 29, 2007

The ongoing operation and maintenance of computers that are protected with Microsoft® BitLocker™ Drive Encryption (BitLocker) and/or the Encrypting File System (EFS) as described in this guide requires you to plan for a number of scenarios, some of which are complex. This chapter describes key scenarios that your organization might require you to support, including:

Recovering data from systems protected by EFS.
Recovering data from systems protected by BitLocker.

BitLocker Drive Encryption Scenarios

BitLocker recovery absolutely depends on having access to the recovery password. Therefore, all recovery scenarios start with the presumption that the recovery password is available. The requirement to recover BitLocker data might result from any of the following situations:

Installing the BitLocker–protected drive into a new computer.
Upgrading the motherboard to one with a new TPM.
Turning off, disabling, or clearing the TPM.
Upgrading critical early boot components that cause the TPM to fail the validation process.
Forgetting the PIN after the PIN authentication process is enabled.
Losing the Plug and Play USB flash drive that contains the startup key after startup-key authentication is enabled.
Redeploying desktops or laptops to other departments or employees in the organization. Such redeployments could occur for users with different security clearances, which could require data recovery functionality for their computers before they can be cleared for use at a new security level.
Retasking desktops in use. For example, an IT administrator might need to re-install the operating system remotely without losing protected data.

BitLocker encrypts the entire operating system volume, and it can only be decrypted after the volume key is unlocked. If the volume cannot be unlocked, the startup process is interrupted before the operating system can start. During this part of the startup process, you must either provide the recovery password from a USB flash drive or use the function keys to enter the recovery password. (Keys F1 through F9 represent the digits 1 through 9, and F10 represents 0.)

Note Because recovery happens so early in the startup process, the accessibility features of Microsoft Windows® (including high contrast screen displays and screen readers) are not available. If you require these accessibility features, consider ways that you can establish alternate recovery procedures for users who depend on accessibility features.

BitLocker Recovery Methods and Issues

BitLocker recovery requires access to a BitLocker recovery password that is unique to the computer on which it was created. You can save the key on paper, on a USB startup device, in the Active Directory® directory service, or in a file on a network. However, access to this key grants the holder the ability to unlock a BitLocker-protected volume and read all the data that it contains. For this reason, it is critical that your organization establish procedures to control access to recovery passwords, and to ensure that they are securely stored separately from the computers that they protect.

Unlocking Methods

There are three different ways to unlock a BitLocker-encrypted disk:

The BitLocker recovery console, which runs before Windows Vista™ boots, is designed to help users unlock a BitLocker-encrypted operating system volume.
The BitLocker control panel's recovery wizard is designed to help users unlock a BitLocker-encrypted data volume (a non-operating system volume, an alternate operating system volume on the same computer, or an operating system volume from another computer).
The Windows Vista Recovery Environment (WinRE) includes a wizard that you can use to unlock BitLocker-protected operating system or data volumes. WinRE is available from a Windows Vista DVD or within a recovery partition available from some computer manufacturers.

In all cases, you can use the 48-digit recovery password to unlock access to the encrypted drive. This password can recover BitLocker-encrypted information regardless of the protection method (TPM, TPM with PIN, TPM with startup key, and so on) that you use. This capability preserves the ability of BitLocker to recover the encrypted information. For example, if the PIN is lost, users can regain access to the encrypted drive by entering the recovery password.

During a recovery, the BitLocker recovery console displays two pieces of information:

The drive label. This information is defined in a three-part string that is composed of the computer name, disk volume name, and the password generation date (for example, CATAPULT OS 1/15/2007).
The password ID. This information is defined in a 32-digit hexadecimal string that uniquely identifies each BitLocker recovery password (for example, 4269744C-6F63-6B65-7220-697320537570).

Users and support professionals can use these identifiers to ensure that they supply the correct recovery password. They are especially useful when the password is retrieved from Active Directory.

User-Initiated Recovery

Users can recover their own data by using a recovery password. However, they must know or have access to the password on a USB flash drive or in another accessible format. After they obtain access to the correct password, they can use either the pre-boot recovery console or WinRE tools to unlock the volume and resume operations.

Helpdesk-Assisted Recovery

When planning the BitLocker recovery process, the first step is to consult your organization's current best practices for recovering sensitive information. For example, how does your organization handle lost Windows passwords? What procedures does your organization use to handle smart card PIN reset requests? Use these best practices and related resources (people and tools) to help formulate a BitLocker recovery model.

Preparing for Recovery

Before you complete your BitLocker deployment, you should prepare for recovery requests to ensure that you can meet them in a timely manner.

Begin by reviewing the Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information guide, which describes how you can use Active Directory to store key recovery information. This document includes a number of tools and scripts that might be useful in establishing your recovery operations.

Microsoft developed the BitLocker Recovery Password Viewer tool (an extension to the Active Directory Users and Computers MMC snap-in) to provide a way to view BitLocker recovery information as a property of a computer object. This capability makes the recovery information more easily accessible to help desk staff. You should carefully review your operational policies and Active Directory permissions delegation to ensure that you restrict access to recovery information to only those support personnel who need access.

To obtain the BitLocker Recovery Password Viewer, refer to the instructions in the Microsoft Knowledge Base article 928202, "How to use the BitLocker Recovery Password Viewer for Active Directory Users and Computers tool to view recovery passwords for Windows Vista." After you obtain the tool, install it according to the instructions in the KB article. You will need to use an account that has Enterprise Administrator permission the first time you install the tool in a domain, but subsequent installations only require that the installation account have local Administrator privileges for the computer on which you install the tool.

Note Microsoft recommends that you establish a user identification policy to verify which computers in your enterprise belong to which users before you issue any recovery passwords.

Executing a Recovery

Help desk technicians can use the following recovery procedure.

To successfully complete a recovery

Obtain the name of the computer from the user. If the user does not know the computer name, you can derive it from the drive label string (if the computer name has not been changed).
Verify the user's identity using an appropriate authentication mechanism.
Retrieve the BitLocker recovery password from the computer object in Active Directory. You can do this with the Get-BitLockerRecoveryInfo.vbs script, which is included with the Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information guide. Alternatively, you can use the BitLocker Recovery Password Viewer (if installed) by doing the following:
1. Open the Active Directory Users and Computers snap-in.
2. In the Active Directory Users and Computers snap-in, locate and then click the container in which the computer is located. For example, click the Computers container.
3. Right-click the computer object, and then select Properties.
4. In the Properties dialog box, click the BitLocker Recovery tab to view the BitLocker recovery passwords that are associated with the specific computer.
If the computer name is not available, you can retrieve the password using the password ID as input when you run the Get-BitLockerRecoveryInfoByID.vbs script, or you can use the BitLocker Recovery Password Viewer:
1. In Active Directory Users and Computers, right-click the domain container, and then click Find BitLocker Recovery Password.
2. In the Find BitLocker Recovery Password dialog box, type the first eight characters of the recovery password in the Password ID (first 8 characters) box, and then click Search.
Provide the recovery password to the user. The password will be required each time the computer reboots unless a startup key or PIN is provided or the user turns off BitLocker.
If the user did not forget or lose their PIN or startup key, make arrangements to examine the system to determine what caused the recovery in the first place. It is important to identify problems with the TPM, boot files, or other issues that require recovery to ensure that they are properly handled and that they do not affect other systems.

After the root cause that forced the recovery is identified, Microsoft recommends resetting BitLocker protection on the drive. Choose from the following method according to the cause of the recovery:

Reset the recovery password. This method creates a new recovery password and invalidates all previous passwords.
Reset the PIN or USB startup key. This method replaces a lost PIN or USB startup key. The Manage Keys link in the BitLocker Drive Encryption control panel allows you to reset a lost PIN or duplicate a USB startup key.
Reset TPM validation measurements. This method renews the snapshot that the TPM uses to validate boot files. Reset TPM measurements only if you know why the validation process failed, and if you have determined that this failure is benign (for example, a known user BIOS update). Otherwise, consider flattening and rebuilding the computer.

Using the BitLocker Repair Tool

The BitLocker Repair Tool (available from Microsoft Knowledge Base article 928201, "How to use the BitLocker Repair Tool to help recover data from an encrypted volume in Windows Vista") can help access encrypted data if the hard disk has been severely damaged. This tool can reconstruct critical parts of the drive and salvage recoverable data. A recovery password or recovery key package is required to decrypt the data. The tool is designed to be used in cases in which Windows Vista cannot be started or the BitLocker recovery console is not available. If you supply the recovery password, the tool will attempt to read the volume-specific encryption key from the volume. If the volume-specific key is damaged or unreadable, you might need to use the recovery key package directly. The tool essentially uses the recovery password or key package you provide to allow you to mount the disk and attempt to recover data from it. Note that the recovery tool will only be useful when data on the disk remains readable. If the disk failure is severe enough, the recovery tool will not be able to read encrypted data to decrypt it.

Before running the BitLocker Repair Tool, you will need the following:

The original BitLocker encrypted volume.
A disk volume with a sufficient amount of space to hold data from the encrypted volume. Microsoft recommends that you use an external hard disk to hold this information.
A USB flash disk or other similar removable storage device with the BitLocker recovery information for the damaged volume.
The BitLocker Repair Tool itself.

Complete instructions for running the BitLocker Repair Tool can be found in the KB article referenced earlier in this section.

Encrypting File System Scenarios

EFS recovery depends on having access to the key material used to protect the file encryption key (FEK). This material could be the user's EFS certificate or a data recovery agent (DRA) certificate. There are three primary scenarios for recovering data from EFS:

The user encrypted data that should not have been encrypted. In this scenario, the recovery model is simple: turn off encryption for the specific data items.
A user loses access to their key material.
An organization needs to restore access to data when the original user (or the associated certificate) is not available to do so.

EFS Recovery Methods and Issues

If a user’s private EFS decryption key is lost or corrupted, they won't be able to access EFS-protected files until the decryption key is recovered. This section provides information about various EFS recovery scenarios that depend on the original recovery method that was planned and deployed.

Importing EFS Keys

If a user loses their EFS private decryption key, the simplest recovery method is to import their EFS digital certificate (and private key) from a known good backup. Previous chapters described several methods to back up EFS keys.

Note For successful recovery, the user’s EFS key backup must include their EFS private encryption key. Also, the user must remember their protection password, which was established during the key export.

To re-import a previously exported EFS key

Log on to Windows using the account of the user who needs to import their EFS key.
Allow the user to access a copy of their exported EFS digital certificate and private key. The exported file name should end in .pfx.
Double-click the exported EFS file.
In the Certificate Import Wizard dialog box, click the Next button.
If needed, type the EFS digital certificate’s location and name and then click Next.
Type the protection password that was established during the EFS certificate export and then click Next.

Figure 3.1. Certificate password prompt in Certificate Import Wizard
To allow the Certificate Import Wizard to import the EFS certificate into the correct default store, select the Automatically select the certificate store based upon the type of certificateradio button, and then click Next.

Figure 3.2. Certificate store location prompt in Certificate Import Wizard
In the final screen, click Finish.

The user should now try to access a previously EFS-protected file. If successful, the user’s backup EFS key should be replaced into its original secure location. Any copies that were made should be deleted, and the Recycle Bin should be emptied.

Using Data Recovery Agents

Another common EFS recovery scenario is to use an EFS data recovery agent (DRA). If you correctly configure the DRA before a file is encrypted, the DRA will automatically be used with that file. You can also add DRAs to existing files after their initial encryption.

To use a data recovery agent

Log on to Windows using the DRA’s user account. You must use a computer that can access the files to be recovered.

Note A DRA can import their EFS DRA digital certificate if it is not already installed by using the instructions in the previous section.
Access the location of the files or folders to be recovered.
Remove the EFS attribute from these files or folders by using Windows Explorer or the Cipher.exe /D command.
Log off and let the originally affected user log on.
The user can then re-enable EFS protection on the files, if they want. Windows will regenerate an EFS certificate if needed.

Recovering Archived Keys

If the user’s EFS digital certificate and private keys were archived by a participating certification authority (CA), a key recovery scenario is appropriate. This section discusses EFS key recovery using Windows Server® 2003 Certificate Services.

Note For key recovery to be available, the EFS certificate template that was used to create the EFS digital certificate and to encrypt files and folders must be configured for key archival.

There are three basic steps to key recovery:

The Certificate Services Certificate Manager retrieves the user’s EFS digital certificate from the key archival store.
The Certificate Manager decrypts the user’s private key, and then stores it in a PFX file.
The user imports the PFX file, which re-adds their EFS digital certificate and private key to the certificate store on their local computer.

The recovery process is straightforward but requires two intermediate steps: identifying the user's EFS digital certificate serial number and recovering the certificate itself.

Identifying the User’s EFS Digital Certificate Serial Number

The first step of key recovery is to identify the user’s EFS digital certificate serial number. Certificate Services requires this serial number to determine which certificate to retrieve from the archive.

To identify an individual user's certificate serial number

Log on to Windows with a user account that is allowed to manage Certificate Services.
Open the Certification Authority console and connect to an authorized Certificate Services server.
Expand the Certification Authority node, and then click the Issued Certificates node.
On the View menu, click Add/Remove Columns.
In the Add/Remove Columns dialog box, in the Available Column list, click Archived Key, and then click Add.
Use the Move Up or Move Down buttons to move the Archived Key field up or down in the column listing to make finding the key easier, and then click OK.
The Archived Key field should now appear in the displayed columns listing and indicate which keys have been archived.
Find the correct EFS digital certificate. Ensure it is the most current issued and archived EFS certificate. Write down the serial number of the certificate (it is required for recovery).
Close the Certification Authority console.

Recovering a User’s EFS Certificate and Key

When you have the user's certificate serial number, you can recover the actual certificate and associated key material from the Certificate Services server. To do so, you need to use the Certutil command-line tool to query the CA and retrieve a PKCS #7 file that contains the key recovery agent’s (KRA's) certificate(s) and the user certificate with its entire certificate trust chain. The inner content is an encrypted PKCS #7 structure that contains the private key (encrypted by the KRA certificates).

To decrypt the PKCS #7 encrypted output file, the logged on user must be a key recovery agent or have the private key of one or more of the KRAs for the target encrypted output file. If the user recovering the key from the certificate store is not a KRA, the user must transfer the encrypted output file to a user who holds a KRA private key for further processing.

To recover a user's certificate and private key

Log on to Windows with a user account that is allowed to manage Certificate Services.
Open a command prompt window. At the command prompt, type Certutil -getkey <number> <name>where number is the serial number of the certificate that should be recovered, and name is the output file name where you want to store the certificate.This command attempts to perform the recovery from any available enterprise CA in the forest. If a specific CA is to be targeted instead of all enterprise CAs in the forest, use the following syntax:Certutil -config <computer name\CA name> -getkey <number> <name>
At the command prompt, type the following command:Certutil -recoverkey <file name> <filename.pfx> –p <password>where file name is the encrypted output file created in the previous step, filename.pfx is the new output file name for the user’s EFS private key in PKCS #12 format, and password is the password for the resulting filename.pfx file.
Enter and confirm a strong password for the file when prompted.
Provide the user the given password through a secure mechanism that is separate from the file itself to ensure strong security in the recovery process.
Deliver the PFX file to the user through a secure delivery mechanism.
Provide the user with the instructions in the "Importing EFS Keys" section earlier in this chapter.

Restoring Data Using an Offline Recovery Agent

When you need to recover data and offline recovery agents are used, you must restore the offline recovery agent certificate before you execute the recovery. This process is straightforward and can be performed using individual steps described in detail elsewhere in this guide:

Use the Active Directory Users and Computers MMC snap-in to enable the Active Directory user account used by the recovery agent so it can be used to log on to the recovery computer.
Use the recovery agent user account to log on to the computer on which the recovery event will take place.
Import the recovery agent digital certificate and private key.
Recover the necessary files and folders.
Remove or re-export the recovery agent certificate and private key. If you re-export the certificate and key, remove them from the network and store the exported version securely.
Disable the recovery user account.

Migrate to a New Computer

Users often migrate their work environments from one computer to another. These migrations happen for a wide variety of reasons, including hardware replacement, computer upgrades, or job changes. Special steps must be performed when migrating user data from one computer to another to ensure continued access to data that is protected by EFS. The basic process requires you to complete the following tasks:

Migrate the EFS certificates and their associated key material from the old computer to the new one.
Create data recovery agent (DRA) certificates, if desired.
Migrate the encrypted files and other user data to the new computer.
Test the encrypted files to verify that they can be opened.

Migrate the EFS Certificates

Migrating EFS certificates is a necessary part of moving user data from one computer to another. The method that you use to achieve this depends on the Windows operating system that you are using.

Migrating to Windows Vista

You can use the Microsoft User State Migration Tool (USMT) version 3.0 to automatically migrate EFS certificates from Windows XP–based computers to computers that run Windows Vista. However, by default USMT fails if the tool finds an encrypted file (unless you use the /efs option). Therefore, you must use the /efs:copyraw flag with the USMT tool to migrate the encrypted files. When you then run USMT on the destination computer, the encrypted file and the EFS certificate will automatically migrate. You can also use the manual methods described in the following section to move EFS data from Windows XP to Windows Vista.

Migrating to Windows XP

To migrate encrypted files to computers that run Windows XP, you must also migrate the EFS certificate. When migrating certificates using USMT, user input is required both before and after the migration.

You can migrate EFS certificates in either of the following ways:

Use the Cipher.exe tool.
Use the Certificates MMC snap-in.

Using the Cipher.exe Tool to Migrate EFS Certificates

You can use the command-line Cipher.exe tool to export the user's EFS certificate (as described in the "Recover from EFS Issues" section of this chapter), then import the resulting PFX file on the new computer.

To migrate a user's certificate with Cipher.exe

Log on as the user who owns the certificate.
Open a command prompt and type Cipher /x:<efsfile> <filename> where filename is a file name without extensions and efsfile is a path to an encrypted file. Then press ENTER.If <efsfile> is provided, the current user's certificate that is used to encrypt the file will be backed up. Otherwise, the user's current EFS certificate and keys will be backed up. Cipher.exe will create a password-protected .pfx file wherever you specify. For additional information about Cipher.exe, type cipher /?.

Note There are two important security concerns in this process. First, the PFX file must be stored in a location that will be accessible from the destination computer (for example, a shared folder or removable media). Second, the file should not be stored in the same place as the EFS-protected files.

After the file is exported, the user can import it on the new computer using the following To import the certificate on the new computer procedure.

Using the Certificates Snap-in to Migrate EFS Certificates

To export a user's certificate with the Certificates snap-in

Have the user who owns the certificate log on to the source computer.
Open the Microsoft Management Console (MMC). To do so, click Start, Run, type mmc, and then press ENTER.
On the File menu, click Add/Remove Snap-in.
In the Add/Remove Snap-in dialog box, click Add.
From the resulting list, select Certificates, click Add, and then select My user account.
Click Finish, click Close, and then click OK.
Browse to Certificates - Current user\Personal\Certificates.
Right-click the certificate that you want to migrate.
Click All Tasks, and then click Export.
The Certificate Export Wizard will help you store the certificate somewhere that is accessible from the destination computer—for example, a floppy disk or a shared folder. When prompted, indicate that you want to export the private key along with the certificate.After the process completes, a message will display that indicates the export was successful.

To import the certificate on the new computer

Have the user who owns the certificate log on to the new computer.
Open the MMC as described in the previous procedure.
On the File menu, click Add/Remove Snap-in.
In the Add/Remove Snap-in dialog box, click Add.
Select Certificates from the list, click Add, and then select My user account.
Click Finish, click Close, and then click OK.
Browse to Certificates - Current user\Personal.
Right-click Personal.
Click All Tasks, and then click Import.
Use the Certificate Import Wizard to locate the certificate that you exported. When browsing for the certificate, select Personal Information Exchange (*.pfx; *.p12) from the Files of type drop-down list box. You will need to enter the password you supplied when you exported the certificate from the destination computer.After the process completes, a message will display that indicates the import was successful.

Create DRA Certificates

As part of the migration, you might wish to use the instructions in Chapter 2: Configuration and Deployment Tasks to ensure that the new computer (and any associated certificates) has the correct set of DRA certificates associated with it.

Migrate the Encrypted Files to the New Computer

After the certificate is exported, you can proceed to move other user data, such as actual files, to the new computer.

If you use the USMT to move encrypted data from one computer to another, you must specify the /efs:copyraw flag to allow the USMT to read the entire stream of encrypted data from the source files. If you do not specify this flag, or if you use other tools (such as xcopy or robocopy) to move the files, they will be decrypted by the source computer before they are copied.

Test the Migrated Files

After you finish moving the certificates and files to the new computer, you should verify that the migration worked properly by testing two things:

Verify that the user account that owns the files can open them.
Verify that the files remain encrypted by checking their attributes in Windows Explorer. Icons of encrypted files will be tinted green; you can also use the File properties dialog to verify that the Encrypted attribute is enabled.

Update the DRA Certificates

You will need to update the DRA certificates in the following circumstances:

Your organization is migrating from local DRAs to a centrally managed DRA infrastructure.
You need to update a centrally managed DRA policy because the existing DRA certificates have expired (or will expire in the near future).
You need to update a centrally managed DRA policy because the existing DRA key material was lost, misplaced, or compromised.

DRA Certificate Update Considerations

To update the DRA certificates, you must first request or create one or more new DRA keypairs and certificates. Depending on your environment, you can accomplish this task in one of the following ways:

Use the /R switch with Cipher.exe.
Use the Web or programmatic interfaces offered by Microsoft Certificate Services.
Use the request mechanism of your existing third-party CA.

The request must use an appropriate DRA template so that the issued certificate will be usable as a DRA.

After you request and obtain the new DRA certificate(s), you must bind them to an appropriate Group Policy that applies to all computers whose DRA information you wish to update. Be sure that the Group Policy object you use correctly applies the new DRA certificates across multiple organizational units, Active Directory domains, and Active Directory forests. As a default, you might be able to use the Active Directory Default Domain Policy GPO as a basis for distributing the new DRA information.

After you assign the new DRA certificates to a GPO, you can delete the existing DRA certificates. However, if you do so you will lose the ability to recover files that were created with the existing DRA certificate. Before you delete any DRA certificates, ensure that you have a usable copy that will allow you to recover encrypted files.

DRA changes do not take effect on individual computers until those computers refresh their Group Policy settings. You can wait for the next security policy refresh (which occurs every 90 minutes by default), run the gpupdate /force command on affected computers, or reboot them.

You should also archive the DRA keypair and certificate(s) for increased security of the private key. After you do so, you should delete the keypair and certificate from the user certificate store of any user who has imported the certificate and keypair. When doing so, be sure to select the Delete the private key if the export is successful checkbox in the Export wizard.

After the DRA information is updated, you can proceed to update EFS-protected files on the target computers as described in the next section.

Update Files for New DRA or User Certificates

After you change or update the DRAs used in your organization, you must update any files that were protected by the previous DRA. You can do this manually by opening and saving each individual file, but this method is time-consuming and error-prone. You can also use the /U switch with the Cipher.exe command, which will traverse the local disk and update the DRA information for every encrypted file it finds.

As part of this process, you might wish to incorporate the following steps:

Capture the output of Cipher /U to an error log and store it on a centralized location (such as a network share).
Consider using the /I flag to force Cipher.exe to ignore errors. If you do not do so, when Cipher /U encounters locked or busy files it will not be able to update them and the update process will fail.
You might want to create a script to perform the update instead of running Cipher /U from the command line. Such a script could take a long time to complete, so it might not be appropriate to run it during the logon process. However, you can schedule it to run on user's computers or ask users to invoke it manually at a convenient time.

More Information

This accelerator is part of a larger series of tools and guidance from Solution Accelerators.