Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://docs.microsoft.com/en-us/windows/device-security/bitlocker/bitlocker-group-policy-settings below:

Configure BitLocker | Microsoft Learn

While many of the BitLocker policy settings can be configured using both CSP and GPO, there are some settings that are only available using one of the options. To learn about the policy settings available for both CSP and GPO, review the section BitLocker policy settings.

The following table lists the Windows editions that support BitLocker management:

This section describes the policy settings to configure BitLocker via configuration service provider (CSP) and group policy (GPO).

The following table lists the BitLocker policies applicable to all drive types, indicating if they're applicable via configuration service provider (CSP) and/or group policy (GPO). Select the policy name for more details.

With this policy you can enforce the Require device encryption policy for scenarios where the policy is applied while the current logged-on user doesn't have administrative rights.

Specify the default path that is displayed when the BitLocker Drive Encryption setup wizard prompts the user to enter the location of a folder in which to save the recovery password. You can specify either a fully qualified path or include the target computer's environment variables in the path:

• If the path isn't valid, the BitLocker setup wizard displays the computer's top-level folder view
• If you disable or don't configure this policy setting, the BitLocker setup wizard displays the computer's top-level folder view when the user chooses the option to save the recovery password in a folder

Note

This policy setting does not prevent the user from saving the recovery password in another folder.

With this policy, you can configure an encryption algorithm and key cipher strength for fixed data drives, operating system drives, and removable data drives individually.

Recommended settings: XTS-AES algorithm for all drives. The choice of key size, 128 bit or 256 bit depends on the performance of the device. For more performant hard drives and CPU, choose 256-bit key, for less performant ones use 128.

Important

Key size might be required by regulators or industry.

If you disable or don't configure this policy setting, BitLocker uses the default encryption method of XTS-AES 128-bit.

Note

This policy doesn't apply to encrypted drives. Encrypted drives utilize their own algorithm, which is set by the drive during partitioning.

With this policy you can configure a numeric recovery password rotation upon use for OS and fixed drives on Microsoft Entra joined and Microsoft Entra hybrid joined devices.

Possible values are:

• 0: numeric recovery password rotation is turned off
• 1: numeric recovery password rotation upon use is on for Microsoft Entra joined devices. This is also the default value
• 2: numeric recovery password rotation upon use is on for both Microsoft Entra joined devices and Microsoft Entra hybrid joined devices

Note

The policy is effective only when Microsoft Entra ID or Active Directory backup for recovery password is configured to required

• For OS drive: enable Do not enable BitLocker until recovery information is stored to AD DS for operating system drives
• For fixed drives: enable "Do not enable BitLocker until recovery information is stored to AD DS for fixed data drives

When enabled, this policy setting blocks direct memory access (DMA) for all hot pluggable PCI ports until a user signs into Windows.

Once a user signs in, Windows enumerates the PCI devices connected to the host Thunderbolt PCI ports. Every time the user locks the device, DMA is blocked on hot plug Thunderbolt PCI ports with no children devices, until the user signs in again.

Devices that were already enumerated when the device was unlocked will continue to function until unplugged, or the system is rebooted or hibernated.

This policy setting is only enforced when BitLocker or device encryption is enabled.

Important

This policy is not compatible with Kernel DMA Protection. It's recommended to disable this policy if the system supports Kernel DMA Protection, as Kernel DMA Protection provides higher security for the system. For more information about Kernel DMA Protection, see Kernel DMA Protection.

This policy setting is used to control whether the computer's memory is overwritten when the device restarts. BitLocker secrets include key material used to encrypt data.

• If you enable this policy setting, memory isn't overwritten when the computer restarts. Preventing memory overwrite may improve restart performance but increases the risk of exposing BitLocker secrets.
• If you disable or do not configure this policy setting, BitLocker secrets are removed from memory when the computer restarts.

Note

This policy setting applies only when BitLocker protection is enabled.

This policy setting allows you to associate unique organizational identifiers to a drive that is encrypted with BitLocker. The identifiers are stored as the identification field and allowed identification field:

• The identification field allows you to associate a unique organizational identifier to BitLocker-protected drives. This identifier is automatically added to new BitLocker-protected drives and can be updated on existing BitLocker-protected drives using the BitLocker Drive Encryption: Configuration Tool (manage-bde.exe)
• The allowed identification field is used in combination with the Deny write access to removable drives not protected by BitLocker policy setting to help control the use of removable drives in your organization. It's a comma separated list of identification fields from your organization or other external organizations. You can configure the identification fields on existing drives by using manage-bde.exe.

If you enable this policy setting, you can configure the identification field on the BitLocker-protected drive and any allowed identification field used by your organization. When a BitLocker-protected drive is mounted on another BitLocker-enabled device, the identification field and allowed identification field are used to determine whether the drive is from a different organization.

If you disable or don't configure this policy setting, the identification field is not required.

Important

