mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-15 18:33:43 +00:00
acrolinx
This commit is contained in:
Paolo Matarazzo
@ -98,7 +98,7 @@ The following table defines which Windows features require TPM support.
|
||||
Windows Features | TPM Required | Supports TPM 1.2 | Supports TPM 2.0 | Details |
|
||||
-|-|-|-|-
|
||||
Measured Boot | Yes | Yes | Yes | Measured Boot requires TPM 1.2 or 2.0 and UEFI Secure Boot. TPM 2.0 is recommended since it supports newer cryptographic algorithms. TPM 1.2 only supports the SHA-1 algorithm which is being deprecated.
|
||||
BitLocker | No | Yes | Yes | TPM 1.2 or 2.0 are supported but TPM 2.0 is recommended. [Automatic Device Encryption requires Modern Standby](../../operating-system-security/data-protection/bitlocker/bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption) including TPM 2.0 support
|
||||
BitLocker | No | Yes | Yes | TPM 1.2 or 2.0 are supported but TPM 2.0 is recommended. [Automatic Device Encryption requires Modern Standby](../../operating-system-security/data-protection/bitlocker/bitlocker-device-encryption.md#bitlocker-device-encryption) including TPM 2.0 support
|
||||
Device Encryption | Yes | N/A | Yes | Device Encryption requires Modern Standby/Connected Standby certification, which requires TPM 2.0.
|
||||
Windows Defender Application Control (Device Guard) | No | Yes | Yes
|
||||
Windows Defender System Guard (DRTM) | Yes | No | Yes | TPM 2.0 and UEFI firmware is required.
|
||||
|
||||
@ -24,11 +24,11 @@ Enterprises can use [Microsoft BitLocker Administration and Monitoring (MBAM)](/
|
||||
|
||||
## Managing devices joined to Azure Active Directory
|
||||
|
||||
Devices joined to Azure AD are managed using Mobile Device Management (MDM) policy from an MDM solution such as Microsoft Intune. Prior to Windows 10, version 1809, only local administrators can enable BitLocker via Intune policy. Starting with Windows 10, version 1809, Intune can enable BitLocker for standard users. [BitLocker Device Encryption](bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption) status can be queried from managed machines via the [Policy Configuration Settings Provider (CSP)](/windows/client-management/mdm/policy-configuration-service-provider/), which reports on whether BitLocker Device Encryption is enabled on the device. Compliance with BitLocker Device Encryption policy can be a requirement for [Conditional Access](https://www.microsoft.com/cloud-platform/conditional-access/) to services like Exchange Online and SharePoint Online.
|
||||
Devices joined to Azure AD are managed using Mobile Device Management (MDM) policy from an MDM solution such as Microsoft Intune. Prior to Windows 10, version 1809, only local administrators can enable BitLocker via Intune policy. Starting with Windows 10, version 1809, Intune can enable BitLocker for standard users. [BitLocker Device Encryption](bitlocker-device-encryption.md) status can be queried from managed machines via the [Policy Configuration Settings Provider (CSP)](/windows/client-management/mdm/policy-configuration-service-provider/), which reports on whether BitLocker Device Encryption is enabled on the device. Compliance with BitLocker Device Encryption policy can be a requirement for [Conditional Access](https://www.microsoft.com/cloud-platform/conditional-access/) to services like Exchange Online and SharePoint Online.
|
||||
|
||||
Starting with Windows 10 version 1703, the enablement of BitLocker can be triggered over MDM either by the [Policy CSP](/windows/client-management/mdm/policy-configuration-service-provider/) or the [BitLocker CSP](/windows/client-management/mdm/bitlocker-csp/). The BitLocker CSP adds policy options that go beyond ensuring that encryption has occurred, and is available on computers that run Windows 11, Windows 10, and on Windows phones.
|
||||
|
||||
For hardware that is compliant with Modern Standby and HSTI, when using either of these features, [BitLocker Device Encryption](bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption) is automatically turned on whenever the user joins a device to Azure AD. Azure AD provides a portal where recovery keys are also backed up, so users can retrieve their own recovery key for self-service, if necessary. For older devices that aren't yet encrypted, beginning with Windows 10 version 1703, admins can use the [BitLocker CSP](/windows/client-management/mdm/bitlocker-csp/) to trigger encryption and store the recovery key in Azure AD. This process and feature is applicable to Azure Hybrid AD as well.
|
||||
For hardware that is compliant with Modern Standby and HSTI, when using either of these features, [BitLocker Device Encryption](bitlocker-device-encryption.md) is automatically turned on whenever the user joins a device to Azure AD. Azure AD provides a portal where recovery keys are also backed up, so users can retrieve their own recovery key for self-service, if necessary. For older devices that aren't yet encrypted, beginning with Windows 10 version 1703, admins can use the [BitLocker CSP](/windows/client-management/mdm/bitlocker-csp/) to trigger encryption and store the recovery key in Azure AD. This process and feature is applicable to Azure Hybrid AD as well.
|
||||
|
||||
## Managing workplace-joined PCs and phones
|
||||
|
||||
@ -91,7 +91,7 @@ Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -UsedSpaceOnly -Pi
|
||||
|
||||
- [BitLocker: FAQs](faq.yml)
|
||||
- [Microsoft BitLocker Administration and Management (MBAM)](/microsoft-desktop-optimization-pack/mbam-v25/)
|
||||
- [Overview of BitLocker Device Encryption in Windows](bitlocker-device-encryption-overview-windows-10.md#bitlocker-device-encryption)
|
||||
- [Overview of BitLocker Device Encryption](bitlocker-device-encryption.md)
|
||||
- [BitLocker policy settings](policy-settings.md)
|
||||
- [Microsoft Intune](https://www.microsoft.com/cloud-platform/microsoft-intune/)
|
||||
*(Overview)*
|
||||
|
||||
@ -32,7 +32,7 @@ BitLocker recovery is the process by which access can be restored to a BitLocker
|
||||
|
||||
The following list provides examples of specific events that will cause BitLocker to enter recovery mode when attempting to start the operating system drive:
|
||||
|
||||
- On PCs that use BitLocker Drive Encryption, or on devices such as tablets or phones that use [BitLocker Device Encryption](bitlocker-device-encryption-overview-windows-10.md) only, when an attack is detected, the device will immediately reboot and enter into BitLocker recovery mode. To take advantage of this functionality, administrators can set the **Interactive logon: Machine account lockout threshold** Group Policy setting located in **Computer Configuration** > **Windows Settings** > **Security Settings** > **Local Policies** > **Security Options** in the Local Group Policy Editor. Or they can use the **MaxFailedPasswordAttempts** policy of [Exchange ActiveSync](/Exchange/clients/exchange-activesync/exchange-activesync) (also configurable through [Microsoft Intune](/mem/intune)), to limit the number of failed password attempts before the device goes into Device Lockout.
|
||||
- On devices that use BitLocker drive encryption or [BitLocker Device Encryption](bitlocker-device-encryption.md), when an attack is detected the device will reboot and enter into BitLocker recovery mode. To take advantage of this functionality, administrators can set the **Interactive logon: Machine account lockout threshold** Group Policy setting located in **Computer Configuration** > **Windows Settings** > **Security Settings** > **Local Policies** > **Security Options** in the Local Group Policy Editor. Or they can use the **MaxFailedPasswordAttempts** policy of [Exchange ActiveSync](/Exchange/clients/exchange-activesync/exchange-activesync) (also configurable through [Microsoft Intune](/mem/intune)), to limit the number of failed password attempts before the device goes into Device Lockout.
|
||||
|
||||
- On devices with TPM 1.2, changing the BIOS or firmware boot device order causes BitLocker recovery. However, devices with TPM 2.0 don't start BitLocker recovery in this case. TPM 2.0 doesn't consider a firmware change of boot device order as a security threat because the OS Boot Loader isn't compromised.
|
||||
|
||||
@ -307,7 +307,7 @@ This error occurs if the firmware is updated. As a best practice, BitLocker shou
|
||||
|
||||
## Windows RE and BitLocker Device Encryption
|
||||
|
||||
Windows Recovery Environment (RE) can be used to recover access to a drive protected by [BitLocker Device Encryption](bitlocker-device-encryption-overview-windows-10.md). If a PC is unable to boot after two failures, Startup Repair automatically starts. When Startup Repair is launched automatically due to boot failures, it executes only operating system and driver file repairs if the boot logs or any available crash dump points to a specific corrupted file. In Windows 8.1 and later versions, devices that include firmware to support specific TPM measurements for PCR\[7\] **the TPM** can validate that Windows RE is a trusted operating environment and unlock any BitLocker-protected drives if Windows RE hasn't been modified. If the Windows RE environment has been modified, for example, the TPM has been disabled, the drives stay locked until the BitLocker recovery key is provided. If Startup Repair isn't able to run automatically from the PC and instead, Windows RE is manually started from a repair disk, the BitLocker recovery key must be provided to unlock the BitLocker-protected drives.
|
||||
Windows Recovery Environment (RE) can be used to recover access to a drive protected by [BitLocker Device Encryption](bitlocker-device-encryption.md). If a device is unable to boot after two failures, Startup Repair automatically starts. When Startup Repair is launched automatically due to boot failures, it executes only operating system and driver file repairs if the boot logs or any available crash dump points to a specific corrupted file. Devices that include firmware to support specific TPM measurements for *PCR 7*, the TPM can validate that Windows RE is a trusted operating environment and unlock any BitLocker-protected drives if Windows RE hasn't been modified. If the Windows RE environment has been modified, for example, the TPM has been disabled, the drives stay locked until the BitLocker recovery key is provided. If Startup Repair isn't able to run automatically from the PC and instead, Windows RE is manually started from a repair disk, the BitLocker recovery key must be provided to unlock the BitLocker-protected drives.
|
||||
|
||||
Windows RE will also ask for a BitLocker recovery key when a **Remove everything** reset from Windows RE is started on a device that uses **TPM + PIN** or **Password for OS drive** protectors. If BitLocker recovery is started on a keyboardless device with TPM-only protection, Windows RE, not the boot manager, will ask for the BitLocker recovery key. After the key is entered, Windows RE troubleshooting tools can be accessed, or Windows can be started normally.
|
||||
|
||||
|
||||
@ -128,7 +128,7 @@ sections:
|
||||
|
||||
- question: What is Used Disk Space Only encryption?
|
||||
answer: |
|
||||
BitLocker in Windows 10 lets users choose to encrypt just their data. Although it's not the most secure way to encrypt a drive, this option can reduce encryption time by more than 99 percent, depending on how much data that needs to be encrypted. For more information, see [Used Disk Space Only encryption](bitlocker-device-encryption-overview-windows-10.md#used-disk-space-only-encryption).
|
||||
BitLocker in Windows 10 lets users choose to encrypt just their data. Although it's not the most secure way to encrypt a drive, this option can reduce encryption time by more than 99 percent, depending on how much data that needs to be encrypted. For more information, see [Used Disk Space Only encryption](bitlocker-device-encryption.md#used-disk-space-only-encryption).
|
||||
|
||||
- question: What system changes would cause the integrity check on my operating system drive to fail?
|
||||
answer: |
|
||||
|
||||
@ -6,9 +6,11 @@ ms.topic: include
|
||||
---
|
||||
|
||||
|
||||
### Allow devices compliant with InstantGo or HSTI to opt out of pre-boot PIN
|
||||
### Allow devices compliant with InstantGo or HSTI to opt out of preboot PIN
|
||||
|
||||
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 pre-boot authentication. This overrides the *Require startup PIN with TPM* and *Require startup key and PIN with TPM* options of the [*Require additional authentication at startup*](#require-additional-authentication-at-startup) policy on compliant hardware. If you enable this policy setting, users on InstantGo and HSTI compliant devices have the choice to turn on BitLocker without pre-boot authentication. If this policy is not enabled, the options of *Require additional authentication at startup* policy apply.
|
||||
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. This overrides the *Require startup PIN with TPM* and *Require startup key and PIN with TPM* options of the [*Require additional authentication at startup*](#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 this policy isn't enabled, the options of [*Require additional authentication at startup*](#require-additional-authentication-at-startup) policy apply.
|
||||
|
||||
| | Path |
|
||||
|--|--|
|
||||
|
||||
@ -9,16 +9,16 @@ ms.topic: include
|
||||
|
||||
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* will be able to 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.
|
||||
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 cannot create Network Key Protectors to automatically unlock with Network Unlock.
|
||||
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 do not configure this policy setting, BitLocker clients will not be able to create and use Network Key Protectors.
|
||||
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](bitlocker-how-to-enable-network-unlock.md)
|
||||
For more information about Network Unlock feature, see [BitLocker: How to enable Network Unlock](../bitlocker-how-to-enable-network-unlock.md)
|
||||
|
||||
| | Path |
|
||||
|--|--|
|
||||
|
||||
@ -9,10 +9,10 @@ ms.topic: include
|
||||
|
||||
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.
|
||||
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 will use legacy platform integrity validation, even on systems 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.
|
||||
|
||||
|
||||
@ -9,8 +9,8 @@ ms.topic: include
|
||||
|
||||
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 is not valid, the BitLocker setup wizard will display the computer's top-level folder view
|
||||
- If you disable or do not configure this policy setting, the BitLocker setup wizard will display the computer's top-level folder view when the user chooses the option to save the recovery password in a folder
|
||||
- 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.
|
||||
|
||||
@ -5,13 +5,13 @@ ms.date: 09/24/2023
|
||||
ms.topic: include
|
||||
---
|
||||
|
||||
### Configure pre-boot recovery message and URL
|
||||
### Configure preboot recovery message and URL
|
||||
|
||||
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.
|
||||
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 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
|
||||
- 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.
|
||||
|
||||
@ -7,19 +7,13 @@ ms.topic: include
|
||||
|
||||
### Configure TPM platform validation profile for native UEFI firmware configurations
|
||||
|
||||
This policy setting determines what values the TPM measures when it validates early boot components before unlocking an operating system drive on a computer with native UEFI firmware configurations.
|
||||
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 will validate before unlocking access to the BitLocker-encrypted operating system drive. If any of these components change while BitLocker protection is in effect, the TPM will not release the encryption key to unlock the drive and the computer will instead display the BitLocker Recovery console and require that either the recovery password or recovery key be provided to unlock the drive
|
||||
- If you disable or do not configure this policy setting, BitLocker uses the default platform validation profile for the available hardware or the platform validation profile specified by the setup script
|
||||
|
||||
|**Conflicts**|Setting this policy with PCR 7 omitted overrides the **Allow Secure Boot for integrity validation** Group Policy setting, and it prevents BitLocker from using Secure Boot for platform or Boot Configuration Data (BCD) integrity validation. <BR><BR> If an environment uses TPM and Secure Boot for platform integrity checks, this policy is configured. <BR><BR> For more information about PCR 7, see [About the Platform Configuration Register (PCR)](#about-the-platform-configuration-register-pcr) in this article.|
|
||||
|
||||
#### Reference: Configure TPM platform validation profile for native UEFI firmware configurations
|
||||
|
||||
This policy setting doesn't apply if the computer doesn't have a compatible TPM or if BitLocker is already turned on with TPM protection.
|
||||
- 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 group policy setting only applies to computers 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** Group Policy setting to configure the TPM PCR profile for computers with BIOS configurations or for computers 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](../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.
|
||||
|
||||
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:
|
||||
|
||||
@ -55,13 +49,13 @@ The following list identifies all of the available PCRs:
|
||||
| PCR 15 - 23 | Reserved for future use
|
||||
|
||||
> [!WARNING]
|
||||
> 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.
|
||||
> 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, will override 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 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 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 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](/windows-hardware/test/hlk/testref/trusted-execution-environment-efi-protocol).
|
||||
|
||||
|
||||
@ -14,13 +14,13 @@ This policy setting specifies whether a password is required to unlock BitLocker
|
||||
|
||||
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** connection to a domain controller will be attempted to validate the complexity adheres to the rules set by the policy, but if no domain controllers are found the password will still be accepted regardless of actual password complexity and the drive will be encrypted using that password as a protector
|
||||
- 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 8 characters. To configure a greater minimum length for the password, specify the desired number of characters under **Minimum password length**
|
||||
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 do not configure this policy setting, the default length constraint of 8 characters applies to operating system drive passwords and no complexity checks occur.
|
||||
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.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Passwords can't be used if FIPS-compliance is enabled.
|
||||
|
||||
@ -14,13 +14,13 @@ This policy setting specifies the constraints for passwords used to unlock BitLo
|
||||
|
||||
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** connection to a domain controller will be attempted to validate the complexity adheres to the rules set by the policy, but if no domain controllers are found the password will still be accepted regardless of actual password complexity and the drive will be encrypted using that password as a protector
|
||||
- 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 8 characters. To configure a greater minimum length for the password, specify the desired number of characters under **Minimum password length**
|
||||
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 do not configure this policy setting, the default length constraint of 8 characters applies to operating system drive passwords and no complexity checks occur.
|
||||
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.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Passwords can't be used if FIPS-compliance is enabled.
|
||||
|
||||
@ -14,13 +14,13 @@ This policy setting specifies whether a password is required to unlock BitLocker
|
||||
|
||||
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** connection to a domain controller will be attempted to validate the complexity adheres to the rules set by the policy, but if no domain controllers are found the password will still be accepted regardless of actual password complexity and the drive will be encrypted using that password as a protector
|
||||
- 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 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 do not configure this policy setting, the default length constraint of 8 characters applies to operating system drive passwords and no complexity checks occur.
|
||||
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.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Passwords can't be used if FIPS-compliance is enabled.
|
||||
|
||||
@ -10,7 +10,7 @@ ms.topic: include
|
||||
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 do not configure this policy, standard users can change BitLocker PINs and passwords.
|
||||
If you disable or don't configure this policy, standard users can change BitLocker PINs and passwords.
|
||||
|
||||
| | Path |
|
||||
|--|--|
|
||||
|
||||
@ -7,14 +7,14 @@ ms.topic: include
|
||||
|
||||
### Enable use of BitLocker authentication requiring preboot keyboard input on slates
|
||||
|
||||
This policy setting allows users to turn on authentication options that require user input from the pre-boot environment, even if the platform lacks pre-boot input capability. The Windows touch keyboard (such as that used by tablets) isn't available in the pre-boot environment where BitLocker requires additional information such as a PIN or Password.
|
||||
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 pre-boot input (such as an attached USB keyboard).
|
||||
- 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 the Windows touch 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:
|
||||
|
||||
|
||||
@ -9,17 +9,17 @@ ms.topic: include
|
||||
|
||||
This policy setting controls the use of BitLocker on fixed data drives.
|
||||
|
||||
If you enable this policy setting the encryption type that BitLocker will use to encrypt drives is defined by this policy and the encryption type option will not be presented in the BitLocker setup wizard:
|
||||
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 will ask the user to select the encryption type before turning on BitLocker.
|
||||
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 as it would be for 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 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.
|
||||
|
||||
| | Path |
|
||||
|--|--|
|
||||
|
||||
@ -9,17 +9,17 @@ ms.topic: include
|
||||
|
||||
This policy setting allows you to configure the encryption type used by BitLocker Drive Encryption.
|
||||
|
||||
If you enable this policy setting the encryption type that BitLocker will use to encrypt drives is defined by this policy and the encryption type option will not be presented in the BitLocker setup wizard:
|
||||
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 will ask the user to select the encryption type before turning on BitLocker.
|
||||
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 as it would be for 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 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.
|
||||
|
||||
| | Path |
|
||||
|--|--|
|
||||
|
||||
@ -9,17 +9,17 @@ ms.topic: include
|
||||
|
||||
This policy setting controls the use of BitLocker on removable data drives.
|
||||
|
||||
If you enable this policy setting the encryption type that BitLocker will use to encrypt drives is defined by this policy and the encryption type option will not be presented in the BitLocker setup wizard:
|
||||
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 will ask the user to select the encryption type before turning on BitLocker.
|
||||
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 as it would be for 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 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.
|
||||
|
||||
| | Path |
|
||||
|--|--|
|
||||
|
||||
@ -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](../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.
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ ms.topic: include
|
||||
|
||||
### Require additional authentication at startup
|
||||
|
||||
This policy configures whether BitLocker requires additional authentication each time the device starts.
|
||||
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.
|
||||
@ -16,7 +16,7 @@ If you disable or don't configure this policy setting, users can configure only
|
||||
> 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'll need to use one of the BitLocker recovery options to access the drive.
|
||||
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:
|
||||
|
||||
@ -33,22 +33,22 @@ There are four options for TPM-enabled devices:
|
||||
- Configure TPM startup
|
||||
- Allow TPM
|
||||
- Require TPM
|
||||
- Do not allow TPM
|
||||
- Don't allow TPM
|
||||
|
||||
- Configure TPM startup PIN
|
||||
- Allow startup PIN with TPM
|
||||
- Require startup PIN with TPM
|
||||
- Do not allow 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
|
||||
- Do not allow 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
|
||||
- Do not allow TPM startup key with PIN
|
||||
- Don't allow TPM startup key with PIN
|
||||
|
||||
| | Path |
|
||||
|--|--|
|
||||
|
||||
@ -9,10 +9,10 @@ ms.topic: include
|
||||
|
||||
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 will be refreshed when Windows is started following BitLocker recovery. This is the default behavior.\
|
||||
If you disable this policy setting, platform validation data will not be refreshed when Windows is started following BitLocker recovery.
|
||||
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 guide](bitlocker-recovery-guide-plan.md).
|
||||
For more information about the recovery process, see the [BitLocker recovery guide](../bitlocker-recovery-guide-plan.md).
|
||||
|
||||
| | Path |
|
||||
|--|--|
|
||||
|
||||
@ -11,18 +11,10 @@ ms.date: 09/29/2023
|
||||
|
||||
This reference article describes the policy settings to configure BitLocker via configuration service provider (CSP) and group policy (GPO).
|
||||
|
||||
## BitLocker and policies compliance
|
||||
|
||||
If a device isn't compliant with the existing policies, BitLocker may not be turned on, or BitLocker configuration may be modified until the computer 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 was brought out of compliance by change in policy settings.
|
||||
|
||||
If multiple changes are necessary to bring the drive into compliance, BitLocker protection may 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 but then policy settings are changed to disallow passwords and require smart cards. In this situation, BitLocker protection needs to be suspended by using the [`manage-bde`](/windows-server/administration/windows-commands/manage-bde) command-line tool, 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 may 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. The [`manage-bde`](/windows-server/administration/windows-commands/manage-bde) command-line can also be used in this scenario to help bring the device into compliance.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Most of the BitLocker policy settings are enforced when BitLocker is initially turned on for a drive. Encryption isn't restarted if settings change.
|
||||
|
||||
## Settings list
|
||||
## Policy settings list
|
||||
|
||||
The list of settings is sorted alphabetically and organized in four categories:
|
||||
|
||||
@ -144,3 +136,11 @@ The following table lists the BitLocker policies applicable to all drive types,
|
||||
[!INCLUDE [removable-drives-excluded-from-encryption](includes/removable-drives-excluded-from-encryption.md)]
|
||||
|
||||
---
|
||||
|
||||
## BitLocker and policies compliance
|
||||
|
||||
If a device isn't compliant with the configured policies, BitLocker may not be turned on, or BitLocker configuration may be modified until the computer 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 was brought out of compliance by change in policy settings.
|
||||
|
||||
If multiple changes are necessary to bring the drive into compliance, BitLocker protection may 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 but then policy settings are changed to disallow passwords and require smart cards. In this situation, BitLocker protection needs to be suspended by using the [`manage-bde`](/windows-server/administration/windows-commands/manage-bde) command-line tool, 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 may 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. The [`manage-bde`](/windows-server/administration/windows-commands/manage-bde) command-line can also be used in this scenario to help bring the device into compliance.
|
||||
Reference in New Issue
Block a user