Using Group Policy to configure BitLocker
(Last updated on February 5, 2021)
Although Windows makes it possible to manually enable BitLocker encryption for a storage device, BitLocker can also be enabled and configured through the use of group policy settings. This is particularly useful for organizations who have a compliance mandate to enable BitLocker encryption for all endpoint devices.
You can access the BitLocker settings by opening the Group Policy editor and then navigating through the console tree to Computer Configuration \ Administrative Templates \ Windows Components \ BitLocker Drive Encryption. The BitLocker Drive Encryption folder contains ten configurable settings, as well as three subfolders, each of which contain additional settings. You can see the primary collection of settings in Figure 1.
These are the primary group settings for BitLocker.
Of the available settings, the one that is arguably the most important to configure is Store BitLocker Recovery Information in Active Directory Domain Services. Enabling this setting provides administrators with a way of recovering BitLocker encrypted data in the event that the user’s key information is lost.
Ideally, IT pros should also enable the Choose Default Folder for Recovery Policy setting. This policy setting allows administrators to provide a default location where users can save their recovery password. Recovery passwords should be saved to a network share, where they can be backed up.
The Choose How Users Can Recover BitLocker Protected Drives setting is optional. This setting allows administrators to provide a 48-digit recovery password and a 256-bit recovery key. These values can be used to unlock BitLocker in the event that a user’s key is lost. If an administrator opts not to provide this information, then recovery information must be saved to the Active Directory.
The next policy setting is Disable New DMA Devices When This Computer is Locked. Enabling this policy blocks direct memory access to Thunderbolt PCI ports. Enabling this policy setting can improve endpoint security, but the setting may not be compatible with older hardware.
Windows also allows you to choose the drive encryption method and cipher strength. When you enable this policy, you are given a choice between AES 128-bit encryption and AES 256-bit encryption. BitLocker uses 128-bit encryption by default.
The previously mentioned Choose Drive Encryption Method and Cipher Strength setting applies to Windows 8 and later operating systems. However, there is a separate setting for Windows 7, Windows Vista, and Windows Server 2008. This setting allows you to choose between 128-bit AES encryption, 256-bit AES encryption, and 128-bit and 256-bit AES encryption with Diffuser.
Similarly, Microsoft makes a separate policy setting available for Windows 10 version 1511 and higher. While Windows 10 can use the Windows 8 and higher policy setting, the Windows 10 1511 and higher policy setting provides some additional options. Rather than simply selecting an encryption method, administrators can specify encryption methods for operating system drives, fixed data drives, and removable data drives. Microsoft has also updated the encryption options. Administrators can choose between 128-bit or 256-bit AES-CBC, or between 128 bit or 256 bit XTS-AES.
Another policy setting that administrators can configure is the Provide the Unique Identifiers for Your Organization setting. When enabled, this setting lets you associate a unique organizational identifier with BitLocker encrypted drives.
The Prevent Memory Overwrite on Restart setting controls whether or not BitLocker secrets that are stored in memory will be overwritten when the computer is rebooted. Overwriting BitLocker secrets stored in memory will improve reboot performance, but may also weaken security in the process since the BitLocker keys remain in the system’s memory.
The last of the primary BitLocker related group policy settings is Validate Smart Card Certificate Usage Rule Compliance. When enabled, this policy lets you associate a smart card object identifier with a BitLocker protected drive, thereby making it possible to use a smart card to gain access to BitLocker protected storage.
As previously mentioned, the Group Policy Editor contains three sub-folders beneath the BitLocker Drive Encryption folder. These sub-folders are named Fixed Data Drives, Operating System Drives, and Removable Data Drives. These folders contain settings that allow administrators to customize BitLocker for use on fixed data drives, operating system drives, and removable data drives respectively.
The Fixed Data Drives and Removable Data Drives folders contain an identical collection of settings. You can use these settings, which are shown in Figure 2, to require the use of smart cards, prevent the writing of data to non-encrypted drives, configure hardware-based encryption, enforce a specific drive encryption type, allow access to drives that were protected by an earlier version of Windows, configure passwords, and choose the recovery methods that you want to allow.
There are additional settings for fixed and removable data drives.
In contrast, the Operating System Drive folder contains nearly two dozen settings, all related to the use of BitLocker on a boot drive. These settings can be configured to control the use of TPM platform validation, PINS and passwords, and Secure Boot, just to name a few. You can see these and the other available settings in Figure 3.
These are the BitLocker settings for operating system drives.
If you are going to use Group Policy to configure BitLocker, then it is important to understand the role of Platform Configuration Registers (PCRs). The Platform Configuration Registers instruct the system to perform a series of integrity checks just prior to booting the operating system. These checks help to ensure that the system has not been tampered with. If the integrity checks are successful, then the TPM chip releases the BitLocker keys and the system is allowed to boot.
Windows maintains the PCR related group policy settings in two separate locations. One location is used for BIOS based computers, while the other is used for UEFI based computers. The BIOS related PCR settings are located at: Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ BitLocker Drive Encryption \ Operating System Drives \ Configure TPM Platform Validation Profile for BIOS-Based Firmware. The UEFI related settings are stored at: Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ BitLocker Drive Encryption \ Operating System Drives \ Configure TPM Platform Validation Profile for Native UEFI Firmware Configurations.
There are over a dozen different PCRs that can be enabled through these group policy settings, each corresponding to specific integrity checks. The only PCR setting that is required is PCR 11, which enables BitLocker Access Control. In most cases however, additional PCRs are enabled. Although these PCRs help to protect the integrity of the system, they can also trigger a BitLocker lockout if low level system changes are made. As such, organizations should consider investing in a self-service key recovery tool such as Specops Key Recovery. That way, users will be able to recover their own BitLocker keys in the event of a lockout, without having to contact the help desk.