Chapter 2: Configuration and Deployment Tasks

Published: May 29, 2007

Before you begin deploying Microsoft® BitLocker™ Drive Encryption (BitLocker) and the Encrypting File System (EFS), you must complete a number of preliminary configuration tasks to prepare your environment. The tasks described in this chapter will help you prepare your Active Directory® directory service and your network, and will also help you deploy BitLocker and EFS on client computers.

Both EFS and BitLocker take advantage of Active Directory, which can be used to apply consistent configuration settings to multiple computers. The settings available for each technology are somewhat different. However, because both technologies can be controlled by Active Directory Group Policy objects (GPOs), you should consider how your Active Directory design can be leveraged to apply appropriate protection to your computers according to their location, what they are used for, or who uses them.

This chapter describes the following tasks:

• Choosing a BitLocker configuration to protect sensitive data.
• Using Active Directory Group Policy controls to control how BitLocker key backup, setup, disk encryption, and Trusted Platform Module (TPM) interaction work.
• Using Active Directory to control EFS encryption and certificate management.
• Preparing your client computers to use BitLocker in the selected configuration.
• Enabling BitLocker on client computers
• Configuring the Microsoft Encrypting File System Assistant (EFS Assistant) for use with EFS on your domain-joined computers.
• Importing Administrative Templates for customizing the administrative tools available for EFS.
• Configuring data recovery agents for EFS.

Infrastructure Preparation Tasks

Both BitLocker and EFS require some infrastructure preparation before you can deploy them in your environment. The tasks described in this section typically need to be performed once before the first deployment and do not usually need to be repeated.

Infrastructure Preparation for BitLocker

BitLocker infrastructure preparation requires two steps:

• Configuring BitLocker options through Active Directory Group Policy
• Preparing your Active Directory infrastructure to allow the storage of BitLocker recovery keys

Configure BitLocker Options with Group Policy

Windows Vista™ offers a number of BitLocker control settings that you can use to control the availability and behavior of BitLocker on your client computers. You control these settings by creating Active Directory GPOs using the standard Windows Server® GPO management toolset and the Windows Vista administrative templates. (For more information about these tools, see the Windows Server 2003 online help.)

Because GPOs can be applied to individual computers or to Active Directory sites, domains, and organizational units (OUs), you can be very flexible when deciding how to assign BitLocker settings to your organization's computers. You can:

• Assign settings to individual computers by modifying the Local Computer GPO.
• Group computers with similar functions into an OU, then assign unique BitLocker settings to only that OU. For example, you might create a separate OU for all mobile PCs, or perhaps only for mobile PCs that belong to employees in certain business units or job roles.
• Broadly apply BitLocker policies to all computers in a domain or forest. This approach provides straightforward implementation of company-wide encryption on Windows Vista–based computers. Computers that run other versions of Windows will ignore the BitLocker-specific settings.

Prepare for Active Directory Key Storage

To enable the storage of TPM owner passwords and BitLocker volume recovery data in Active Directory, you must complete the following steps. These steps require that all the domain controllers accessible to BitLocker clients are running Windows Server 2003 Service Pack 1 (SP1) or greater.

1. Extend the Active Directory schema.
2. Set permissions on the BitLocker and TPM recovery information schema objects.
3. Configure a GPO to enable Active Directory backup of BitLocker key information.
4. Configure a GPO to enable Active Directory backup of TPM owner password information.

Detailed procedures for these steps are described in the Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information guide.

After you complete the preceding steps you can delegate recovery access to other people in your organization.

To delegate recovery access

1. Create or identify an Active Directory security group that contains the user accounts to which you want to delegate access.
2. Add an access control entry (ACE) to the discretionary access control list (ACL) for the domain or organizational unit (OU) that holds the computers to which you want to delegate access. The ACE must grant the "control access" and "read property" permissions to the BitLocker recovery information object, the key package, and the computer object.
3. To enable recovery of the TPM information, you can use the same method to grant "control access" and "read property" to the TPM owner information object.

As part of this process, you might want to consider granting access to the TPM and BitLocker recovery information to two separate groups of users. This approach helps maintain separation of duties for access to recovery information.

Infrastructure Preparation for EFS

To effectively use EFS, you must complete the following infrastructure preparation tasks:

1. Prepare Active Directory and create Group Policy objects
2. Manage and configure data recovery agents
3. Manage and configure key recovery agents

Prepare Active Directory and Create Group Policy Objects

This section of the guide describes the necessary configuration tasks to prepare your Active Directory environment to support EFS. If you do not perform these tasks, individual client computers that run Windows XP or Windows Vista might still be able to use EFS, but you will not have the ability to centrally manage and control EFS functionality.

Control EFS Encryption Settings

Windows Vista and Windows XP offer a range of settings that you can use to control the availability and behavior of EFS on your client computers. You control these settings by creating Active Directory GPOs, using the standard Windows Server GPO management toolset. (For more information about these tools, see the Windows Server 2003 online help.)

