In this article, I’ll discuss the changes coming to BitLocker Group Policy (Microsoft’s drive encryption software) in Windows 8.

Along with many other Windows features, Microsoft’s drive encryption, BitLocker, also has some changes and new features coming in Windows 8. Along with those changes and new features come changes to Group Policy.

Before we delve into the changes, be aware that you’ll need the latest Group Policy Management Console (GPMC) that is included with the Remote Server Administration Tools (RSAT) for Windows 8 or Windows Server 2012. You will not be able to manage these settings with older versions of the GPMC. All of the settings I’ll discuss can be found in Computer Configuration > Policies > Administrative Templates > Windows Components > BitLocker Drive Encryption.

Drive Encryption and Cipher Strength ^

When you get to the main BitLocker Drive Encryption, the only change is to the “Choose drive encryption method and cipher strength” option. A new policy has been added to cover pre-Windows 8/2012 computers along with a second policy for the latest OS. In the latest OS release, Microsoft has deprecated the Diffuser functionality in this version of BitLocker. In previous versions of BitLocker, the default setting is 128-bit with Diffuser. In the latest versions, the default is 128-bit. Unfortunately, I haven’t been able find documentation as to why this functionality has been removed.

Choose drive encryption method and cipher strength

Choose drive encryption method and cipher strength

Drive Encryption Type ^

One of my favorite new features of BitLocker is the ability to determine whether you want to encrypt the entire drive or just the portions of the drive that currently contain data. For setting up new computers, it will be a huge time saver since those unused portions of the disk shouldn’t contain data. However, existing computers will most likely still need to be fully encrypted to ensure that unused portions of the disk that may still contain deleted data are also secured.

The policy for this feature is the “Enforce drive encryption on fixed data drives” policy and is included for operating system drives, fixed data drives, and removable drives. When you enable this policy, you can also choose from the following encryption options: Default (allow the user to choose), full encryption, or used space only encryption. In most cases, “Full Encryption” is probably going to be the best choice to ensure encrypted data is always protected. If you have a staging OU for new computers, you’ll definitely want to set this to “Used Space Only encryption” to speed up the process.

Enforce drive encryption type on operating system drives

Enforce drive encryption type on operating system drives

Hardware Based Encryption ^

The next addition is “Configure use of hardware-based encryption.” This policy is also available for operating system drives, fixed data drives, and removable drives. In plain English, this means that BitLocker can now take advantage of hard drives that have built-in hardware-based encryption. Finally, right? In the event the computer does not have a Windows logo hard drive that is capable of BitLocker-compatible hardware-based encryption, it will fall back to software-based encryption. With this option, BitLocker will manage the encryption keys used by the hard drive while the drive itself performs the encryption function. This new feature is being touted as a way to improve system performance, but I’ve personally never seen a noticeable performance hit on computers encrypted with BitLocker.

Configure use of hardware-based encryption for operating system drives

Configure use of hardware-based encryption for operating system drives

Operating System Drives ^

If you’re using PIN numbers for your operating system drives, your users are probably going to beg you to implement Network Unlock. The “Allow network unlock at startup” allows you boot BitLocker encrypted computers with a TPM and startup PIN directly into Windows bypassing the PIN. Of course, you’ll also need additional infrastructure to make this work.

Allow network unlock at startup

Allow network unlock at startup

Another feature your users will like (and I’m sure you’ll like too) is the ability for non-Administrators to change the PIN or password associated with an OS drive. In the event this is something your organization needs to control, the “Disallow standard users from changing the PIN or password” policy will let you do that.

Disallow standard users from changing the pin or password

Disallow standard users from changing the pin or password

For whatever reason, Microsoft did not include an onscreen keyboard for the BitLocker PIN/password pre-boot screen in Windows 8. The “enable use of BitLocker authentication requiring preboot keyboard imput on slates” allows you to enforce pre-boot PINs/passwords even if those devices do not have keyboards. But, obviously, they’ll need keyboards to be able to enter a PIN.

Enable use of BitLocker authentication requiring preboot keyboard input on slates

Enable use of BitLocker authentication requiring preboot keyboard input on slates

“Allow Secure Boot for integrity validation” allows you to configure the use of Secure Boot on computers that have UEFI firmware. More specifically, it lets you disable it since the default is to use Secure Boot when it is available on a computer. In the event you do disable it, you can configure the “use enhanced Boot Configuration Data validation profile” to choose specific BCD settings to verify.

Allow Secure Boot for integrity validation

Allow Secure Boot for integrity validation

The “Configure TPM platform validation profile” policy has now been split into three separate policies: one for pre-Windows 8/2012 operating systems, one for BIOS-based firmwares, and one for UEFI-based firmwares. This policy allows you to specifically control which components are validated by the TPM before booting into Windows. In most situations, you probably won’t need to change these settings unless there is something in your environment that necessitates changing it.

Configure TPM platform validation for native UEFI firmware configurations

Configure TPM platform validation for native UEFI firmware configurations

Last, but certainly not least is “Reset platform validation data after BitLocker recovery.” This is another one of those, “Finally!” features in my book. This setting is enabled by default, so you probably won’t need to actually change it.

Reset platform validation data after BitLocker recovery

Reset platform validation data after BitLocker recovery

0 Comments

Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2021

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account