mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-16 10:53:43 +00:00
updates
This commit is contained in:
Paolo Matarazzo
@ -12,87 +12,60 @@ ms.date: 09/29/2023
|
||||
|
||||
Organizations can use BitLocker recovery information saved in Microsoft Entra ID and Active Directory Domain Services (AD DS) to access BitLocker-protected drives. It's recommended to create a recovery model for BitLocker while planning your BitLocker deployment.
|
||||
|
||||
This article describes how to recover BitLocker keys from Microsoft Entra ID and Active Directory Domain Services (AD DS).
|
||||
|
||||
This article assumes that it's understood how to configure devices to automatically backup BitLocker recovery information, and what types of recovery information are saved to Microsoft Entra ID and AD DS.
|
||||
This article describes how to recover BitLocker keys from Microsoft Entra ID and Active Directory Domain Services (AD DS). This article assumes that it's understood how to configure devices to automatically backup BitLocker recovery information, and what types of recovery information are saved to Microsoft Entra ID and AD DS.
|
||||
|
||||
## What is BitLocker recovery?
|
||||
|
||||
BitLocker recovery is the process by which access to a BitLocker-protected drive can be restored if the drive can't be unlocked normally. In a recovery scenario, the following options to restore access to the drive are available:
|
||||
|
||||
- The user can supply the 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 AD DS and use it to unlock the drive: storing recovery passwords in AD DS is recommended to provide a way for IT professionals to be able to obtain recovery passwords for drives in an organization if needed. This method requires to enable the recovery method **Choose how BitLocker-protected operating system drives can be recovered**. For more information, review [BitLocker policy settings](policy-settings.md).
|
||||
- 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)
|
||||
|
||||
### What causes BitLocker recovery?
|
||||
|
||||
The following list provides examples of specific events that will cause BitLocker to enter recovery mode when attempting to start the operating system drive:
|
||||
The following list provides some examples of specific events that causes BitLocker to enter recovery mode when attempting to start the operating system drive:
|
||||
|
||||
- On devices that use BitLocker drive encryption or [device encryption](index.md#device-encryption), 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.
|
||||
|
||||
- Having the CD or DVD drive before the hard drive in the BIOS boot order and then inserting or removing a CD or DVD.
|
||||
|
||||
- Failing to boot from a network drive before booting from the hard drive.
|
||||
|
||||
- Docking or undocking a portable computer. In some instances (depending on the computer manufacturer and the BIOS), the docking condition of the portable computer is part of the system measurement and must be consistent to validate the system status and unlock BitLocker. So if a portable computer is connected to its docking station when BitLocker is turned on, then it might also need to be connected to the docking station when it's unlocked. Conversely, if a portable computer isn't connected to its docking station when BitLocker is turned on, then it might need to be disconnected from the docking station when it's unlocked.
|
||||
|
||||
- Changes to the NTFS partition table on the disk including creating, deleting, or resizing a primary partition.
|
||||
|
||||
- Entering the personal identification number (PIN) incorrectly too many times so that the anti-hammering logic of the TPM is activated. Anti-hammering logic is software or hardware methods that increase the difficulty and cost of a brute force attack on a PIN by not accepting PIN entries until after a certain amount of time has passed.
|
||||
|
||||
- Turning off the support for reading the USB device in the pre-boot environment from the BIOS or UEFI firmware if using USB-based keys instead of a TPM.
|
||||
|
||||
- Turning off, disabling, deactivating, or clearing the TPM.
|
||||
|
||||
- Upgrading critical early startup components, such as a BIOS or UEFI firmware upgrade, causing the related boot measurements to change.
|
||||
|
||||
- Forgetting the PIN when PIN authentication has been enabled.
|
||||
|
||||
- Updating option ROM firmware.
|
||||
|
||||
- Upgrading TPM firmware.
|
||||
|
||||
- Adding or removing hardware; for example, inserting a new card in the computer, including some PCMIA wireless cards.
|
||||
|
||||
- Removing, inserting, or completely depleting the charge on a smart battery on a portable computer.
|
||||
|
||||
- Changes to the master boot record on the disk.
|
||||
|
||||
- Changes to the boot manager on the disk.
|
||||
|
||||
- Hiding the TPM from the operating system. Some BIOS or UEFI settings can be used to prevent the enumeration of the TPM to the operating system. When implemented, this option can make the TPM hidden from the operating system. When the TPM is hidden, BIOS and UEFI secure startup are disabled, and the TPM doesn't respond to commands from any software.
|
||||
|
||||
- Using a different keyboard that doesn't correctly enter the PIN or whose keyboard map doesn't match the keyboard map assumed by the pre-boot environment. This problem can prevent the entry of enhanced PINs.
|
||||
|
||||
- Modifying the Platform Configuration Registers (PCRs) used by the TPM validation profile. For example, including **PCR\[1\]** would result in BitLocker measuring most changes to BIOS settings, causing BitLocker to enter recovery mode even when non-boot critical BIOS settings change.
|
||||
- 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
|
||||
- Having the CD or DVD drive before the hard drive in the BIOS boot order and then inserting or removing a CD or DVD
|
||||
- Failing to boot from a network drive before booting from the hard drive
|
||||
- Docking or undocking a portable computer. In some instances (depending on the computer manufacturer and the BIOS), the docking condition of the portable computer is part of the system measurement and must be consistent to validate the system status and unlock BitLocker. So if a portable computer is connected to its docking station when BitLocker is turned on, then it might also need to be connected to the docking station when it's unlocked. Conversely, if a portable computer isn't connected to its docking station when BitLocker is turned on, then it might need to be disconnected from the docking station when it's unlocked
|
||||
- Changes to the NTFS partition table on the disk including creating, deleting, or resizing a primary partition
|
||||
- Entering the personal identification number (PIN) incorrectly too many times so that the anti-hammering logic of the TPM is activated. Anti-hammering logic is software or hardware methods that increase the difficulty and cost of a brute force attack on a PIN by not accepting PIN entries until after a certain amount of time has passed
|
||||
- Turning off the support for reading the USB device in the pre-boot environment from the BIOS or UEFI firmware if using USB-based keys instead of a TPM
|
||||
- Turning off, disabling, deactivating, or clearing the TPM
|
||||
- Upgrading critical early startup components, such as a BIOS or UEFI firmware upgrade, causing the related boot measurements to change
|
||||
- Forgetting the PIN when PIN authentication has been enabled
|
||||
- Updating option ROM firmware
|
||||
- Upgrading TPM firmware
|
||||
- Adding or removing hardware; for example, inserting a new card in the computer, including some PCMIA wireless cards
|
||||
- Removing, inserting, or completely depleting the charge on a smart battery on a portable computer
|
||||
- Changes to the master boot record on the disk
|
||||
- Changes to the boot manager on the disk
|
||||
- Hiding the TPM from the operating system. Some BIOS or UEFI settings can be used to prevent the enumeration of the TPM to the operating system. When implemented, this option can make the TPM hidden from the operating system. When the TPM is hidden, BIOS and UEFI secure startup are disabled, and the TPM doesn't respond to commands from any software
|
||||
- Using a different keyboard that doesn't correctly enter the PIN or whose keyboard map doesn't match the keyboard map assumed by the pre-boot environment. This problem can prevent the entry of enhanced PINs
|
||||
- Modifying the Platform Configuration Registers (PCRs) used by the TPM validation profile. For example, including **PCR\[1\]** would result in BitLocker measuring most changes to BIOS settings, causing BitLocker to enter recovery mode even when non-boot critical BIOS settings change
|
||||
|
||||
> [!NOTE]
|
||||
> Some computers have BIOS settings that skip measurements to certain PCRs, such as **PCR\[2\]**. Changing this setting in the BIOS would cause BitLocker to enter recovery mode because the PCR measurement will be different.
|
||||
|
||||
- Moving the BitLocker-protected drive into a new computer.
|
||||
|
||||
- Upgrading the motherboard to a new one with a new TPM.
|
||||
|
||||
- Losing the USB flash drive containing the startup key when startup key authentication has been enabled.
|
||||
|
||||
- Failing the TPM self-test.
|
||||
|
||||
- Having a BIOS, UEFI firmware, or an option ROM component that isn't compliant with the relevant Trusted Computing Group standards for a client computer. For example, a non-compliant implementation may record volatile data (such as time) in the TPM measurements, causing different measurements on each startup and causing BitLocker to start in recovery mode.
|
||||
|
||||
- Changing the usage authorization for the storage root key of the TPM to a non-zero value.
|
||||
- Moving the BitLocker-protected drive into a new computer
|
||||
- Upgrading the motherboard to a new one with a new TPM
|
||||
- Losing the USB flash drive containing the startup key when startup key authentication has been enabled
|
||||
- Failing the TPM self-test
|
||||
- Having a BIOS, UEFI firmware, or an option ROM component that isn't compliant with the relevant Trusted Computing Group standards for a client computer. For example, a non-compliant implementation may record volatile data (such as time) in the TPM measurements, causing different measurements on each startup and causing BitLocker to start in recovery mode
|
||||
- Changing the usage authorization for the storage root key of the TPM to a non-zero value
|
||||
|
||||
> [!NOTE]
|
||||
> The BitLocker TPM initialization process sets the usage authorization value to zero, so another user or process must explicitly have changed this value.
|
||||
|
||||
- Disabling the code integrity check or enabling test signing on Windows Boot Manager (Bootmgr).
|
||||
|
||||
- Pressing the F8 or F10 key during the boot process.
|
||||
|
||||
- Adding or removing add-in cards (such as video or network cards), or upgrading firmware on add-in cards.
|
||||
|
||||
- Using a BIOS hot key during the boot process to change the boot order to something other than the hard drive.
|
||||
- Disabling the code integrity check or enabling test signing on Windows Boot Manager (Bootmgr)
|
||||
- Pressing the F8 or F10 key during the boot process
|
||||
- Adding or removing add-in cards (such as video or network cards), or upgrading firmware on add-in cards
|
||||
- Using a BIOS hot key during the boot process to change the boot order to something other than the hard drive
|
||||
|
||||
> [!NOTE]
|
||||
> Before beginning recovery, it is recommend to determine what caused recovery. This might help prevent the problem from occurring again in the future. For instance, if it is determined that an attacker has modified the computer by obtaining physical access, new security policies can be created for tracking who has physical presence. After the recovery password has been used to recover access to the PC, BitLocker reseals the encryption key to the current values of the measured components.
|
||||
@ -102,7 +75,7 @@ For planned scenarios, such as a known hardware or firmware upgrades, initiating
|
||||
> [!NOTE]
|
||||
> If suspended BitLocker will automatically resume protection when the PC is rebooted, unless a reboot count is specified using the manage-bde command line tool.
|
||||
|
||||
If software maintenance requires the computer to be restarted and two-factor authentication is being used, the BitLocker network unlock feature can be enabled to provide the secondary authentication factor when the computers don't have an on-premises user to provide the additional authentication method.
|
||||
If software maintenance requires the computer to be restarted and two-factor authentication is being used, the BitLocker network unlock feature can be enabled to provide the secondary authentication factor when the computers don't have a user to provide the additional authentication method.
|
||||
|
||||
Recovery has been described within the context of unplanned or undesired behavior. However, recovery can also be caused as an intended production scenario, for example in order to manage access control. When desktop or laptop computers are redeployed to other departments or employees in the enterprise, BitLocker can be forced into recovery before the computer is given to a new user.
|
||||
|
||||
@ -110,50 +83,36 @@ Recovery has been described within the context of unplanned or undesired behavio
|
||||
|
||||
Before a thorough BitLocker recovery process is created, it's recommended to test how the recovery process works for both end users (people who call the helpdesk for the recovery password) and administrators (people who help the end user get the recovery password). The `-forcerecovery` command of `manage-bde.exe` is an easy way to step through the recovery process before users encounter a recovery situation.
|
||||
|
||||
**To force a recovery for the local computer:**
|
||||
|
||||
1. Select the **Start** button and type in **cmd**
|
||||
|
||||
2. Right select on **cmd.exe** or **Command Prompt** and then select **Run as administrator**.
|
||||
|
||||
3. At the Command Prompt, enter the following command:
|
||||
To force a recovery for the local computer, open an elevated command prompt and enter the following command:
|
||||
|
||||
```cmd
|
||||
manage-bde.exe -forcerecovery <BitLockerVolume>
|
||||
```
|
||||
|
||||
**To force recovery for a remote computer:**
|
||||
|
||||
1. Select the **Start** button and type in **cmd**
|
||||
|
||||
2. Right select on **cmd.exe** or **Command Prompt** and then select **Run as administrator**.
|
||||
|
||||
3. At the Command Prompt, enter the following command:
|
||||
To force a recovery for a remote computer, open an elevated command prompt and enter the following command:
|
||||
|
||||
```cmd
|
||||
manage-bde.exe -ComputerName <RemoteComputerName> -forcerecovery <BitLockerVolume>
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> Recovery triggered by `-forcerecovery` persists for multiple restarts until a TPM protector is added or protection is suspended by the user. When using Modern Standby devices (such as Surface devices), the `-forcerecovery` option is not recommended because BitLocker will have to be unlocked and disabled manually from the WinRE environment before the OS can boot up again. For more information, see [BitLocker Troubleshooting: Continuous reboot loop with BitLocker recovery on a slate device](https://social.technet.microsoft.com/wiki/contents/articles/18671.bitlocker-troubleshooting-continuous-reboot-loop-with-bitlocker-recovery-on-a-slate-device.aspx).
|
||||
> Recovery triggered by `-forcerecovery` persists for multiple restarts until a TPM protector is added or protection is suspended by the user. When using Modern Standby devices, the `-forcerecovery` option is not recommended because BitLocker will have to be unlocked and disabled manually from the WinRE environment before the OS can boot up again. For more information, see [BitLocker Troubleshooting: Continuous reboot loop with BitLocker recovery on a slate device](https://social.technet.microsoft.com/wiki/contents/articles/18671.bitlocker-troubleshooting-continuous-reboot-loop-with-bitlocker-recovery-on-a-slate-device.aspx).
|
||||
|
||||
## Plan the recovery process
|
||||
|
||||
When planning the BitLocker recovery process, first consult the organization's current best practices for recovering sensitive information. For example: How does the enterprise handle lost Windows passwords? How does the organization perform smart card PIN resets? These best practices and related resources (people and tools) can be used to help formulate a BitLocker recovery model.
|
||||
When planning the BitLocker recovery process, first consult the organization's current best practices for recovering sensitive information. For example:
|
||||
|
||||
Organizations that rely on BitLocker Drive Encryption and BitLocker To Go to protect data on a large number of computers and removable drives running the Windows 11, Windows 10, Windows 8, or Windows 7 operating systems and Windows to Go should consider using the Microsoft BitLocker Administration and Monitoring (MBAM) Tool version 2.0, which is included in the Microsoft Desktop Optimization Pack (MDOP) for Microsoft Software Assurance. MBAM makes BitLocker implementations easier to deploy and manage and allows administrators to provision and monitor encryption for operating system and fixed drives. MBAM prompts the user before encrypting fixed drives. MBAM also manages recovery keys for fixed and removable drives, making recovery easier to manage. MBAM can be used as part of a Microsoft System Center deployment or as a stand-alone solution. For more info, see [Microsoft BitLocker Administration and Monitoring](/microsoft-desktop-optimization-pack/mbam-v25/).
|
||||
- how does the organization handle lost Windows passwords?
|
||||
- how does the organization perform smart card PIN resets?
|
||||
|
||||
After a BitLocker recovery has been initiated, users can use a recovery password to unlock access to encrypted data. Consider both self-recovery and recovery password retrieval methods for the organization.
|
||||
|
||||
When the recovery process is determined:
|
||||
|
||||
- Become familiar with how a recovery password can be retrieved. See:
|
||||
|
||||
- [Self-recovery](#self-recovery)
|
||||
- [Recovery password retrieval](#recovery-password-retrieval)
|
||||
|
||||
- Determine a series of steps for post-recovery, including analyzing why the recovery occurred and resetting the recovery password. See:
|
||||
|
||||
- [Post-recovery analysis](#post-recovery-analysis)
|
||||
|
||||
### Self-recovery
|
||||
|
||||
Reference in New Issue
Block a user