Because GPOs can be applied to individual computers or to Active Directory sites, domains, and OUs, you can be very flexible when deciding how to assign EFS settings to your organization's computers. You can:

• Assign settings to individual computers by modifying the Local Computer GPO.
• Group computers with similar functions into an OU, then assign unique EFS settings to only that OU. For example, you might create a separate OU for all mobile PCs, or perhaps only for mobile PCs belonging to employees in certain business units or job roles.
• Broadly apply EFS policies to all computers in a domain or forest. This approach can be used in conjunction with the EFS Assistant to provide straightforward implementation of company-wide encryption on both Windows XP and Windows Vista–based computers.

EFS Settings Common to Windows Vista and Windows XP

The Active Directory GPO template allows you to control several EFS-related settings, which are listed and described in the following table. For more information, see the Windows XP and Windows Vista security guides.

Table 2.1. Active Directory GPO Template EFS-related Settings

Enabling and Disabling EFS

Because of the serious risk of losing keys (and therefore losing access to encrypted files) with stand-alone EFS, some organizations choose to disable EFS until they can implement an enterprise certification authority (CA) and domain-based EFS. You can disable or enable the use of EFS by changing the state of the Allow users to encrypt files using Encrypting File System (EFS) checkbox in the properties of the Encrypting File System object in a GPO. The Encrypting File System object is located at the following path: Computer Configuration\Windows Settings\Security Settings\Public Key Policies.

If your organization has previously disabled EFS through a GPO, you must now modify the GPO to enable EFS. If you disabled EFS through local policies or registry changes, you must now remove the local policies or use the registry editor to enable EFS. To enable EFS via the registry, look for a DWORD value named EfsConfiguration in the registry in the HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\EFS key. To disable EFS, change the value to 1. To enable it, change the value to 0. Note that this change only applies to the local computer, not other computers in the domain.

Supporting Additional Encryption Algorithms

If during the planning phase you determined that your deployment of EFS must be compliant with Federal Information Processing Standards (FIPS) 140-1, you should enable FIPS by changing the System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing option in Local or Group Policy in Active Directory. This option is located at the following path: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.

If another encryption algorithm needs to be used (for reasons other than compliance with FIPS) Group Policy should be used to modify HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS on the required client computers.

Windows Vista-Specific EFS Options

A number of new Group Policy options were added to Windows Vista to help administrators define and implement organizational policies for EFS. These options (shown in the following figure) include the ability to require smart cards for EFS, enforce page file encryption, stipulate minimum key lengths for EFS, and enforce encryption of the user’s Documents folder. To access these options, edit the Encrypting File System object in a GPO (this object is located at the following path: Computer Configuration\Windows Settings\Security Settings\Public Key Policies.)

Control Certificate Auto-enrollment

Windows XP Professional and Windows Vista enable users to be automatically enrolled for user-type certificates when they log on. Automatic enrollment of user certificates is quick and simple, and it enables public key infrastructure (PKI) applications (smart card logon, EFS, SSL, S/MIME, and others) within an Active Directory environment. User auto-enrollment minimizes the high cost of typical PKI deployments. To enable certificate auto-enrollment, you must create an appropriate certificate template in Active Directory. Use the Certificate Templates Microsoft Management Console (MMC) snap-in to add an appropriate certificate template. For more information, see the article "Certificate Autoenrollment in Windows XP."

Manage and Configure Data Recovery Agents

Microsoft recommends that your organization define at least one data recovery agent (DRA) for use with EFS. DRAs might be regular network administrator accounts, but Microsoft recommends that you use dedicated accounts that are only used for recovery activities. Your organization's policy or legal requirements might specify additional requirements, including auditing and separation of access. Meeting these requirements might entail defining separate DRAs for different groups, organizations, job functions, or other subdivisions of your organization's network.

DRA management includes the following tasks, which are described in detail in the following subsections:

• Create the DRA user accounts
• Create and populate security groups for DRAs
• Configure the CA to issue DRA certificates
• Request DRA certificates
• Approve EFS DRA certificate requests
• Define a data recovery policy (a planning step described in Chapter 1)
• Export certificate for assignment to a policy
• Define a data recovery agent

Creating DRA User Accounts

The best practice for DRA user account management is to create separate user accounts that are only used for data recovery, because this approach helps reduce the risk that a privileged user will improperly recover data. Dedicated DRA user accounts start as ordinary accounts to which you grant recovery privileges.

To create DRA user accounts

1. Open Active Directory Users and Computers.
2. In the console tree, right-click the folder in which you want to add a user account. (Active Directory Users and Computers/domain node/folder)
3. Select New, and then click User.
4. Name the account. Instead of using an individual user name, you should identify the account by role (for example, HR DRA or Engineering DRA).
5. In User logon name, type the user logon name, click the UPN suffix in the drop-down list, and then click Next.
6. In Password and Confirm password, type the user's password, and then select the appropriate password options.
7. Click OK.
8. Repeat steps 3-7 for each additional DRA that you want to create.