Identification fields are required for management of certificate-based data recovery agents on BitLocker-protected drives. BitLocker only manages and updates certificate-based data recovery agents when the identification field is present on a drive and is identical to the value configured on the device. The identification field can be any value of 260 characters or fewer.

This policy setting determines whether BitLocker is required:

• If enabled, encryption is triggered on all drives silently or non-silently based on Allow warning for other disk encryption policy
• If disabled, BitLocker isn't turned off for the system drive, but it stops prompting the user to turn BitLocker on.

Encryptable fixed data volumes are treated similarly to OS volumes, but they must meet other criteria to be encryptable:

• It must not be a dynamic volume
• It must not be a recovery partition
• It must not be a hidden volume
• It must not be a system partition
• It must not be backed by virtual storage
• It must not have a reference in the BCD store

This policy setting is used to determine which certificate to use with BitLocker by associating an object identifier (OID) from a smart card certificate to a BitLocker-protected drive. The object identifier is specified in the enhanced key usage (EKU) of a certificate.

BitLocker can identify which certificates may be used to authenticate a user certificate to a BitLocker-protected drive by matching the object identifier in the certificate with the object identifier that is defined by this policy setting. Default OID is 1.3.6.1.4.1.311.67.1.1.

If you enable this policy setting, the object identifier specified in the Object identifier field must match the object identifier in the smart card certificate. If you disable or don't configure this policy setting, the default OID is used.

Note

BitLocker doesn't require that a certificate have an EKU attribute; however, if one is configured for the certificate, it must be set to an object identifier that matches the object identifier configured for BitLocker.

This policy setting allows users on devices that are compliant with InstantGo or Microsoft Hardware Security Test Interface (HSTI) to not have a PIN for preboot authentication.

The policy overrides the Require startup PIN with TPM and Require startup key and PIN with TPM options of the Require additional authentication at startup policy on compliant hardware.

• If you enable this policy setting, users on InstantGo and HSTI compliant devices can turn on BitLocker without preboot authentication
• If the policy is disabled or not configured, the options of Require additional authentication at startup policy apply

This setting permits the use of enhanced PINs when an unlock method that includes a PIN is used.

Enhanced startup PINs permit the use of characters (including uppercase and lowercase letters, symbols, numbers, and spaces).

Important

Not all computers support enhanced PIN characters in the preboot environment. It's strongly recommended that users perform a system check during the BitLocker setup to verify that enhanced PIN characters can be used.

This policy setting controls whether a BitLocker-protected device that is connected to a trusted wired Local Area Network (LAN) can create and use Network Key Protectors on TPM-enabled computers to automatically unlock the operating system drive when the computer is started.

If you enable this policy, devices configured with a BitLocker Network Unlock certificate can create and use Network Key Protectors. To use a Network Key Protector to unlock the computer, both the computer and the BitLocker Drive Encryption Network Unlock server must be provisioned with a Network Unlock certificate. The Network Unlock certificate is used to create Network Key Protectors, and protects the information exchanged with the server to unlock the computer.

The Group Policy setting Computer Configuration > Windows Settings > Security Settings > Public Key Policies > BitLocker Drive Encryption Network Unlock Certificate can be used on the domain controller to distribute this certificate to computers in the organization. This unlock method uses the TPM on the computer, so computers that don't have a TPM can't create Network Key Protectors to automatically unlock with Network Unlock.

If you disable or don't configure this policy setting, BitLocker clients won't be able to create and use Network Key Protectors.

Note

For reliability and security, computers should also have a TPM startup PIN that can be used when the computer is disconnected from the wired network or the server at startup.

For more information about Network Unlock feature, see BitLocker: How to enable Network Unlock

This policy setting allows you to configure whether Secure Boot is allowed as the platform integrity provider for BitLocker operating system drives.

Secure Boot ensures that the device's preboot environment only loads firmware that is digitally signed by authorized software publishers.

• If you enable or don't configure this policy setting, BitLocker uses Secure Boot for platform integrity if the platform is capable of Secure Boot-based integrity validation
• If you disable this policy setting, BitLocker uses 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 policy setting is ignored and Secure Boot verifies BCD settings according to the Secure Boot policy setting, which is configured separately from BitLocker.

Warning

Disabling this policy might result in BitLocker recovery when manufacturer-specific firmware is updated. If this policy is disabled, suspend BitLocker prior to applying firmware updates.

With this policy you can disable all notification for encryption, warning prompt for other disk encryption, and turn on encryption silently.

Important

This policy applies to Microsoft Entra joined devices only.

This policy takes effect only if Require device encryption policy is enabled.

Warning

When you enable BitLocker on a device with non-Microsoft encryption, it may render the device unusable and will require reinstallation of Windows.

The expected values for this policy are:

• Enabled (default): warning prompt and encryption notification is allowed
• Disabled: warning prompt and encryption notification are suppressed. Windows will attempt to silently enable BitLocker

Note

