mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-19 04:13:41 +00:00
updates
This commit is contained in:
Paolo Matarazzo
@ -14,10 +14,10 @@ Secure Boot ensures that the device's preboot environment only loads firmware th
|
||||
- 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-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.
|
||||
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](../configure.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.
|
||||
> If the policy setting *[Configure TPM platform validation profile for native UEFI firmware configurations](../configure.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.
|
||||
|
||||
@ -7,10 +7,10 @@ ms.topic: include
|
||||
|
||||
### Allow standard user encryption
|
||||
|
||||
With this policy you can enforce the [*Require device encryption*](../policy-settings.md?tabs=os#require-device-encryption) policy for scenarios where the policy is applied while the current logged-on user doesn't have administrative rights.
|
||||
With this policy you can enforce the [*Require device encryption*](../configure.md?tabs=os#require-device-encryption) policy for scenarios where the policy is applied while the current logged-on user doesn't have administrative rights.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> The [Allow warning for other disk encryption](../policy-settings.md?tabs=os#allow-warning-for-other-disk-encryption) policy must be disabled to allow standard user encryption.
|
||||
> The [Allow warning for other disk encryption](../configure.md?tabs=os#allow-warning-for-other-disk-encryption) policy must be disabled to allow standard user encryption.
|
||||
|
||||
| | Path |
|
||||
|--|--|
|
||||
|
||||
@ -12,7 +12,7 @@ With this policy you can disable all notification for encryption, warning prompt
|
||||
> [!IMPORTANT]
|
||||
> This policy applies to Microsoft Entra joined devices only.
|
||||
|
||||
This policy takes effect only if [Require device encryption](../policy-settings.md?tabs=os#require-device-encryption) policy is enabled.
|
||||
This policy takes effect only if [Require device encryption](../configure.md?tabs=os#require-device-encryption) policy is enabled.
|
||||
|
||||
> [!WARNING]
|
||||
> When you enable BitLocker on a device with third party encryption, it may render the device unusable and will require reinstallation of Windows.
|
||||
|
||||
@ -12,7 +12,7 @@ This policy configures a minimum length for a Trusted Platform Module (TPM) star
|
||||
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](../../../../hardware-security/tpm/trusted-platform-module-services-group-policy-settings.md) 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 TPM can be configured to use Dictionary Attack Prevention parameters ([lockout threshold and lockout duration](../../../../hardware-security/tpm/trusted-platform-module-services-group-configure.md) 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.
|
||||
|
||||
|
||||
@ -13,7 +13,7 @@ This policy setting determines what values the TPM measures when it validates ea
|
||||
- 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-settings.md?tabs=os#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.
|
||||
> 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](../configure.md?tabs=os#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:
|
||||
|
||||
@ -51,7 +51,7 @@ 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-settings.md?tabs=os#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 with PCR 7 omitted, overrides the *[Allow Secure Boot for integrity validation](../configure.md?tabs=os#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.
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ ms.topic: include
|
||||
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`.
|
||||
- The allowed identification field is used in combination with the *[Deny write access to removable drives not protected by BitLocker](../configure.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.
|
||||
|
||||
|
||||
@ -9,11 +9,11 @@ ms.topic: include
|
||||
|
||||
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-settings.md?tabs=os#allow-warning-for-other-disk-encryption) policy
|
||||
- If enabled, encryption is triggered on all drives silently or non-silently based on [Allow warning for other disk encryption](../configure.md?tabs=os#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.
|
||||
|
||||
> [!NOTE]
|
||||
> Typically, BitLocker follows the [Choose drive encryption method and cipher strength](../policy-settings.md?tabs=os#choose-drive-encryption-method-and-cipher-strength) policy configuration. However, this policy setting will be ignored for self-encrypting fixed drives and self-encrypting OS drives.
|
||||
> Typically, BitLocker follows the [Choose drive encryption method and cipher strength](../configure.md?tabs=os#choose-drive-encryption-method-and-cipher-strength) policy configuration. However, this policy setting will be ignored for self-encrypting fixed drives and self-encrypting OS drives.
|
||||
|
||||
Encryptable fixed data volumes are treated similarly to OS volumes, but they must meet other criteria to be encryptable:
|
||||
|
||||
@ -25,7 +25,7 @@ Encryptable fixed data volumes are treated similarly to OS volumes, but they mus
|
||||
- It must not have a reference in the BCD store
|
||||
|
||||
> [!NOTE]
|
||||
> Only full disk encryption is supported when using this policy for silent encryption. For non-silent encryption, encryption type will depend on the [*Enforce drive encryption type on operating system drives*](../policy-settings.md?tabs=fixed#enforce-drive-encryption-type-on-operating-system-drives) and [*Enforce drive encryption type on fixed data drives*](../policy-settings.md?tabs=fixed#enforce-drive-encryption-type-on-fixed-data-drives) policies configured on the device.
|
||||
> Only full disk encryption is supported when using this policy for silent encryption. For non-silent encryption, encryption type will depend on the [*Enforce drive encryption type on operating system drives*](../configure.md?tabs=fixed#enforce-drive-encryption-type-on-operating-system-drives) and [*Enforce drive encryption type on fixed data drives*](../configure.md?tabs=fixed#enforce-drive-encryption-type-on-fixed-data-drives) policies configured on the device.
|
||||
|
||||
| | Path |
|
||||
|--|--|
|
||||
|
||||
@ -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](../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.
|
||||
> When BitLocker is using Secure Boot for platform and BCD integrity validation, as defined by the *[Allow Secure Boot for integrity validation](../configure.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 |
|
||||
|--|--|
|
||||
|
||||
Reference in New Issue
Block a user