Creating Security Groups for DRAs

Microsoft recommends that you create an Active Directory security group for each group of DRAs you want to use. This approach allows you to effectively control which users have access to recover data from various parts of your organization.

To create security groups for DRAs

1. Open Active Directory Users and Computers.
2. Right-click Users, click New, click Group, type Domain Recovery Agents (or another appropriate name), and then click OK.
3. To add users to that group, right-click Domain Recovery Agents under the Users OU, click Properties, and then click the Members tab. Select the users you want to add to this group, then click OK.
4. Repeat steps 2 and 3 for each additional DRA group.

Configuring the CA to Issue DRA Certificates

You must configure your CA to issue certificates using a template that includes the key usage flags for EFS recovery. The following steps describe how to configure Microsoft Certificate Services to issue EFS DRA digital certificates. You can use other compatible CAs for issuing EFS DRA certificates, but instructions for third-party CA services are not provided in this guide.

To configure Certificate Services to issue EFS recovery certificates

1. Log on to Windows with a user account that is allowed to manage Certificate Services.
2. Open the Certification Authority console with a focus on an authorized Certificate Services server. To do so, click Start, point to All Programs, point to Administrative Tools, and then select Certification Authority.
3. Expand the Certification Authority server object to display its components.

4. Right-click the Certificate Templates node and select Manage to open the Certificates Template console as shown in the following figure.

   

   Figure 2.2. Certificate templates in the Certification Authority console

5. The digital certificate used to issue EFS recovery agent certificates does not allow its default key size of 1024 bits to be changed. A copy must be made of the built-in template, and the resulting copy of the EFS recovery agent certificate template must be appropriately configured.Right-click the EFS Recovery Agent certificate template and select Duplicate Template.
6. Assign the new certificate template a new name (for example, Updated EFS Recovery Agent) to differentiate it from the standard template.
7. Click the Request Handling tab, and configure the desired key length option to be 2048 bits or larger.
8. Click the Security tab and ensure that the user accounts you wish to make EFS recovery agents have the Read and Enroll permission.
9. Click OK.
10. Open the properties dialog box of the original EFS Recovery Agent certificate template, click the Security tab, and set Deny-Enroll permission for all users. Click OK.
11. Switch to the Certification Authority console, then right-click the Certificate Templates object, select New, and then Certificate Template to Issue.
12. Select the new, stronger EFS recovery agent certificate and click OK.
13. Close the Certification Authority console.
14. Have all existing EFS recovery agents request new digital certificates using the new, stronger EFS recovery agent certificate templates.
15. Approve and issue the new EFS recovery agent certificates.
16. Ensure that the new EFS recovery agent private key(s) (such files have .PFX extensions) are archived or backed up to two or more separate, secure locations, and then delete them from the local computer until needed for recovery.

Note All EFS DRA and KRA certificates must be issued from the newly configured certificate or they will have the originally set key length.

For organizations which may have previously deployed EFS and EFS recovery agents using the standard template, files already encrypted with the weaker EFS recovery agent need to be encrypted with the new, stronger EFS recovery agent certificate. This process will happen automatically, on a file-by-file basis, when individual files are modified.

You can instruct EFS to update all encrypted files on local drives all at once by opening a command prompt, typing Cipher.exe /U, and pressing ENTER.

After all encrypted files are re-encrypted with the new EFS recovery agent certificate, and after you have ensured that you have backup copies of the original, weaker EFS recovery agent key in two or more separate, secure locations, you can delete the original recovery key in the Certificate Templates object in the Certification Authority console.

Requesting DRA Certificates for an Individual User

In circumstances in which multiple recovery agents are needed for the domain, or in which the recovery agent needs to be different from the domain administrator for legal reasons or because of organizational policy, you might need to identify certain users as recovery agents. These users must be issued file recovery certificates.

Issuing these certificates requires the following:

• An enterprise CA must be available.
• The policy on the enterprise CA must allow the designated user/agents to request and obtain a file recovery certificate.
• Each user must request a file recovery certificate.

This process can be automated by enabling certificate auto-enrollment, or it can be performed manually by completing the steps in the following procedure:

To create an EFS recovery agent certificate

1. Click Start, Run, type mmc, and then click OK.
2. On the File menu, select Add/Remove Snap-in, and then click Add.
3. Double-click Certificates, select My user account, and then click Finish. Click Close, and then click OK.
4. Click the plus sign (+) next to Certificates - Current User to expand the folder.
5. Right-click Personal in the left pane, click All Tasks, and then click Request New Certificate to start the Certificate Request wizard.
6. The first page of the wizard is informational. Click Next to continue.
7. A list of certificate templates is displayed. Select EFS Recovery Agent and then click Next.
8. Type a friendly name to distinguish this certificate from others, and add a description if you wish. Click Next, and then click Finish to request the certificate.
9. Click OK to acknowledge the successful certificate request.

To create a domain-wide EFS Recovery Policy, the EFS Recovery Agent certificate created previously needs to be exported in a .CER format.

Approving EFS DRA Certificate Requests

Typically, EFS DRA certificate requests must be manually approved in Certificate Services.

To review and approve DRA requests sent to a Microsoft Certificate Services server

1. Log on to Windows with a user account that is allowed to approve digital certificate requests in Certificate Services.
2. Open the Certification Authority console with a focus on an authorized Certificate Services server. To do so, click Start, point to All Programs, point to Administrative Tools, and then select Certification Authority.
3. Expand the Certification Authority server to display its components.
4. Click Pending Requests. The right pane will display a list of pending certificate requests awaiting approval.
5. Find the appropriate pending EFS recovery agent certificate requests, right-click them, and select Issue. Close the Certification Authority console when finished.

Note If you use a certificate template that requires manager approval, and you manually request a certificate using that template, the request might fail. If so, you must edit the template to remove the manager approval requirement or create a new request using a different template.

Exporting Certificates for Assignment to a Policy

After you assign a DRA certificate to an individual user, you need to export that certificate so that it can be attached to a Group Policy object for assignment as a recovery policy.

To export a certificate for assignment to a GPO

1. In the Certificates console, expand the Personal folder.
2. In the right pane, right-click the certificate you just created, click All Tasks, and then click Export. Click Next to begin the export process.
3. Select the No, do not export the private key check box, and then click Next.
4. Leave the default .cer file format, and then click Next.
5. Provide a file path and name, and then click Next.
6. To perform the export, click Finish, and then click OK.
7. Close the Certificates console.

Defining a Data Recovery Agent

You define DRAs by modifying the Public Key Policies object within a Group Policy object, adding a DRA, and linking the DRA's certificate to the DRA. To do so, you need the DRA's certificate in .CER format.

To define a DRA

1. Click Start, Run, type mmc, and then click OK.
2. On the File menu, click Add/Remove Snap-In.
3. Click Add, scroll down, and then double-click Group Policy.
4. Select the Group Policy object that you are using to apply the DRA policy to affected computers, and then click OK.
5. Click the plus sign (+) next to the target GPO to expand the tree. Expand Computer Configuration, Windows Settings, Security Settings, and Public Key Policies. Click Encrypting File System.
6. Right-click Encrypting File System, and then click Add Data Recovery Agent.
7. On the Add Recovery Agent wizard screen, click Next, click Browse Folders, and then navigate to the Adminstrator's Documents and Settings folder. Double-click the DRA.CER file, then click Next, and then click Finish.

Manage and Configure Key Recovery Agents

The next implementation task that is required for EFS deployment is to set up your key recovery agent (KRA) accounts and infrastructure.

Configuring Certificate Services for Key Archival

If you use the Windows Server 2003 Certificate Services solution, you can configure your CA to provide automatic key archival. Only Windows Server 2003 and later server editions allow automated key archival. To configure automated key archival, you need to complete the following tasks, which are described in detail in the following subsections:

• Enable key recovery agent certificates
• Request and issue key recovery agent certificates
• Approve certificate requests
• Configure key recovery agents in Certificate Services
• Configure the digital certificate template to include an archiving capability flag so that newly issued certificates can be archived

Enabling Key Recovery Agent Certificates

To make key recovery agent certificate requests possible, you must first enable them in Certificate Services.

To make KRA certificate requests possible

1. Choose one or more user accounts to become key recovery agents.
2. Log on to Windows with a user account that is allowed to manage Certificate Services.
3. Open the Certification Authority console (Start, All Programs, Administrative Tools, Certification Authority) and attach to an authorized Certificate Services server.
4. Expand the Certification Authority node, then right-click the Certificate Templates object and select Manage to open the Certificates Template console.
5. Right-click the Key Recovery Agent certificate template and select Properties.
6. Click the Security tab and ensure that the user accounts you wish to designate as KRAs (those chosen in step 1) have the Read and Enroll permissions.

7. Under the Request Handling tab, ensure that Minimum Key Size is set to 2048 bits or larger.

   Note Microsoft now recommends that all DRA and KRA recovery keys be 2048 bits or larger.

8. Click OK.
9. If 1024-bit or shorter keys were already generated and used, new longer keys must be generated to replace the weaker keys. Right-click the Key Recovery Agent certificate template and select the Reenroll All Certificate Holders option.
10. Switch to the Certification Authority console, right-click the Certificate Templates object, select New, and then select Certificate Template to Issue.
11. Select Key recovery agent certificate and click OK.
12. Close the Certificate Templates and Certification Authority consoles.

Requesting and Issuing Key Recovery Agent Certificates

After you enable specified accounts for use as KRAs, you must issue KRA-enabled certificates to those users.

Note Key recovery agent certificates can be requested many ways, including through the Certificates console, Web enrollment (if enabled), or using manual certificate request files. This guide describes the Certificates console method.

To issue KRA-enabled certificates

1. Log on to Windows using the KRA user account logon and password.
2. Click Start, Run, type MMC.EXE and press ENTER. Click Continue if prompted by User Account Control.
3. Click the File menu option, and then select Add/Remove Snap-in.
4. Select the Certificates snap-in and then click Add.
5. When prompted, choose My user account, then click Finish, and then click OK.
6. Expand the Certificates-Current User object, and then click the Personal object.
7. Right-click Personal, select All Tasks, and then Request New Certificate.
8. Click Next on the Certificate Request wizard screen.
9. Select Key Recovery Agent in the Certificates Type dialog box, and then click Next.
10. Type a friendly name (for example, My Key Recovery Agent Certificate) and description, click Next, and then click Finish.
11. Close the Certificates console when no longer needed.
12. Log out of Windows.

Repeat steps 1-12 for all users who are authorized to receive a key recovery agent certificate.

Approving Certificate Requests

Typically, KRA certificates must be manually approved in Certificate Services.

To approve KRA certificate requests

1. Log on to Windows with a user account that is allowed to approve digital certificate requests in Certificate Services.
2. Open the Certification Authority console and attach to an authorized Certificate Services server.
3. Expand the Certification Authority node, then click Pending Requests. The right pane will display pending certificate requests that are awaiting approval.
4. Select the KRA certificate requests that you want to approve.
5. Right-click each KRA request, and then select Issue.
6. Close the Certification Authority console.

Configuring Key Recovery Agents in Certificate Services

Each key recovery agent must be added to Certificate Services.

To add KRAs to Certificate Services

1. Log on to Windows with a user account that is allowed to manage Certificate Services.
2. Open the Certification Authority console and attach to an authorized Certificate Services server.
3. Right-click the server object and select Properties.

4. Click the Recovery Agents tab (shown in the following screen shot).

   

   Figure 2.3. The Recovery Agents tab for a server object in the Certification Authority console

5. In the Number of recovery agents to use box, type the number of key recovery agents that will be used to encrypt the archived key. This value must be at least 1. However, if this value exceeds the number of recovery agent certificates with "Valid" status, new enrollment requests that require key archival will fail.
6. Click Add and add one or more of the KRAs you previously approved. Then click OK.
7. Select Yes when prompted to stop and restart Certificate Services. New key recovery agents will not be loaded until Certificate Services is stopped and started.
8. Close the Certification Authority console when no longer needed.

Creating New EFS Certificate Template to Allow Key Archival

The digital certificate that is used to issue EFS digital certificates to users must be configured to automatically archive keys. This option cannot be enabled on the built-in Basic EFS certificate template. You must copy the built-in template, then enable the EFS certificate template copy to automate key archival

To configure a digital certificate to automatically archive keys

1. Log on to Windows with a user account that is allowed to manage Certificate Services.
2. Open the Certification Authority console and attach to an authorized Certificate Services server.
3. Expand the Certification Authority node, then right-click the CertificateTemplates node and select Manage to open the Certificates Template console.
4. Right-click the Basic EFS certificate template and select Duplicate Template.
5. Assign the new certificate template a new name (for example, Updated Basic EFS) to differentiate it from the standard template.

6. Click the Request Handling tab, and select the Archive subject’s encryption private key check box as shown in the following screen shot.

   

   Figure 2.4. Properties of New Template dialog in the Certification Authority console

7. Set the desired key length (for example, 2048 bits).
8. Click the Security tab and ensure that the user accounts you wish to participate in EFS have the Read and Enroll permissions.
9. Set other certificate template options as desired, such as auto-enroll, useful life, and so on.

10. On the original Basic EFS certificate template, click the Security tab and create a new access control entry that assigns the Deny action to the Enroll permission right.

    Note All issued EFS certificates must be issued from the newly configured certificate or else the keys will not be automatically archived.

11. Click OK and exit the Certification Authority console.

Creating and Using an Offline Recovery Agent

Microsoft strongly recommends that KRAs and DRAs be configured for offline use, and only enabled when needed for recovery scenarios. There are four general steps required to create an offline recovery agent:

1. Create a new user account to be used only for recovery events.
2. Request, generate, and assign a DRA or KRA digital certificate to the new account.
3. Export the certificate and private key, remove them from the network, and store them securely.
4. Disable the recovery user account so that it cannot be used until needed.

Steps 1 and 2 are discussed elsewhere in this guide, and step 4 is a standard Windows account maintenance task. Step 3, however, requires some additional explanation.

Export and Remove Recovery Certificate

To export and remove a recovery certificate for offline use, complete the following steps.

To export and remove a recovery certificate

1. Log on to Windows using the recovery user account for which you want to export keys.
2. Click Start, Run, type MMC.EXE, and then press ENTER. If prompted by User Account Control, click Continue.
3. On the File menu, click Add/Remove Snap-in.
4. Select the Certificates snap-in and then click the Add button.
5. When prompted, select the My user accountradio button, click the Finish button, and then click OK.
6. Expand the Certificates-Current User object, expand Personal, and then click Certificates.
7. Locate the correct recovery digital certificate. If you are unsure which certificate to use, look for digital certificates with File Recovery or Key Recovery in the Intended Purposes field.
8. Right-click the recovery digital certificate, click All Tasks, and then click Export to start the Certificate Export wizard.
9. Click the Next button.
10. Select the Yes, export the private key check box, and then click Next.

11. Select the Delete private key if export is successful check box, and then click Next.

    

    Figure 2.5. Export File Format prompt in Certificate Export Wizard

12. Type a protective password twice and then click Next.
13. Click Browse and then choose the location to which you want to store the exported recovery certificate.
14. Type a file name for the backed up recovery keys and certificate. Leave the file extension as .PFX to make re-importing the key easier.
15. Click Save, click Next, click Finish, and then click OK.
16. Copy the resulting backup file to another location and delete it from the current location if not needed. Make sure to empty the Recycle Bin after you delete EFS digital certificates or files.
17. Store the backed-up recovery digital certificate and keys in two or more separate, secure locations.

Note When the recovery certificate private key is exported, the recovery public key (which is used to encrypt the FEK) should be left on the computer. If you delete it, you could not enable the recovery agent to encrypt or recover EFS-protected files or keys.

Per-Computer Configuration Tasks

In addition to the infrastructure configuration tasks described earlier, you will need to perform configuration tasks on individual computers.

Per-Computer Configuration Tasks for BitLocker

To configure BitLocker on a computer, you must:

• Ensure that the computer is capable of running BitLocker
• Enable and initialize the TPM if one is present
• Enable BitLocker

Update BIOS for TPM Support

In the planning phase, you determined which computers would be used with BitLocker, and which of those computers include TPM v1.2 (or later) hardware and a compatible BIOS. The first step in the per-computer configuration tasks for BitLocker is to update the BIOS on computers that need it.

The specific steps required to update the BIOS of an individual computer varies between manufacturers. BIOS firmware updates are often shipped on media that accompanies new computers, and are usually available on the OEM or motherboard vendor’s Web site. Generally, for mobile computers, you will need to create a bootable CD or USB disk with the manufacturer-provided BIOS image, and then use it to boot the computer while it is plugged in to an electrical outlet. This process necessarily requires physical access to each computer to be updated. Follow the vendor’s instructions for updating the BIOS firmware and reboot the computer after you apply the update.

Note It is important that all participating computers have the latest BIOS firmware updates for many other reasons, including software updates and performance enhancements. Before you enable TPM or BitLocker in Windows Vista, make sure the latest firmware version is installed.

Confirm Stable Boot Path

BitLocker and TPM ensure the integrity of the boot path from the computer startup through the Windows Vista boot process by performing a set of checks that are collectively known as a TPM Platform Validation Profile (PVP). If the boot process is significantly changed after BitLocker is installed, the PVP results will be different, and an integrity change could be noted. If an integrity change occurs, BitLocker could refuse to unlock the operating system volume without using an additional recovery method.

For this reason, ensure that the hardware and software boot pathway is fully configured and stable before you enable BitLocker. Specifically, each computer on which you are going to enable BitLocker should have:

• A BIOS configuration that reflects the correct boot device
• All optional devices employing ROM firmware installed
• Wake-on-LAN events configured
• Windows Boot Configuration Data (BCD) configured

You can use Local Computer policy and Active Directory Group Policy to configure which boot components (called Platform Configuration Registers or PCRs) are considered by TPM during the startup process. For most applications, the default set of PCRs provide good security, and Microsoft does not recommend changing them.

After BitLocker is installed, changing any component that has a corresponding PCR will cause BitLocker to request a recovery password. Examples of PCR changes include updating the BIOS, adding an additional ROM-enabled boot device, modifying the Master Boot Record (MBR), partition table, low-level boot sector data, boot configuration data, or boot manager, or installing another operating system in a new dual-boot scenario.

Note The Windows Vista master boot record (MBR), boot sector code, and boot manager provide critical integrity protection for BitLocker. Microsoft strongly recommends that you not use third-party boot loaders. Adding a new boot loader after BitLocker is enabled will trigger recovery; switching boot loaders before BitLocker is enabled will prevent BitLocker from maintaining a secure boot environment.

Enable TPM

