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:
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:
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:
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.
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
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:
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:
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.)
Figure 2.1. Windows Vista Encrypting File System Properties options
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:
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
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
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
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:
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
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
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
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
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:
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
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
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
Configuring Key Recovery Agents in Certificate Services
Each key recovery agent must be added to Certificate Services.
To add KRAs to Certificate Services
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
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:
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
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:
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:
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.
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.
Figure 2.6. Example TPM confirmation dialog
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
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.
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
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.
Figure 2.10. Disk Management console
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
Figure 2.11. Advanced Attributes dialog in Windows Explorer
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.
Figure 2.12. Encryption Warning dialog in Windows Explorer
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
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.
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.
Figure 2.13. EFS-encrypted files in Windows Explorer
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.
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.