When you disable the warning prompt, the OS drive's recovery key will back up to the user's Microsoft Entra ID account. When you allow the warning prompt, the user who receives the prompt can select where to back up the OS drive's recovery key.

The endpoint for a fixed data drive's backup is chosen in the following order:

1. The user's Windows Server Active Directory Domain Services account
2. The user's Microsoft Entra ID account
3. The user's personal OneDrive (MDM/MAM only)

Encryption will wait until one of these three locations backs up successfully.

This policy setting allows you to control how BitLocker-protected operating system drives are recovered in the absence of the required startup key information. If you enable this policy setting, you can control the methods available to users to recover data from BitLocker-protected operating system drives. Here are the available options:

• Allow certificate-based data recovery agent: specify whether a data recovery agent can be used with BitLocker-protected OS drives. Before a data recovery agent can be used, it must be added from the Public Key Policies item in either the Group Policy Management Console or the Local Group Policy Editor
• Configure user storage of BitLocker recovery information: select whether users are allowed, required, or not allowed to generate a 48-digit recovery password or a 256-bit recovery key
• Omit recovery options from the BitLocker setup wizard: prevent users from specifying recovery options when they turn on BitLocker for a drive. This means that users won't be able to specify which recovery option to use when they turn on BitLocker. BitLocker recovery options for the drive are determined by the policy setting
• Save BitLocker recovery information to Active Directory Domain Services: choose which BitLocker recovery information to store in AD DS for operating system drives. If you select Backup recovery password and key package, both the BitLocker recovery password and key package are stored in AD DS. Storing the key package supports recovering data from a drive that has been physically corrupted. If you select Backup recovery password only, only the recovery password is stored in AD DS
• Do not enable BitLocker until recovery information is stored in AD DS for operating system drives: prevents users from enabling BitLocker unless the device is connected to the domain and the backup of BitLocker recovery information to AD DS succeeds. When using this option, a recovery password is automatically generated.

If this policy setting is disabled or not configured, the default recovery options are supported for BitLocker recovery. By default a DRA is allowed, the recovery options can be specified by the user including the recovery password and recovery key, and recovery information is not backed up to AD DS.

For Microsoft Entra hybrid joined devices, the BitLocker recovery password is backed up to both Active Directory and Entra ID.

For Microsoft Entra joined devices, the BitLocker recovery password is backed up to Entra ID.

This policy configures a minimum length for a Trusted Platform Module (TPM) startup PIN. The startup PIN must have a minimum length of 4 digits and can have a maximum length of 20 digits.

If you enable this policy setting, you can require a minimum number of digits to be used when setting the startup PIN.
If you disable or do not configure this policy setting, users can configure a startup PIN of any length between 6 and 20 digits.

The TPM can be configured to use Dictionary Attack Prevention parameters (lockout threshold and lockout duration to control how many failed authorizations attempts are allowed before the TPM is locked out, and how much time must elapse before another attempt can be made.

The Dictionary Attack Prevention Parameters provide a way to balance security needs with usability. For example, when BitLocker is used with a TPM + PIN configuration, the number of PIN guesses is limited over time. A TPM 2.0 in this example could be configured to allow only 32 PIN guesses immediately, and then only one more guess every two hours. This number of attempts totals to a maximum of about 4415 guesses per year. If the PIN is four digits, all 9999 possible PIN combinations could be attempted in a little over two years.

Tip

Increasing the PIN length requires a greater number of guesses for an attacker. In that case, the lockout duration between each guess can be shortened to allow legitimate users to retry a failed attempt sooner, while maintaining a similar level of protection.

Note

If minimum PIN length is set below 6 digits, Windows will attempt to update the TPM 2.0 lockout period to be greater than the default when a PIN is changed. If successful, Windows will only reset the TPM lockout period back to default if the TPM is reset.

This policy setting is used to configure the recovery message and to replace the existing URL that is displayed on the preboot recovery screen when the OS drive is locked.

• If you select the Use default recovery message and URL option, the default BitLocker recovery message and URL are displayed in the preboot key recovery screen. If you have previously configured a custom recovery message or URL and want to revert to the default message, you must keep the policy enabled and select the Use default recovery message and URL option
• If you select the Use custom recovery message option, the message you add to the Custom recovery message option text box is displayed in the preboot key recovery screen. If a recovery URL is available, include it in the message
• If you select the Use custom recovery URL option, the URL you add to the Custom recovery URL option text box replaces the default URL in the default recovery message, which is displayed in the preboot key recovery screen

Note

Not all characters and languages are supported in pre-boot. It is strongly recommended that you test that the characters you use for the custom message or URL appear correctly on the pre-boot recovery screen.

For more information about the BitLocker preboot recovery screen, see Preboot recovery screen.

This policy setting determines what values the TPM measures when it validates early boot components before it unlocks an operating system drive on a computer with a BIOS configuration or with UEFI firmware that has the Compatibility Support Module (CSM) enabled.

• When enabled, the boot components that the TPM validates before unlocking access to the BitLocker-encrypted operating system drive can be configured. If any of these components change while BitLocker protection is in effect, then the TPM doesn't release the encryption key to unlock the drive. Instead, the computer displays the BitLocker Recovery console and requires that the recovery password or the recovery key is provided to unlock the drive.
• When disabled or not configured, the TPM uses the default platform validation profile or the platform validation profile that is specified by the setup script.

This policy setting doesn't apply if the computer doesn't have a compatible TPM or if BitLocker has already been turned on with TPM protection.

Important

This Group Policy setting only applies to computers with BIOS configurations or to computers with UEFI firmware with the CSM enabled. Computers that use a native UEFI firmware configuration store different values in the Platform Configuration Registers (PCRs). Use the Configure TPM platform validation profile for native UEFI firmware configurations policy setting to configure the TPM PCR profile for computers that use native UEFI firmware.

A platform validation profile consists of a set of PCR indices that range from 0 to 23. Each PCR index represents a specific measurement that the TPM validates during early boot. The default platform validation profile secures the encryption key against changes to the following PCRs:

Note

Changing from the default platform validation profile affects the security and manageability of a computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or decreased depending on inclusion or exclusion (respectively) of the PCRs.

The following list identifies all of the available PCRs:

This policy setting determines what values the TPM measures when it validates early boot components, before unlocking the OS drive on native-UEFI firmware device.

• If you enable this policy setting before turning on BitLocker, you can configure the boot components that the TPM validates before unlocking access to the BitLocker-encrypted OS drive. If any of these components change while BitLocker protection is in effect, the TPM doesn't release the encryption key to unlock the drive. The device displays the BitLocker Recovery console and requires 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 for the available hardware, or the platform validation profile specified by the setup script

Important

This policy setting only applies to devices with a native UEFI firmware configuration. Computers with BIOS or UEFI firmware with a Compatibility Support Module (CSM) enabled store different values in the Platform Configuration Registers (PCRs). Use the Configure TPM platform validation profile for BIOS-based firmware configurations policy setting to configure the TPM PCR profile for devices with BIOS configurations, or for devices with UEFI firmware with a CSM enabled.

A platform validation profile consists of a set of PCR indices ranging from 0 to 23. The default platform validation profile secures the encryption key against changes to the following PCRs:

Note

When Secure Boot State (PCR7) support is available, the default platform validation profile secures the encryption key using Secure Boot State (PCR 7) and the BitLocker access control (PCR 11).

The following list identifies all of the available PCRs:

Warning

Changing from the default platform validation profile affects the security and manageability of a device. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or decreased depending on inclusion or exclusion (respectively) of the PCRs.

Setting this policy with PCR 7 omitted, overrides the Allow Secure Boot for integrity validation 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. It is recommended to not configure this policy, to allow Windows to select the PCR profile for the best combination of security and usability based on the available hardware on each device.

PCR 7 measures the state of Secure Boot. With PCR 7, BitLocker can use Secure Boot for integrity validation. Secure Boot ensures that the computer's preboot environment loads only firmware that is digitally signed by authorized software publishers. PCR 7 measurements indicate whether Secure Boot is on, and which keys are trusted on the platform. If Secure Boot is on and the firmware measures PCR 7 correctly per the UEFI specification, BitLocker can bind to this information rather than to PCRs 0, 2, and 4, which have the measurements of the exact firmware and Bootmgr images loaded. This process reduces the likelihood of BitLocker starting in recovery mode as a result of firmware and image updates, and it provides with greater flexibility to manage the preboot configuration.

PCR 7 measurements must follow the guidance that is described in Appendix A Trusted Execution Environment EFI Protocol.

PCR 7 measurements are a mandatory logo requirement for systems that support Modern Standby (also known as Always On, Always Connected PCs). On such systems, if the TPM with PCR 7 measurement and secure boot are correctly configured, BitLocker binds to PCR 7 and PCR 11 by default.

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 options that control whether BitLocker software-based encryption is used instead of hardware-based encryption on devices that don't support hardware-based encryption. You can also specify if you want to restrict the encryption algorithms and cipher suites used with hardware-based encryption.

If you disable this policy setting, BitLocker can't 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 software-based encryption, irrespective of hardware-based encryption availability.

Note

The Choose drive encryption method and cipher strength policy setting doesn't 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 isn't available, BitLocker disables 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 specifies the constraints for passwords used to unlock BitLocker-protected operating system drives. If non-TPM protectors are allowed on operating system drives, you can provision a password, enforce complexity requirements, and configure a minimum length.

Important

For the complexity requirement setting to be effective, the group policy setting Password must meet complexity requirements located in Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy, must be also enabled.

If you enable this policy setting, users can configure a password that meets the requirements you define. To enforce complexity requirements on the password, select Require complexity:

• When set to Require complexity, a connection to a domain controller is necessary when BitLocker is enabled to validate the complexity the password
• When set to Allow complexity, a connection to a domain controller is attempted to validate that the complexity adheres to the rules set by the policy. If no domain controllers are found, the password is accepted regardless of actual password complexity and the drive will be encrypted using that password as a protector
• When set to Do not allow complexity, password complexity isn't validated

Passwords must be at least eight characters. To configure a greater minimum length for the password, specify the desired number of characters under Minimum password length

If you disable or don't configure this policy setting, the default length constraint of eight characters applies to operating system drive passwords, and no complexity checks occur.

This policy allows configuration of whether standard users are allowed to change the PIN or password that is used to protect the operating system drive, if they can provide the existing PIN first.

If you enable this policy, standard users can't change BitLocker PINs or passwords. If you disable or don't configure this policy, standard users can change BitLocker PINs and passwords.

This policy setting allows users to turn on authentication options that require user input from the preboot environment, even if the platform lacks preboot input capability. The Windows touch keyboard (such as that used by tablets) isn't available in the preboot environment where BitLocker requires additional information such as a PIN or Password.

• If you enable this policy setting, devices must have an alternative means of preboot input (such as an attached USB keyboard).
• If this policy isn't enabled, the Windows Recovery Environment must be enabled on tablets to support the entry of the BitLocker recovery password.

It's recommended that administrators enable this policy only for devices that are verified to have an alternative means of preboot input, such as attaching a USB keyboard.

When the Windows Recovery Environment (WinRE) isn't enabled and this policy isn't enabled, BitLocker can't be turned on a device that uses a touch keyboard.

If this policy setting isn't enabled, the following options in the Require additional authentication at startup policy might not be available:

• Configure TPM startup PIN: Required and Allowed
• Configure TPM startup key and PIN: Required and Allowed
• Configure use of passwords for operating system drives

This policy setting allows you to configure the encryption type used by BitLocker Drive Encryption.

When you enable this policy setting, the encryption type option isn't offered in the BitLocker setup wizard:

• Choose full encryption to require that the entire drive be encrypted when BitLocker is turned on
• Choose used space only encryption to require that only the portion of the drive used to store data is encrypted when BitLocker is turned on

If you disable or don't configure this policy setting, the BitLocker setup wizard asks the user to select the encryption type before turning on BitLocker.

Note

Changing the encryption type has no effect if the drive is already encrypted or if encryption is in progress.

This policy is ignored when shrinking or expanding a volume, and the BitLocker driver uses the current encryption method. For example, when a drive that is using Used Space Only encryption is expanded, the new free space isn't wiped like a drive that uses Full encryption. The user could wipe the free space on a Used Space Only drive by using the following command: manage-bde.exe -w. If the volume is shrunk, no action is taken for the new free space.

This policy setting configures whether BitLocker requires extra authentication each time the device starts.

If you enable this policy, users can configure advanced startup options in the BitLocker setup wizard.
If you disable or don't configure this policy setting, users can configure only basic options on computers with a TPM.

Note

Only one of the additional authentication options can be required at startup, otherwise a policy error occurs.

If you want to use BitLocker on a device without a TPM, select the option Allow BitLocker without a compatible TPM. In this mode, either a password or a USB drive is required for startup.
When using a startup key, the key information used to encrypt the drive is stored on the USB drive, creating a USB key. When the USB key is inserted, the access to the drive is authenticated and the drive is accessible. If the USB key is lost or unavailable, or if you have forgotten the password, then you must use one of the BitLocker recovery options to access the drive.

On a computer with a compatible TPM, four types of authentication methods can be used at startup to provide added protection for encrypted data. When the computer starts, it can use:

• TPM only
• a USB flash drive containing a startup key
• a PIN (6-digit to 20-digit)
• PIN + USB flash drive

Note

If you want to require the use of a startup PIN and a USB flash drive, you must configure BitLocker settings using the command-line tool manage-bde instead of the BitLocker Drive Encryption setup wizard.

There are four options for TPM-enabled devices:

• Configure TPM startup

  • Allow TPM
  • Require TPM
  • Don't allow TPM

• Configure TPM startup PIN

  • Allow startup PIN with TPM
  • Require startup PIN with TPM
  • Don't allow startup PIN with TPM

• Configure TPM startup key

  • Allow startup key with TPM
  • Require startup key with TPM
  • Don't allow startup key with TPM

• Configure TPM startup key and PIN

  • Allow TPM startup key with PIN
  • Require startup key and PIN with TPM
  • Don't allow TPM startup key with PIN

This policy setting determines if platform validation data should refresh when Windows is started following a BitLocker recovery. A platform validation data profile consists of the values in a set of Platform Configuration Register (PCR) indices that range from 0 to 23.

If you enable this policy setting, platform validation data is refreshed when Windows is started following BitLocker recovery. This is the default behavior.
If you disable this policy setting, platform validation data won't be refreshed when Windows is started following BitLocker recovery.

For more information about the recovery process, see the BitLocker recovery overview.

This policy setting determines specific Boot Configuration Data (BCD) settings to verify during platform validation. A platform validation uses the data in the platform validation profile, which consists of a set of Platform Configuration Register (PCR) indices that range from 0 to 23.

If you don't configure this policy setting, the device will verify the default Windows BCD settings.

Note

When BitLocker is using Secure Boot for platform and BCD integrity validation, as defined by the Allow Secure Boot for integrity validation policy setting, this policy setting is ignored. The setting that controls boot debugging 0x16000010 is always validated, and it has no effect if it's included in the inclusion or exclusion list.

This policy setting allows you to control how BitLocker-protected fixed data drives are recovered in the absence of the required startup key information. If you enable this policy setting, you can control the methods available to users to recover data from BitLocker-protected fixed data drives. Here are the available options:

• Allow certificate-based data recovery agent: specify whether a data recovery agent can be used with BitLocker-protected fixed data drives. Before a data recovery agent can be used, it must be added from the Public Key Policies item in either the Group Policy Management Console or the Local Group Policy Editor
• Configure user storage of BitLocker recovery information: select whether users are allowed, required, or not allowed to generate a 48-digit recovery password or a 256-bit recovery key
• Omit recovery options from the BitLocker setup wizard: prevent users from specifying recovery options when they turn on BitLocker for a drive. This means that users won't be able to specify which recovery option to use when they turn on BitLocker. BitLocker recovery options for the drive are determined by the policy setting
• Save BitLocker recovery information to Active Directory Domain Services: choose which BitLocker recovery information to store in AD DS for fixed data drives. If you select Backup recovery password and key package, both the BitLocker recovery password and key package are stored in AD DS. Storing the key package supports recovering data from a drive that has been physically corrupted. If you select Backup recovery password only, only the recovery password is stored in AD DS
• Do not enable BitLocker until recovery information is stored in AD DS for fixed data drives: prevents users from enabling BitLocker unless the device is connected to the domain and the backup of BitLocker recovery information to AD DS succeeds. When using this option, a recovery password is automatically generated.

For Microsoft Entra hybrid joined devices, the BitLocker recovery password is backed up to both Active Directory and Entra ID.

For Microsoft Entra joined devices, the BitLocker recovery password is backed up to Entra ID.

Important

The use of recovery keys must be disallowed if the Deny write access to fixed drives not protected by BitLocker policy setting is enabled.

If this policy setting is disabled or not configured, the default recovery options are supported for BitLocker recovery. By default a DRA is allowed, the recovery options can be specified by the user including the recovery password and recovery key, and recovery information is not backed up to AD DS.

This policy setting allows you to manage BitLocker's use of hardware-based encryption on fixed data 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 options that control whether BitLocker software-based encryption is used instead of hardware-based encryption on devices that don't support hardware-based encryption. You can also specify if you want to restrict the encryption algorithms and cipher suites used with hardware-based encryption.

If you disable this policy setting, BitLocker can't use hardware-based encryption with fixed data 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 software-based encryption, irrespective of hardware-based encryption availability.

Note

The Choose drive encryption method and cipher strength policy setting doesn't 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 isn't available, BitLocker disables 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 specifies whether a password is required to unlock BitLocker-protected fixed data drives. If you choose to allow the use of a password, you can require that a password be used, enforce complexity requirements, and configure a minimum length.

Important

For the complexity requirement setting to be effective, the group policy setting Password must meet complexity requirements located in Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy, must be also enabled.

If you enable this policy setting, users can configure a password that meets the requirements you define. To enforce complexity requirements on the password, select Require complexity:

• When set to Require complexity, a connection to a domain controller is necessary when BitLocker is enabled to validate the complexity the password
• When set to Allow complexity, a connection to a domain controller is attempted to validate that the complexity adheres to the rules set by the policy. If no domain controllers are found, the password is accepted regardless of actual password complexity and the drive will be encrypted using that password as a protector
• When set to Do not allow complexity, password complexity isn't validated

Passwords must be at least eight characters. To configure a greater minimum length for the password, specify the desired number of characters under Minimum password length

If you disable or don't configure this policy setting, the default length constraint of eight characters applies to operating system drive passwords, and no complexity checks occur.

This policy setting allows you to specify whether smart cards can be used to authenticate user access to the BitLocker-protected fixed data drives.

• If you enable this policy setting, smart cards can be used to authenticate user access to the drive
  • You can require a smart card authentication by selecting the Require use of smart cards on fixed data drives option
• If you disable this policy setting, users can't use smart cards to authenticate their access to BitLocker-protected fixed data drives
• If you don't configure this policy setting, smart cards can be used to authenticate user access to a BitLocker-protected drive

This policy setting is used to require encryption of fixed drives prior to granting write access.

If you enable this policy setting, all fixed data drives that are not BitLocker-protected will be mounted as read-only. If the drive is protected by BitLocker, it will be mounted with read and write access.

If you disable or don't configure this policy setting, all fixed data drives on the computer will be mounted with read and write access.

Note

When this policy setting is enabled, users receive Access denied error messages when they try to save data to unencrypted fixed data drives.

If the BitLocker Drive Preparation Tool BdeHdCfg.exe is executed on a computer when this policy setting is enabled, the following issues could be encountered:

• If you attempt to shrink a drive to create the system drive, the drive size is successfully reduced, and a raw partition is created. However, the raw partition isn't formatted. The following error message is displayed: The new active drive cannot be formatted. You may need to manually prepare your drive for BitLocker.
• If you attempt to use unallocated space to create the system drive, a raw partition is created. However, the raw partition isn't be formatted. The following error message is displayed: The new active drive cannot be formatted. You may need to manually prepare your drive for BitLocker.
• If you attempt to merge an existing drive into the system drive, the tool fails to copy the required boot file onto the target drive to create the system drive. The following error message is displayed: BitLocker setup failed to copy boot files. You may need to manually prepare your drive for BitLocker.

This policy setting controls the use of BitLocker on fixed data drives.

If you enable this policy setting the encryption type that BitLocker uses to encrypt drives is defined by this policy, and the encryption type option won't be presented in the BitLocker setup wizard:

• Choose full encryption to require that the entire drive be encrypted when BitLocker is turned on
• Choose used space only encryption to require that only the portion of the drive used to store data is encrypted when BitLocker is turned on

If you disable or don't configure this policy setting, the BitLocker setup wizard asks the user to select the encryption type before turning on BitLocker.

Note

Changing the encryption type has no effect if the drive is already encrypted or if encryption is in progress.

This policy is ignored when shrinking or expanding a volume, and the BitLocker driver uses the current encryption method. For example, when a drive that is using Used Space Only encryption is expanded, the new free space isn't wiped like a drive that uses Full encryption. The user could wipe the free space on a Used Space Only drive by using the following command: manage-bde.exe -w. If the volume is shrunk, no action is taken for the new free space.

This policy setting allows you to control how BitLocker-protected removable data drives are recovered in the absence of the required startup key information. If you enable this policy setting, you can control the methods available to users to recover data from BitLocker-protected removable data drives. Here are the available options:

• Allow certificate-based data recovery agent: specify whether a data recovery agent can be used with BitLocker-protected removable data drives. Before a data recovery agent can be used, it must be added from the Public Key Policies item in either the Group Policy Management Console or the Local Group Policy Editor
• Configure user storage of BitLocker recovery information: select whether users are allowed, required, or not allowed to generate a 48-digit recovery password or a 256-bit recovery key
• Omit recovery options from the BitLocker setup wizard: prevent users from specifying recovery options when they turn on BitLocker for a drive. This means that users won't be able to specify which recovery option to use when they turn on BitLocker. BitLocker recovery options for the drive are determined by the policy setting
• Save BitLocker recovery information to Active Directory Domain Services: choose which BitLocker recovery information to store in AD DS for removable data drives. If you select Backup recovery password and key package, both the BitLocker recovery password and key package are stored in AD DS. Storing the key package supports recovering data from a drive that has been physically corrupted. If you select Backup recovery password only, only the recovery password is stored in AD DS
• Do not enable BitLocker until recovery information is stored in AD DS for removable data drives: prevents users from enabling BitLocker unless the device is connected to the domain and the backup of BitLocker recovery information to AD DS succeeds. When using this option, a recovery password is automatically generated.

Important

The use of recovery keys must be disallowed if the Deny write access to removable drives not protected by BitLocker policy setting is enabled.

If this policy setting is disabled or not configured, the default recovery options are supported for BitLocker recovery. By default a DRA is allowed, the recovery options can be specified by the user including the recovery password and recovery key, and recovery information is not backed up to AD DS.

This policy setting allows you to manage BitLocker's use of hardware-based encryption on removable data 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 options that control whether BitLocker software-based encryption is used instead of hardware-based encryption on devices that don't support hardware-based encryption. You can also specify if you want to restrict the encryption algorithms and cipher suites used with hardware-based encryption.

If you disable this policy setting, BitLocker can't use hardware-based encryption with removable data 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 software-based encryption, irrespective of hardware-based encryption availability.

Note

The Choose drive encryption method and cipher strength policy setting doesn't 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 isn't available, BitLocker disables 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 specifies whether a password is required to unlock BitLocker-protected removable data drives. If you choose to allow the use of a password, you can require that a password be used, enforce complexity requirements, and configure a minimum length.

Important

For the complexity requirement setting to be effective, the group policy setting Password must meet complexity requirements located in Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy, must be also enabled.

If you enable this policy setting, users can configure a password that meets the requirements you define. To enforce complexity requirements on the password, select Require complexity:

• When set to Require complexity, a connection to a domain controller is necessary when BitLocker is enabled to validate the complexity of the password
• When set to Allow complexity, a connection to a domain controller is attempted to validate that the complexity adheres to the rules set by the policy. If no domain controllers are found, the password is accepted regardless of actual password complexity and the drive will be encrypted using that password as a protector
• When set to Do not allow complexity, password complexity isn't validated

Passwords must be at least 8 characters. To configure a greater minimum length for the password, specify the desired number of characters under Minimum password length

If you disable or don't configure this policy setting, the default length constraint of eight characters applies to operating system drive passwords, and no complexity checks occur.

This policy setting allows you to specify whether smart cards can be used to authenticate user access to the BitLocker-protected removable data drives.

• If you enable this policy setting, smart cards can be used to authenticate user access to the drive
  • You can require a smart card authentication by selecting the Require use of smart cards on removable data drives option
• If you disable this policy setting, users can't use smart cards to authenticate their access to BitLocker-protected removable data drives
• If you don't configure this policy setting, smart cards can be used to authenticate user access to a BitLocker-protected drive

This policy setting controls the use of BitLocker on removable data drives.

When this policy setting is enabled, you can select property settings that control how users can configure BitLocker:

• Choose Allow users to apply BitLocker protection on removable data drives to permit the user to run the BitLocker setup wizard on a removable data drive
• Choose Allow users to suspend and decrypt BitLocker on removable data drives to permit the user to remove BitLocker encryption from the drive or suspend the encryption while maintenance is performed

If you disable this policy setting, users can't use BitLocker on removable disk drives.

This policy setting configures whether BitLocker protection is required for a device to be able to write data to a removable data drive.

If you enable this policy setting:

• all removable data drives that are not BitLocker-protected are mounted as read-only
• if the drive is protected by BitLocker, it's mounted with read and write access
• if the Deny write access to devices configured in another organization option is selected, only drives with identification fields matching the computer's identification fields are given write access
  • When a removable data drive is accessed, it's checked for valid identification field and allowed identification fields. These fields are defined by the (Provide the unique identifiers for your organization)[] policy setting

If you disable or do not configure this policy setting, all removable data drives on the computer are mounted with read and write access.

Note

This policy setting is ignored if the policy settings Removable Disks: Deny write access is enabled.

Important

If you enable this policy:

• Use of BitLocker with the TPM startup key or TPM key and PIN must be disallowed
• Use of recovery keys must be disallowed

This policy setting controls the use of BitLocker on removable data drives.

When you enable this policy setting, the encryption type option isn't offered in the BitLocker setup wizard:

• Choose full encryption to require that the entire drive be encrypted when BitLocker is turned on
• Choose used space only encryption to require that only the portion of the drive used to store data is encrypted when BitLocker is turned on

If you disable or don't configure this policy setting, the BitLocker setup wizard asks the user to select the encryption type before turning on BitLocker.

Note

Changing the encryption type has no effect if the drive is already encrypted or if encryption is in progress.

This policy is ignored when shrinking or expanding a volume, and the BitLocker driver uses the current encryption method. For example, when a drive that is using Used Space Only encryption is expanded, the new free space isn't wiped like a drive that uses Full encryption. The user could wipe the free space on a Used Space Only drive by using the following command: manage-bde.exe -w. If the volume is shrunk, no action is taken for the new free space.

If a device isn't compliant with the configured policy settings, BitLocker might not be turned on, or BitLocker configuration might be modified until the device is in a compliant state. When a drive becomes out of compliance with policy settings, only changes to the BitLocker configuration that will bring it into compliance are allowed. Such scenario could occur, for example, if a previously encrypted drive becomes noncompliant by a policy setting change.

If multiple changes are necessary to bring the drive into compliance, BitLocker protection might need to be suspended, the necessary changes made, and then protection resumed. Such situation could occur, for example, if a removable drive is initially configured for unlock with a password, and then policy settings are changed to require smart cards. In this scenario, BitLocker protection needs to be suspended, delete the password unlock method, and add the smart card method. After this process is complete, BitLocker is compliant with the policy setting, and BitLocker protection on the drive can be resumed.

In other scenarios, to bring the drive into compliance with a change in policy settings, BitLocker might need to be disabled and the drive decrypted followed by re-enabling BitLocker and then re-encrypting the drive. An example of this scenario is when the BitLocker encryption method or cipher strength is changed.

Servers are often deployed, configured, and managed using PowerShell. The recommendation is to use group policy settings to configure BitLocker on servers, and to manage BitLocker using PowerShell.

BitLocker is an optional component in Windows Server. Follow the directions in Install BitLocker on Windows Server to add the BitLocker optional component.

Lights-out data centers can take advantage of the enhanced security of a second factor while avoiding the need for user intervention during reboots by optionally using a combination of BitLocker (TPM+PIN) and BitLocker Network Unlock. BitLocker Network Unlock brings together the best of hardware protection, location dependence, and automatic unlock, while in the trusted location. For the configuration steps, see Network Unlock.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4