If you plan to deploy BitLocker with the TPM, you must enable the TPM on each client computer. Computers that are certified as Windows Vista compatible should contain a BIOS version that allows BitLocker to enable the TPM as part of the BitLocker setup process. Otherwise, enabling the TPM typically requires you to use the computer’s BIOS setup and configuration program, which is usually invoked by pressing a specific key combination during the computer’s hardware boot process. The TPM option is often located under Advanced Options or Peripheral Configuration within the configuration screens, but there is no standard location. If the option is disabled, select Enable, save the new BIOS settings and exit, and then reboot if needed. After the reboot, most TPM-equipped computers will display a screen like the one shown in the following screen shot that prompts you to confirm that you want to enable the TPM.

Initialize TPM with Windows Vista

If a TPM will be used with BitLocker, the TPM chip needs to be initialized by allowing Windows Vista to take ownership of the TPM. TPM ownership information can be viewed through the TPM MMC snap-in (tpm.msc).

The TPM needs to be initialized once for each computer. BitLocker needs to be enabled once per operating system (if the computer is configured to boot to multiple operating systems). In other words, if you have a single computer that has multiple boot installations of Windows Vista, you will need to enable BitLocker for each Windows Vista installation.

In typical conditions, the BitLocker setup wizard will automate the process of initializing the TPM. However, you can also manually initialize the TPM if necessary.

To initialize the TPM from within Windows Vista

1. Ensure that the TPM chip has been enabled in the BIOS.
2. Make sure the appropriate storage or printer device is available for the TPM management password.
3. Log on to Windows Vista using an account that has local Administrator privileges on the computer.
4. Start the MMC Trusted Platform Module snap-in. To do so, type TPM.MSC in the Search box and then press ENTER.
5. If prompted by User Account Control, click Continue and a TPM console will display.
6. If Windows Vista does not recognize the TPM chip, you will need to troubleshoot the problem, enable it successfully, and then restart this procedure.
7. In the Actions pane, click the Initialize TPM option.
8. In the Create the TPM owner password dialog box, you will be prompted to create a TPM owner password. This password is needed only for TPM management tasks outside the BitLocker realm.You can let the wizard automatically create the password (the recommended action) or manually create the password. If you choose to create the password manually, you will need to create one that is at least 8 characters long. You can change the TPM owner password at any time after you set it (although you need to know the current password to change it).
9. You can save the password on removable media or to any other valid storage location, including a USB flash memory device, file location, desktop, or network location. If you prefer, you can print the password on an attached local or network printer. If you store the TPM password, Windows Vista saves it as a XML-formatted file ending with a .TPM file extension. By default, the file is named with the computer’s name. You should save or print the TPM owner password to two or more secure, separate locations.
10. After the password is entered and saved or printed, the TPM will begin to initialize. Windows Vista displays a progress dialog indicating the TPM initialization status.
11. After the initialization is complete, Windows Vista displays a completion dialog. Click Close to end the initialization process.

You can also initialize and take ownership of the TPM from within Windows Vista by using the manage-bde.wsf script as follows at a command prompt:

cscript manage-bde.wsf -tpm -takeownership -<password>

Executing this command will take ownership of the TPM and set the TPM owner password to the specified value.

Optionally, you can write a script of your own that uses the provided WMI interfaces to control the TPM.

Enable BitLocker

BitLocker can be enabled in two ways: manually using the steps in the following procedure or by using the Windows Deployment Wizard. For more information about using the Windows Deployment Wizard to enable BitLocker, see Running the Windows Deployment Wizard in the "Lite Touch Installation Guide" section of the Business Desktop Deployment toolkit.

Note Group Policy settings might be used to control which BitLocker features end users can configure, so the interface in the following screen shots might vary.

To enable BitLocker manually

1. Open Control Panel and then double-click Security.

2. Double-click BitLocker Drive Encryption. If prompted by User Access Control, click Continue.

   

   Figure 2.7. BitLocker Drive Encryption screen within Control Panel

3. Click the Turn on BitLocker option.

4. As the following figure shows, you might be prompted to choose a location to save or print the BitLocker recovery password. If you choose to save the BitLocker recovery password, the 48-character BitLocker recovery password will be saved in a text file named with the BitLocker Password ID. If you save the recovery password to a USB flash memory drive, a 256-bit recovery key will be stored as well as a hidden file (with a .BEK extension). You can choose any file storage location or USB flash memory drive, or you can print the recovery password. The following screen shot shows the recovery password being stored to a folder on a USB flash memory drive.

   

   Figure 2.8. BitLocker recovery password options

5. You should save the recovery password to one or more separate, secure locations. If you lose this BitLocker recovery key, you could lose access to your data. You cannot continue to enable BitLocker until you successfully save the BitLocker recovery password.

   Note The recovery password is written in plaintext in the text file, so it must be protected from unauthorized access.

   After you save the BitLocker recovery password one or more times, click the Next button.

