Chapter 3: Operations and Recovery Scenarios
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:
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:
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.
There are three different ways to unlock a BitLocker-encrypted disk:
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:
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.
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.
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
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:
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:
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:
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
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
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 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
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
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:
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
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:
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
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
To import the certificate on the new computer
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:
Update the DRA Certificates
You will need to update the DRA certificates in the following circumstances:
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:
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: