This commit is contained in:
Paolo Matarazzo
2023-09-28 17:14:25 -04:00
parent 650e50712b
commit 1602ef7d91
10 changed files with 48 additions and 107 deletions

View File

@ -7,7 +7,20 @@ ms.topic: include
### Allow Secure Boot for integrity validation
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 whether Secure Boot is allowed as the platform integrity provider for BitLocker operating system drives.
Secure Boot ensures that the device's pre-boot 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 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](../policy-settings.md?tabs=os#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.
> [!NOTE]
> If the policy setting *[Configure TPM platform validation profile for native UEFI firmware configurations](../policy-settings.md?tabs=os#configure-tpm-platform-validation-profile-for-native-uefi-firmware-configurations)* is enabled and has PCR 7 omitted, BitLocker is prevented from using Secure Boot for platform or Boot Configuration Data (BCD) integrity validation.
> [!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.
| | Path |
|--|--|

View File

@ -7,7 +7,14 @@ ms.topic: include
### Configure pre-boot recovery message and URL
This policy setting lets you configure the entire recovery message or replace the existing URL that are displayed on the pre-boot key 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 will be displayed in the pre-boot 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 type in the "Custom recovery message option" text box will be displayed in the pre-boot 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 type in the "Custom recovery URL option" text box will replace the default URL in the default recovery message, which will be displayed in the pre-boot 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.
This policy setting is used to configure the recovery message and to replace the existing URL that is displayed on the pre-boot 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 pre-boot 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 pre-boot 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 pre-boot 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.
| | Path |
|--|--|

View File

@ -6,7 +6,14 @@ ms.topic: include
---
### Prevent memory overwrite on restart
This policy setting controls computer restart performance at the risk of exposing BitLocker secrets. BitLocker secrets include key material used to encrypt data. This policy setting applies only when BitLocker protection is enabled. If you enable this policy setting, memory will not be overwritten when the computer restarts. Preventing memory overwrite may improve restart performance but will increase 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.
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.
| | Path |
|--|--|

View File

@ -7,7 +7,17 @@ ms.topic: include
### Provide the unique identifiers for your organization
This policy setting allows you to associate unique organizational identifiers to a new drive that is enabled with BitLocker. These 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 manage-bde command-line tool. An identification field is required for management of certificate-based data recovery agents on BitLocker-protected drives and for potential updates to the BitLocker To Go Reader. BitLocker will only manage and update data recovery agents when the identification field on the drive matches the value configured in the identification field. In a similar manner, BitLocker will only update the BitLocker To Go Reader when the identification field on the drive matches the value configured for the identification field. 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 is 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 computer the identification field and allowed identification field will be used to determine whether the drive is from an outside organization. If you disable or do not configure this policy setting, the identification field is not required. Note: Identification fields are required for management of certificate-based data recovery agents on BitLocker-protected drives. BitLocker will only manage and update certificate-based data recovery agents when the identification field is present on a drive and is identical to the value configured on the computer. The identification field can be any value of 260 characters or fewer.
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-settings.md?tabs=removable##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.
| | Path |
|--|--|

View File

@ -12,7 +12,7 @@ This policy setting determines specific Boot Configuration Data (BCD) settings t
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* GPO, 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.
> When BitLocker is using Secure Boot for platform and BCD integrity validation, as defined by the *[Allow Secure Boot for integrity validation](../policy-settings.md?tabs=os#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.
| | Path |
|--|--|