6. In the Encrypt the Volume dialog box, select the Run BitLocker system check option to verify that the boot path is trusted and that the BitLocker protector can be located before beginning the encryption. This step is optional, but strongly recommended. If there is a failure, Windows Vista displays a warning and BitLocker encryption does not automatically occur.
7. Click the Continue button. If you choose not to perform a system check, you can click Encrypt to begin the volume encryption.
8. If you choose the system check, you will be prompted to ensure that the USB flash memory media is inserted (if that is where you choose to store the BitLocker recovery password) and then to restart the computer.
9. During the restart, Windows Vista searches for and verifies the BitLocker recovery password stored on the USB key and displays a message in a pre-boot text dialog box that indicates success.

10. When Windows Vista restarts, BitLocker begins encrypting the boot volume and displays a progress message that indicates the percentage complete, as shown in the following screen shot.

    

    Figure 2.9. BitLocker encryption progress message

The first active encryption of the operating system volume will result in a slightly noticeable performance delay. Users can continue to work on the computer while the encryption occurs.

Validate BitLocker Configuration and Installation

When BitLocker is finished encrypting the operating system volume, you can confirm its status using the Disk Management console, which is shown in the following screen shot. The encrypted volume will include the words BitLocker Encrypted.

If you use Active Directory for recovery key storage, you should verify that the recovery information is correctly stored in Active Directory. To do so, you can obtain the BitLocker Recovery Password Viewer (available from 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"), install it, and use it to verify that recovery information is available for one or more test computers. The BitLocker Recovery Password Viewer also simplifies the process of allowing authorized help desk or support personnel to retrieve recovery information when necessary. (For more information about policy issues with regard to password recovery, see the Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information guide.

Per-Computer Configuration Tasks for EFS

EFS requires a relatively small number of per-computer configuration tasks. If you are deploying EFS for the first time, the only task you must complete is encrypting the files or folders you want to protect on the target computer.

Encrypt Files and Folders

After EFS is enabled on the target computers, the organization's users can begin encrypting files and folders on their computers. The EFS Assistant that ships with this toolkit can be used to create encryption policies or users can be instructed about how to use one of the two interfaces provided with Windows to enable EFS encryption.

Using Windows Explorer

To change the encryption status of a file or folder using Windows Explorer

1. Right-click the file or folder and then click Properties.
2. On the General tab, click the Advanced button and then select the Encrypt contents to secure data check box
3. Click OK twice to ensure the encryption of the file.

When you encrypt an individual file in a folder for the first time, Windows prompts you to see if you want to encrypt just the file or the entire parent folder—thereby enabling EFS for the entire folder and all its child files and folders.

Using Cipher.exe

The command-line tool Cipher.exe can also be used to encrypt files and folders. To do so, at a command prompt change to the directory that contains the files or folders you want to encrypt. To encrypt the entire directory and all files and folders it contains, type Cipher.exe /e and then press ENTER. Alternatively, you can specify a list of files or folders that you want encrypted by including the names after the /e switch.

Encrypting Shared Files

To add users to a shared file

1. Right-click the file or folder and then click Properties.
2. On the General tab, click the Advanced button, and then click the Details button.Windows will display the other available users with EFS digital certificates.
3. Choose one or more additional users and then click OK.
4. When finished, click OK twice to return to Windows Explorer.

Note In Windows Vista, you can also use the Cipher.exe command with the /adduser parameter to add additional users to EFS-protected files.

Checking the Encryption Status of a File or Folder

If you are unsure whether a particular file or folder is encrypted, you can use multiple methods to determine its status. Two of these methods are noting visual clues in Windows Explorer and using Cipher.exe.

Windows Explorer

In Windows Explorer, EFS-encrypted files and folders are highlighted with a green font (shown in the following screen shot) or display an E in file attributes.

The green highlighting is a characteristic that is turned on by default in Windows XP Professional and later versions of Windows. To turn this feature on or off in Windows XP, click Folder Options and then select or clear the Show encrypted or compressed NTFS files in color attribute check box.

To access this setting in Windows Vista, open Windows Explorer, and on the Organize menu click Folder and Search Options, click the View tab, and select or clear the Show encrypted or compressed NTFS files in color check box.

To access this setting in Windows XP Professional, open Windows Explorer, and on the Tools menu click Folder Options. Then click the View tab.

File or folder attributes might not be readily visible in Windows Explorer in some versions of Windows. Ensure that you are using the Details view to view files. If file or folder attributes are still not visible, you must add them to the Details view. To do so, right-click any column heading in the Details view, click More, and then select Attributes.

Cipher.exe

You can also use the command-line utility Cipher.exe to view, encrypt, and decrypt EFS-protected files (among other options). To check the EFS status of any file, open a command prompt in Windows, change to the file or folder location, type Cipher.exe without any command line parameters, and then press ENTER. The Cipher utility will display a U next to any unencrypted file or folder and an E by an encrypted file or folder.

More Information

• Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information
• Certificate Autoenrollment in Windows XP
• Running the Windows Deployment Wizard
• How to use the BitLocker Recovery Password Viewer for Active Directory Users and Computers tool to view recovery passwords for Windows Vista