mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-18 03:43:39 +00:00
updates
This commit is contained in:
@ -15,13 +15,13 @@ If it's believed that there's a risk in excluding a particular BCD setting from
|
||||
If the default BCD setting persistently triggers a recovery for benign changes, you can exclude that BCD setting from the validation coverage.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Devices with UEFI firmware can use secure boot to provide enhanced boot security. When BitLocker is able to use 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, the **[Use enhanced Boot Configuration Data validation profile](policy-settings.md?tabs=os#use-enhanced-boot-configuration-data-validation-profile)** policy is ignored.
|
||||
> Devices with UEFI firmware can use secure boot to provide enhanced boot security. When BitLocker is able to use 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, the **[Use enhanced Boot Configuration Data validation profile](configure.md?tabs=os#use-enhanced-boot-configuration-data-validation-profile)** policy is ignored.
|
||||
|
||||
One of the benefits of using secure boot is that it can correct BCD settings during boot without triggering recovery events. Secure boot enforces the same BCD settings as BitLocker. Secure boot BCD enforcement isn't configurable from within the operating system.
|
||||
|
||||
## Customize BCD validation settings
|
||||
|
||||
To modify the BCD settings that are validated by BitLocker, the administrator will add or exclude BCD settings from the platform validation profile by enabling and configuring the **[Use enhanced Boot Configuration Data validation profile](policy-settings.md?tabs=os#use-enhanced-boot-configuration-data-validation-profile)** policy setting.
|
||||
To modify the BCD settings that are validated by BitLocker, the administrator will add or exclude BCD settings from the platform validation profile by enabling and configuring the **[Use enhanced Boot Configuration Data validation profile](configure.md?tabs=os#use-enhanced-boot-configuration-data-validation-profile)** policy setting.
|
||||
|
||||
For the purposes of BitLocker validation, BCD settings are associated with a specific set of Microsoft boot applications. These BCD settings can also be applied to the other Microsoft boot applications that aren't part of the set to which the BCD settings are already applicable for. This setting can be done by attaching any of the following prefixes to the BCD settings that are being entered in the group policy settings dialog:
|
||||
|
||||
@ -38,7 +38,7 @@ You can quickly obtain the friendly name for the BCD settings on a computer by u
|
||||
|
||||
Not all BCD settings have friendly names. For those settings without a friendly name, the hex value is the only way to configure an exclusion policy.
|
||||
|
||||
When specifying BCD values in the **[Use enhanced Boot Configuration Data validation profile](policy-settings.md?tabs=os#use-enhanced-boot-configuration-data-validation-profile)** policy setting, use the following syntax:
|
||||
When specifying BCD values in the **[Use enhanced Boot Configuration Data validation profile](configure.md?tabs=os#use-enhanced-boot-configuration-data-validation-profile)** policy setting, use the following syntax:
|
||||
|
||||
- Prefix the setting with the boot application prefix
|
||||
- Append a colon `:`
|
||||
|
@ -16,7 +16,7 @@ To configure BitLocker, you can use one of the following options:
|
||||
> [!NOTE]
|
||||
> Windows Server doesn't support the configuration of BitLocker using CSP or Microsoft Configuration Manager. Use GPO instead.
|
||||
|
||||
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 reference article [BitLocker policy settings](policy-settings.md).
|
||||
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 reference article [BitLocker policy settings](configure.md).
|
||||
|
||||
[!INCLUDE [bitlocker](../../../../../includes/licensing/bitlocker-management.md)]
|
||||
|
||||
@ -41,7 +41,7 @@ To learn more about the Intune options to configure and monitor BitLocker, check
|
||||
To learn more about options to configure BitLocker via Microsoft Configuration Manager, see [Deploy BitLocker management](/mem/configmgr/protect/deploy-use/bitlocker/deploy-management-agent).
|
||||
|
||||
> [!TIP]
|
||||
> Organizations that image their device using Configuration Manager can use an existing task sequence to [pre-provision BitLocker](/configmgr/osd/understand/task-sequence-steps#BKMK_PreProvisionBitLocker) encryption while in Windows Preinstallation Environment (WinPE), and can then [enable protection](/configmgr/osd/understand/task-sequence-steps#BKMK_EnableBitLocker). These steps during an operating system deployment can help ensure that computers are encrypted from the start, even before users receive them. As part of the imaging process, an organization could also decide to use Configuration Manager to pre-set any desired [BitLocker policy settings](policy-settings.md).
|
||||
> Organizations that image their device using Configuration Manager can use an existing task sequence to [pre-provision BitLocker](/configmgr/osd/understand/task-sequence-steps#BKMK_PreProvisionBitLocker) encryption while in Windows Preinstallation Environment (WinPE), and can then [enable protection](/configmgr/osd/understand/task-sequence-steps#BKMK_EnableBitLocker). These steps during an operating system deployment can help ensure that computers are encrypted from the start, even before users receive them. As part of the imaging process, an organization could also decide to use Configuration Manager to pre-set any desired [BitLocker policy settings](configure.md).
|
||||
|
||||
## BitLocker policy settings
|
||||
|
||||
|
@ -46,11 +46,11 @@ On the other hand, Preboot authentication-prompts can be inconvenient to users.
|
||||
|
||||
To address these issues, [BitLocker Network Unlock](network-unlock.md) can be deployed. Network Unlock allows systems that meet the hardware requirements and have BitLocker enabled with TPM+PIN to boot into Windows without user intervention. It requires direct ethernet connectivity to a Windows Deployment Services (WDS) server.
|
||||
|
||||
To learn more, see the policy setting [Require additional authentication at startup](policy-settings.md?tabs=os#require-additional-authentication-at-startup).
|
||||
To learn more, see the policy setting [Require additional authentication at startup](configure.md?tabs=os#require-additional-authentication-at-startup).
|
||||
|
||||
### Protect DMA ports
|
||||
|
||||
It's important to protect DMA ports, as external peripherals may gain unauthorized access to memory. Depending on the device capabilities, there are different options to protect DMA ports. To learn more, see the policy setting [Disable new DMA devices when this computer is locked](policy-settings.md?tabs=common#disable-new-dma-devices-when-this-computer-is-locked).
|
||||
It's important to protect DMA ports, as external peripherals may gain unauthorized access to memory. Depending on the device capabilities, there are different options to protect DMA ports. To learn more, see the policy setting [Disable new DMA devices when this computer is locked](configure.md?tabs=common#disable-new-dma-devices-when-this-computer-is-locked).
|
||||
|
||||
## Attack countermeasures
|
||||
|
||||
@ -130,7 +130,7 @@ Mitigation:
|
||||
> [!IMPORTANT]
|
||||
> These settings are **not configured** by default.
|
||||
|
||||
For some systems, bypassing TPM-only may require opening the case, and may require soldering, but could possibly be done for a reasonable cost. Bypassing a TPM with a PIN protector would cost more, and require brute forcing the PIN. With a sophisticated enhanced PIN, it could be nearly impossible. To learn more about the policy setting, see [Allow enhanced PINs for startup](policy-settings.md?tabs=os#allow-enhanced-pins-for-startup).
|
||||
For some systems, bypassing TPM-only may require opening the case, and may require soldering, but could possibly be done for a reasonable cost. Bypassing a TPM with a PIN protector would cost more, and require brute forcing the PIN. With a sophisticated enhanced PIN, it could be nearly impossible. To learn more about the policy setting, see [Allow enhanced PINs for startup](configure.md?tabs=os#allow-enhanced-pins-for-startup).
|
||||
|
||||
For secure administrative workstations, it's recommended to:
|
||||
|
||||
|
@ -113,7 +113,7 @@ sections:
|
||||
|
||||
- question: How can I prevent users on a network from storing data on an unencrypted drive?
|
||||
answer: |
|
||||
Policy settings can be configured to require that data drives be BitLocker-protected before a BitLocker-protected computer can write data to them. For more info, see [BitLocker policy settings](policy-settings.md).
|
||||
Policy settings can be configured to require that data drives be BitLocker-protected before a BitLocker-protected computer can write data to them. For more info, see [BitLocker policy settings](configure.md).
|
||||
When these policy settings are enabled, the BitLocker-protected operating system will mount any data drives that aren't protected by BitLocker as read-only.
|
||||
|
||||
- question: |
|
||||
@ -217,7 +217,7 @@ sections:
|
||||
- question: When should an additional method of authentication be considered?
|
||||
answer: |
|
||||
New hardware that meets [Windows Hardware Compatibility Program](/windows-hardware/design/compatibility/) requirements make a PIN less critical as a mitigation, and having a TPM-only protector is likely sufficient when combined with policies like device lockout. For example, Surface Pro and Surface Book don't have external DMA ports to attack.
|
||||
For older hardware, where a PIN may be needed, it's recommended to enable [enhanced PINs](policy-settings.md) that allow non-numeric characters such as letters and punctuation marks, and to set the PIN length based on the risk tolerance and the hardware anti-hammering capabilities available to the TPMs on the computers.
|
||||
For older hardware, where a PIN may be needed, it's recommended to enable [enhanced PINs](configure.md) that allow non-numeric characters such as letters and punctuation marks, and to set the PIN length based on the risk tolerance and the hardware anti-hammering capabilities available to the TPMs on the computers.
|
||||
|
||||
- question: If I lose my recovery information, will the BitLocker-protected data be unrecoverable?
|
||||
answer: |
|
||||
@ -278,7 +278,7 @@ sections:
|
||||
answer: |
|
||||
The minimum personal identification number (PIN) length can be configured by using the **Configure minimum PIN length for startup** Group Policy setting and allow the use of alphanumeric PINs by enabling the **Allow enhanced PINs for startup** policy setting. PIN complexity can't be required via policy settings.
|
||||
|
||||
For more info, see [BitLocker policy settings](policy-settings.md).
|
||||
For more info, see [BitLocker policy settings](configure.md).
|
||||
|
||||
- question: How are the PIN and TPM used to derive the volume master key?
|
||||
answer: |
|
||||
@ -314,7 +314,7 @@ sections:
|
||||
answer: |
|
||||
If BitLocker is enabled on a drive before policy settings are applied to enforce a backup, the recovery information won't be automatically backed up to AD DS when the computer joins the domain or when the policy settings are subsequently applied. However, the policy settings **Choose how BitLocker-protected operating system drives can be recovered**, **Choose how BitLocker-protected fixed drives can be recovered**, and **Choose how BitLocker-protected removable drives can be recovered** can be chosen to require the computer to be connected to a domain before BitLocker can be enabled to help ensure that recovery information for BitLocker-protected drives in the organization is backed up to AD DS.
|
||||
|
||||
For more info, see [BitLocker policy settings](policy-settings.md).
|
||||
For more info, see [BitLocker policy settings](configure.md).
|
||||
|
||||
The BitLocker Windows Management Instrumentation (WMI) interface allows administrators to write a script to back up or synchronize an online client's existing recovery information. However, BitLocker doesn't automatically manage this process. The `manage-bde.exe` command-line tool can also be used to manually back up recovery information to AD DS. For example, to back up all of the recovery information for the `$env:SystemDrive` to AD DS, the following command script can be used from an elevated Command Prompt:
|
||||
|
||||
@ -348,7 +348,7 @@ sections:
|
||||
|
||||
When an administrator selects the **Do not enable BitLocker until recovery information is stored in AD DS for (operating system | fixed data | removable data) drives** check box in any of the **Choose how BitLocker-protected operating system drives can be recovered**, **Choose how BitLocker-protected fixed data drives can be recovered**, and **Choose how BitLocker-protected removable data drives can be recovered** policy settings, users can't enable BitLocker unless the computer is connected to the domain and the backup of BitLocker recovery information to AD DS succeeds. With these settings configured if the backup fails, BitLocker can't be enabled, ensuring that administrators will be able to recover BitLocker-protected drives in the organization.
|
||||
|
||||
For more info, see [BitLocker policy settings](policy-settings.md).
|
||||
For more info, see [BitLocker policy settings](configure.md).
|
||||
|
||||
When an administrator clears these check boxes, the administrator is allowing a drive to be BitLocker-protected without having the recovery information successfully backed up to AD DS; however, BitLocker won't automatically retry the backup if it fails. Instead, administrators can create a backup script, as described earlier in [What if BitLocker is enabled on a computer before the computer joins the domain?](#what-if-bitlocker-is-enabled-on-a-computer-before-the-computer-joins-the-domain-) to capture the information after connectivity is restored.
|
||||
|
||||
@ -367,7 +367,7 @@ sections:
|
||||
- question: |
|
||||
What are the implications of using the sleep or hibernate power management options?
|
||||
answer: |
|
||||
BitLocker on operating system drives in its basic configuration provides extra security for the hibernate mode. In sleep mode, the computer is vulnerable to direct memory access attacks, since unprotected data remains in RAM. Therefore, for improved security, it's recommended to disable sleep mode. Startup authentication can be configured by using a [policy setting](policy-settings.md).
|
||||
BitLocker on operating system drives in its basic configuration provides extra security for the hibernate mode. In sleep mode, the computer is vulnerable to direct memory access attacks, since unprotected data remains in RAM. Therefore, for improved security, it's recommended to disable sleep mode. Startup authentication can be configured by using a [policy setting](configure.md).
|
||||
|
||||
- question: |
|
||||
What are the advantages of a TPM?
|
||||
|
@ -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 |
|
||||
|--|--|
|
||||
|
@ -95,7 +95,7 @@ BitLocker has the following requirements:
|
||||
|
||||
Unlike a standard BitLocker implementation, device encryption is enabled automatically so that the device is always protected. When a clean installation of Windows is completed and the out-of-box experience is finished, the device is prepared for first use. As part of this preparation, device encryption is initialized on the OS drive and fixed data drives on the computer with a clear key that is the equivalent of standard BitLocker suspended state. In this state, the drive is shown with a warning icon in Windows Explorer. The yellow warning icon is removed after the TPM protector is created and the recovery key is backed up.
|
||||
|
||||
- If the device is Microsoft Entra joined or Active Directory domain joined, the clear key is removed once the recovery key is successfully backed up to Microsoft Entra ID or Active Directory Domain Services (AD DS). The following policy settings must be enabled for the recovery key to be backed up: [Choose how BitLocker-protected operating system drives can be recovered](policy-settings.md?tabs=os#choose-how-bitlocker-protected-operating-system-drives-can-be-recovered)
|
||||
- If the device is Microsoft Entra joined or Active Directory domain joined, the clear key is removed once the recovery key is successfully backed up to Microsoft Entra ID or Active Directory Domain Services (AD DS). The following policy settings must be enabled for the recovery key to be backed up: [Choose how BitLocker-protected operating system drives can be recovered](configure.md?tabs=os#choose-how-bitlocker-protected-operating-system-drives-can-be-recovered)
|
||||
- For Microsoft Entra joined devices: the recovery password is created automatically when the user authenticates to Microsoft Entra ID, then the recovery key is backed up to Microsoft Entra ID, the TPM protector is created, and the clear key is removed
|
||||
- For AD DS joined devices: the recovery password is created automatically when the computer joins the domain. The recovery key is then backed up to AD DS, the TPM protector is created, and the clear key is removed
|
||||
- If the device isn't Microsoft Entra joined or Active Directory domain joined, a Microsoft account with administrative privileges on the device is required. When the administrator uses a Microsoft account to sign in, the clear key is removed, a recovery key is uploaded to the online Microsoft account, and a TPM protector is created. Should a device require the recovery key, the user is guided to use an alternate device and navigate to a recovery key access URL to retrieve the recovery key by using their Microsoft account credentials
|
||||
|
@ -76,7 +76,7 @@ Copy the ID of the recovery password from the output.
|
||||
#### Backup the new recovery password to AD DS
|
||||
|
||||
> [!NOTE]
|
||||
>This step is not required if the policy setting [Choose how BitLocker-protected operating system drives can be recovered](policy-settings.md?tabs=os#choose-how-bitlocker-protected-operating-system-drives-can-be-recovered) is configured to **Require BitLocker backup to AD DS**.
|
||||
>This step is not required if the policy setting [Choose how BitLocker-protected operating system drives can be recovered](configure.md?tabs=os#choose-how-bitlocker-protected-operating-system-drives-can-be-recovered) is configured to **Require BitLocker backup to AD DS**.
|
||||
|
||||
Using the ID from the previous step, replace the `{ID}` in the following command:
|
||||
|
||||
|
@ -166,7 +166,7 @@ For more information about encrypted hard drives, see [Encrypted hard drive](../
|
||||
|
||||
## Microsoft Entra ID and Active Directory Domain Services considerations
|
||||
|
||||
BitLocker integrates with Microsoft Entra ID and Active Directory Domain Services (AD DS) to provide centralized key management. By default, no recovery information is backed up to Microsoft Entra ID or AD DS. Administrators can configure [policy setting](policy-settings.md?tabs=os#choose-how-bitlocker-protected-operating-system-drives-can-be-recovered) for each drive type to enable backup of BitLocker recovery information.
|
||||
BitLocker integrates with Microsoft Entra ID and Active Directory Domain Services (AD DS) to provide centralized key management. By default, no recovery information is backed up to Microsoft Entra ID or AD DS. Administrators can configure [policy setting](configure.md?tabs=os#choose-how-bitlocker-protected-operating-system-drives-can-be-recovered) for each drive type to enable backup of BitLocker recovery information.
|
||||
|
||||
The following recovery data is saved for each computer object:
|
||||
|
||||
@ -205,4 +205,4 @@ Organizations can use Microsoft Intune or Configuration Manager to monitor and m
|
||||
> Learn about the available options to configure BitLocker and how to configure them via Configuration Service Providers (CSP) or group policy (GPO).
|
||||
>
|
||||
>
|
||||
> [Configure BitLocker >](countermeasures.md)
|
||||
> [Configure BitLocker >](configure.md)
|
||||
|
@ -46,7 +46,7 @@ With BitLocker policy settings, you can configure a custom recovery message and
|
||||
:::column-end:::
|
||||
:::row-end:::
|
||||
|
||||
For more information how to configure a custom recovery message with policy settings, see [Configure preboot recovery message and URL](policy-settings.md?tabs=os#configure-preboot-recovery-message-and-url).
|
||||
For more information how to configure a custom recovery message with policy settings, see [Configure preboot recovery message and URL](configure.md?tabs=os#configure-preboot-recovery-message-and-url).
|
||||
|
||||
## Recovery key hints
|
||||
|
||||
|
@ -21,9 +21,9 @@ BitLocker recovery is the process by which access to a BitLocker-protected drive
|
||||
- The user can supply a *recovery password*: if the organization allows users to print or store recovery passwords, the users can enter the 48-digit recovery password
|
||||
- *Data recovery agents* can use their credentials to unlock the drive: if the drive is an operating system drive, the drive must be mounted as a data drive on another device for the data recovery agent to unlock it
|
||||
- An administrator can obtain the *recovery password* from Microsoft Entra ID or AD DS and use it to unlock the drive. Storing recovery passwords in Microsoft Entra ID or AD DS is recommended to provide a way to obtain recovery passwords for drives in an organization if needed. This method requires to enable the policy settings:
|
||||
- [Choose how BitLocker-protected operating system drives can be recovered](policy-settings.md?tabs=os#choose-how-bitlocker-protected-operating-system-drives-can-be-recovered)
|
||||
- [Choose how BitLocker-protected fixed drives can be recovered](policy-settings.md?tabs=fixed#choose-how-bitlocker-protected-fixed-drives-can-be-recovered)
|
||||
- [Choose how BitLocker-protected removable drives can be recovered](policy-settings.md?tabs=removable#choose-how-bitlocker-protected-removable-drives-can-be-recovered)
|
||||
- [Choose how BitLocker-protected operating system drives can be recovered](configure.md?tabs=os#choose-how-bitlocker-protected-operating-system-drives-can-be-recovered)
|
||||
- [Choose how BitLocker-protected fixed drives can be recovered](configure.md?tabs=fixed#choose-how-bitlocker-protected-fixed-drives-can-be-recovered)
|
||||
- [Choose how BitLocker-protected removable drives can be recovered](configure.md?tabs=removable#choose-how-bitlocker-protected-removable-drives-can-be-recovered)
|
||||
|
||||
## What causes BitLocker recovery?
|
||||
|
||||
@ -105,9 +105,9 @@ In some cases, users might have the recovery password in a printout or a USB fla
|
||||
If the user doesn't have a recovery password printed or on a USB flash drive, the user will need to be able to retrieve the recovery password from an online source. If the PC is a member of a domain, the recovery password can be backed up to AD DS. **However, back up of the recovery password to AD DS does not happen by default.** Backup of the recovery password to AD DS has to be configured via the appropriate group policy settings **before** BitLocker was enabled on the PC. BitLocker group policy settings can be found in the Local Group Policy Editor or the Group Policy Management Console (GPMC) under **Computer Configuration** > **Administrative Templates** > **Windows Components** > **BitLocker Drive Encryption**. The following policy settings define the recovery methods that can be used to restore access to a BitLocker-protected drive if an authentication method fails or is unable to be used.
|
||||
|
||||
This method requires to enable the policy settings:
|
||||
- [Choose how BitLocker-protected operating system drives can be recovered](policy-settings.md?tabs=os#choose-how-bitlocker-protected-operating-system-drives-can-be-recovered)
|
||||
- [Choose how BitLocker-protected fixed drives can be recovered](policy-settings.md?tabs=fixed#choose-how-bitlocker-protected-fixed-drives-can-be-recovered)
|
||||
- [Choose how BitLocker-protected removable drives can be recovered](policy-settings.md?tabs=removable#choose-how-bitlocker-protected-removable-drives-can-be-recovered)
|
||||
- [Choose how BitLocker-protected operating system drives can be recovered](configure.md?tabs=os#choose-how-bitlocker-protected-operating-system-drives-can-be-recovered)
|
||||
- [Choose how BitLocker-protected fixed drives can be recovered](configure.md?tabs=fixed#choose-how-bitlocker-protected-fixed-drives-can-be-recovered)
|
||||
- [Choose how BitLocker-protected removable drives can be recovered](configure.md?tabs=removable#choose-how-bitlocker-protected-removable-drives-can-be-recovered)
|
||||
|
||||
In each of these policies, select **Save BitLocker recovery information to Active Directory Domain Services** and then choose which BitLocker recovery information to store in AD DS. Check the **Do not enable BitLocker until recovery information is stored in AD
|
||||
DS** check box if it's desired to prevent users from enabling BitLocker unless the computer is connected to the domain and the backup of BitLocker recovery information for the drive to AD DS succeeds.
|
||||
|
Reference in New Issue
Block a user