Category: At least Windows Server 2012, Windows 8 or Windows RT

This policy setting allows you to manage BitLocker’s use of hardware-based encryption on operating system drives and specify which encryption algorithms it can use with hardware-based encryption. Using hardware-based encryption can improve performance of drive operations that involve frequent reading or writing of data to the drive. If you enable this policy setting you can specify additional options that control whether BitLocker software-based encryption is used instead of hardware-based encryption on computers that do not support hardware-based encryption and whether you want to restrict the encryption algorithms and cipher suites used with hardware-based encryption. If you disable this policy setting BitLocker cannot use hardware-based encryption with operating system drives and BitLocker software-based encryption will be used by default when the drive is encrypted. If you do not configure this policy setting BitLocker will use hardware-based encryption with the encryption algorithm set for the drive. If hardware-based encryption is not available BitLocker software-based encryption will be used instead. Note: The “Choose drive encryption method and cipher strength” policy setting does not apply to hardware-based encryption. The encryption algorithm used by hardware-based encryption is set when the drive is partitioned. By default BitLocker uses the algorithm configured on the drive to encrypt the drive. The “Restrict encryption algorithms and cipher suites allowed for hardware-based encryption” option enables you to restrict the encryption algorithms that BitLocker can use with hardware encryption. If the algorithm set for the drive is not available BitLocker will disable the use of hardware-based encryption. Encryption algorithms are specified by object identifiers (OID). For example:- AES 128 in CBC mode OID: 2. 16. 840. 1. 101. 3. 4. 1. 2- AES 256 in CBC mode OID: 2. 16. 840. 1. 101. 3. 4. 1. 42

This policy setting allows you to configure whether Secure Boot will be allowed as the platform integrity provider for BitLocker operating system drives. Secure Boot ensures that the PC’s pre-boot environment only loads firmware that is digitally signed by authorized software publishers. Secure Boot also provides more flexibility for managing pre-boot configuration than legacy BitLocker integrity checks. If you enable or do not configure this policy setting BitLocker will use Secure Boot for platform integrity if the platform is capable of Secure Boot-based integrity validation. If you disable this policy setting BitLocker will use legacy platform integrity validation even on systems capable of Secure Boot-based integrity validation. When this policy is enabled and the hardware is capable of using Secure Boot for BitLocker scenarios the “Use enhanced Boot Configuration Data validation profile” group policy setting is ignored and Secure Boot verifies BCD settings according to the Secure Boot policy setting which is configured separately from BitLocker. Note: If the group policy setting “Configure TPM platform validation profile for native UEFI firmware configurations” is enabled and has PCR 7 omitted Bitlocker will be prevented from using Secure Boot for platform or Boot Configuration Data (BCD) integrity validation. Warning: Disabling this policy may result in BitLocker recovery when firmware is updated. If you disable this policy suspend BitLocker prior to applying firmware updates.

This policy setting allows you to configure how the computer’s Trusted Platform Module (TPM) security hardware secures the BitLocker encryption key. This policy setting does not apply if the computer does not have a compatible TPM or if BitLocker has already been turned on with TPM protection. Important: This group policy only applies to computers with a native UEFI firmware configuration. Computers with BIOS or UEFI firmware with a Compatibility Service Module (CSM) enabled store different values into the Platform Configuration Registers (PCRs). Use the “Configure TPM platform validation profile for BIOS-based firmware configurations” group policy setting to configure the TPM PCR profile for computers with BIOS configurations or computers with UEFI firmware with a CSM enabled. If you enable this policy setting before turning on BitLocker you can configure the boot components that the TPM will validate before unlocking access to the BitLocker-encrypted operating system drive. If any of these components change while BitLocker protection is in effect the TPM will not release the encryption key to unlock the drive and the computer will instead display the BitLocker Recovery console and require that either the recovery password or recovery key be provided to unlock the drive. If you disable or do not configure this policy setting BitLocker uses the default platform validation profile or the platform validation profile specified by the setup script. A platform validation profile consists of a set of Platform Configuration Register (PCR) indices ranging from 0 to 23. The default platform validation profile secures the encryption key against changes to the core system firmware executable code (PCR 0) extended or pluggable executable code (PCR 2) boot manager (PCR 4) and the BitLocker access control (PCR 11). Warning: Changing from the default platform validation profile affects the security and manageability of your computer. BitLocker’s sensitivity to platform modifications (malicious or authorized) is increased or decreased depending upon inclusion or exclusion (respectively) of the PCRs. Specifically setting this policy with PCR 7 omitted will override the “Allow Secure Boot for integrity validation” group policy preventing BitLocker from using Secure Boot for platform or Boot Configuration Data (BCD) integrity validation. Setting this policy may result in BitLocker recovery when firmware is updated. If you set this policy to include PCR 0 suspend BitLocker prior to applying firmware updates.

This policy setting allows you to choose specific Boot Configuration Data (BCD) settings to verify during platform validation. If you enable this policy setting you will be able to add additional settings remove the default settings or both. If you disable this policy setting the computer will revert to a BCD profile similar to the default BCD profile used by Windows 7. If you do not configure this policy setting the computer will verify the default Windows BCD settings. Note: When BitLocker is using Secure Boot for platform and Boot Configuration Data (BCD) integrity validation as defined by the “Allow Secure Boot for integrity validation” group policy the “Use enhanced Boot Configuration Data validation profile” group policy is ignored. The setting that controls boot debugging (0x16000010) will always be validated and will have no effect if it is included in the provided fields.

This policy setting allows you to configure the algorithm and cipher strength used by BitLocker Drive Encryption. This policy setting is applied when you turn on BitLocker. Changing the encryption method has no effect if the drive is already encrypted or if encryption is in progress. Consult the BitLocker Drive Encryption Deployment Guide on Microsoft TechNet for more information about the encryption methods available. This policy is only applicable to computers running Windows 8 and later. If you enable this policy setting you will be able to choose an encryption algorithm and key cipher strength for BitLocker to use to encrypt drives. If you disable or do not configure this policy setting BitLocker will use AES with the same bit strength (128-bit or 256-bit) as the “Choose drive encryption method and cipher strength (Windows Vista Windows Server 2008 Windows 7)” policy setting if it is set. If neither policy is set BitLocker will use the default encryption method of AES 128-bit or the encryption method specified by the setup script.

This policy setting allows you to control whether or not platform validation data is refreshed when Windows is started following BitLocker recovery. If you enable this policy setting platform validation data will be refreshed when Windows is started following BitLocker recovery. If you disable this policy setting platform validation data will not be refreshed when Windows is started following BitLocker recovery. If you do not configure this policy setting platform validation data will be refreshed when Windows is started following BitLocker recovery.

This setting prevents users from managing the ability to allow apps to access the user name account picture and domain information. If you enable this policy setting sharing of user name picture and domain information may be controlled by setting one of the following options:”Always on” – users will not be able to change this setting and the user’s name and account picture will be shared with apps (not desktop apps). In addition apps (not desktop apps) that have the enterprise authentication capability will also be able to retrieve the user’s UPN SIP/URI and DNS. “Always off” – users will not be able to change this setting and the user’s name and account picture will not be shared with apps (not desktop apps). In addition apps (not desktop apps) that have the enterprise authentication capability will not be able to retrieve the user’s UPN SIP/URI and DNS. Selecting this option may have a negative impact on certain enterprise software and/or line of business apps that depend on the domain information protected by this setting to connect with network resources. If you do not configure or disable this policy the user will have full control over this setting and can turn it off and on. Selecting this option may have a negative impact on certain enterprise software and/or line of business apps that depend on the domain information protected by this setting to connect with network resources if users choose to turn the setting off.

This policy setting controls on a per-computer basis whether roaming profiles are downloaded on a user’s primary computers only. This policy setting is useful to improve logon performance and to increase security for user data on computers where the user might not want to download private data such as on a meeting room computer or on a computer in a remote office. To designate a user’s primary computers an administrator must use management software or a script to add primary computer attributes to the user’s account in Active Directory Domain Services (AD DS). This policy setting also requires the Windows Server 2012 version of the Active Directory schema to function. If you enable this policy setting and the user has a roaming profile the roaming profile is downloaded on the user’s primary computer only. If you disable or do not configure this policy setting and the user has a roaming profile the roaming profile is downloaded on every computer that the user logs on to.

This policy setting allows you to specify the location and root (file share or local path) of a user’s home folder for a logon session. If you enable this policy setting the user’s home folder is configured to the specified local or network location creating a new folder for each user name. To use this policy setting in the Location list choose the location for the home folder. If you choose “On the network” enter the path to a file share in the Path box (for example -> -> ComputerName -> ShareName) and then choose the drive letter to assign to the file share. If you choose “On the local computer” enter a local path (for example C: -> HomeFolder) in the Path box. Do not specify environment variables or ellipses in the path. Also do not specify a placeholder for the user name because the user name will be appended at logon. Note: The Drive letter box is ignored if you choose “On the local computer” from the Location list. If you choose “On the local computer” and enter a file share the user’s home folder will be placed in the network location without mapping the file share to a drive letter. If you disable or do not configure this policy setting the user’s home folder is configured as specified in the user’s Active Directory Domain Services account. If the “Set Remote Desktop Services User Home Directory” policy setting is enabled the “Set user home folder” policy setting has no effect.

This policy setting allows you to manage the maximum number of authorization failures for each standard user for the Trusted Platform Module (TPM). If the number of authorization failures for the user within the duration for Standard User Lockout Duration equals this value the standard user is prevented from sending commands to the Trusted Platform Module (TPM) that require authorization. This setting helps administrators prevent the TPM hardware from entering a lockout mode because it slows the speed standard users can send commands requiring authorization to the TPM. An authorization failure occurs each time a standard user sends a command to the TPM and receives an error response indicating an authorization failure occurred. Authorization failures older than the duration are ignored. For each standard user two thresholds apply. Exceeding either threshold will prevent the standard user from sending a command to the TPM that requires authorization. This value is the maximum number of authorization failures each standard user may have before the user is not allowed to send commands requiring authorization to the TPM. The Standard User Lockout Total Threshold value is the maximum total number of authorization failures all standard users may have before all standard users are not allowed to send commands requiring authorization to the TPM. The TPM is designed to protect itself against password guessing attacks by entering a hardware lockout mode when it receives too many commands with an incorrect authorization value. When the TPM enters a lockout mode it is global for all users including administrators and Windows features like BitLocker Drive Encryption. The number of authorization failures a TPM allows and how long it stays locked out vary by TPM manufacturer. Some TPMs may enter lockout mode for successively longer periods of time with fewer authorization failures depending on past failures. Some TPMs may require a system restart to exit the lockout mode. Other TPMs may require the system to be on so enough clock cycles elapse before the TPM exits the lockout mode. An administrator with the TPM owner password may fully reset the TPM’s hardware lockout logic using the TPM Management Console (tpm. msc). Each time an administrator resets the TPM’s hardware lockout logic all prior standard user TPM authorization failures are ignored; allowing standard users to use the TPM normally again immediately. If this value is not configured a default value of 4 is used. A value of zero means the OS will not allow standard users to send commands to the TPM which may cause an authorization failure.