mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-12 13:27:23 +00:00
operations guide
This commit is contained in:
Paolo Matarazzo
parent
e0964d488a
commit
35ee01a186
@ -10,9 +10,11 @@ ms.date: 10/03/2023
|
||||
To configure BitLocker, you can use one of the following options:
|
||||
|
||||
- Configuration Service Provider (CSP): this option is commonly used for devices managed by a Mobile Device Management (MDM) solution, like Microsoft Intune. The [BitLocker CSP](/windows/client-management/mdm/bitlocker-csp) is used to configure BitLocker, and to report the status of different BitLocker functions to the MDM solution. With Microsoft Intune, you can use the BitLocker status in [compliance polices](/mem/intune/protect/compliance-policy-create-windows#encryption), combining them with [Conditional Access](/azure/active-directory/conditional-access/overview). Conditional Access can prevent or grant access to services like Exchange Online and SharePoint Online, based on the status of BitLocker. To learn more about the Intune options to configure and monitor BitLocker, check the following articles:
|
||||
|
||||
- [Manage BitLocker policy for Windows devices with Intune](/mem/intune/protect/encrypt-devices#rotate-bitlocker-recovery-keys)
|
||||
- [Monitor device encryption with Intune](/mem/intune/protect/encryption-monitor)
|
||||
- [Use compliance policies to set rules for devices you manage with Intune](/mem/intune/protect/device-compliance-get-started)
|
||||
|
||||
- Group policy (GPO): this option can be used for devices that are joined to an Active Directory domain and aren't managed by a device management solution. Group policy can also be used for devices that aren't joined to an Active Directory domain, using the local group policy editor
|
||||
- Microsoft Configuration Manager: this option can be used for devices that are managed by Microsoft Configuration Manager using the BitLocker management agent. 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)
|
||||
|
||||
|
||||
@ -50,7 +50,7 @@ To learn more, see the policy setting [Require additional authentication at star
|
||||
|
||||
### 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](configure.md?tabs=common#disable-new-dma-devices-when-this-computer-is-locked).
|
||||
It's important to protect DMA ports, as external peripherals might 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
|
||||
|
||||
@ -63,7 +63,7 @@ A physically present attacker might attempt to install a bootkit or rootkit-like
|
||||
> [!NOTE]
|
||||
> BitLocker protects against this attack by default.
|
||||
|
||||
A BIOS password is recommended for defense-in-depth in case a BIOS exposes settings that may weaken the BitLocker security promise. Intel Boot Guard and AMD Hardware Verified Boot support stronger implementations of Secure Boot that provide additional resilience against malware and physical attacks. Intel Boot Guard and AMD Hardware Verified Boot are part of platform boot verification [standards for a highly secure Windows device](/windows-hardware/design/device-experiences/oem-highly-secure).
|
||||
A BIOS password is recommended for defense-in-depth in case a BIOS exposes settings that might weaken the BitLocker security promise. Intel Boot Guard and AMD Hardware Verified Boot support stronger implementations of Secure Boot that provide additional resilience against malware and physical attacks. Intel Boot Guard and AMD Hardware Verified Boot are part of platform boot verification [standards for a highly secure Windows device](/windows-hardware/design/device-experiences/oem-highly-secure).
|
||||
|
||||
### Brute force attacks against a PIN
|
||||
|
||||
@ -79,13 +79,13 @@ These files are secured on an encrypted volume by default when BitLocker is enab
|
||||
|
||||
### Memory remanence
|
||||
|
||||
Enable secure boot and mandatorily prompt a password to change BIOS settings. For scenarios requiring protection against these advanced attacks, configure a TPM+PIN protector, disable *standby* power management, and shut down or hibernate the device before it leaves the control of an authorized user.
|
||||
Enable secure boot and mandatorily use a password to change BIOS settings. For scenarios requiring protection against these advanced attacks, configure a `TPM+PIN` protector, disable *standby* power management, and shut down or hibernate the device before it leaves the control of an authorized user.
|
||||
|
||||
The Windows default power settings cause devices to enter *sleep mode* when idle. When a device transitions to sleep, running programs and documents are persisted in memory. When a device resumes from sleep, users aren't required to reauthenticate with a PIN or USB startup key to access encrypted data. This scenario may lead to conditions where data security is compromised.
|
||||
The Windows default power settings cause devices to enter *sleep mode* when idle. When a device transitions to sleep, running programs and documents are persisted in memory. When a device resumes from sleep, users aren't required to reauthenticate with a PIN or USB startup key to access encrypted data. This scenario might lead to conditions where data security is compromised.
|
||||
|
||||
When a device *hibernates*, the drive is locked. When the device resumes from hibernation, the drive is unlocked, which means that users must provide a PIN or a startup key if using multifactor authentication with BitLocker.
|
||||
|
||||
Therefore, organizations that use BitLocker may want to use Hibernate instead of Sleep for improved security.
|
||||
Therefore, organizations that use BitLocker might want to use Hibernate instead of Sleep for improved security.
|
||||
|
||||
> [!NOTE]
|
||||
> This setting doesn't have an impact on TPM-only mode, because it provides a transparent user experience at startup and when resuming from the Hibernate states.
|
||||
@ -94,7 +94,7 @@ Therefore, organizations that use BitLocker may want to use Hibernate instead of
|
||||
|
||||
An attacker might modify the boot manager configuration database (BCD), which is stored on a nonencrypted partition and add an entry point to a rogue operating system on a different partition. During the boot process, BitLocker code makes sure that the operating system that the encryption key obtained from the TPM is given to, is cryptographically verified to be the intended recipient. Because this strong cryptographic verification already exists, we don't recommend storing a hash of a disk partition table in Platform Configuration Register (PCR) 5.
|
||||
|
||||
An attacker might also replace the entire operating system disk while preserving the platform hardware and firmware and could then extract a protected BitLocker key blob from the metadata of the victim OS partition. The attacker could then attempt to unseal that BitLocker key blob by calling the TPM API from an operating system under their control. This can't succeed because when Windows seals the BitLocker key to the TPM, it does it with a PCR 11 value of 0, and to successfully unseal the blob, PCR 11 in the TPM must have a value of 0. However, when the boot manager passes the control to any boot loader (legitimate or rogue) it always changes PCR 11 to a value of 1. Since the PCR 11 value is guaranteed to be different after exiting the boot manager, the attacker can't unlock the BitLocker key.
|
||||
An attacker might also replace the entire operating system disk while preserving the platform hardware and firmware and could then extract a protected BitLocker key blob from the metadata of the victim OS partition. The attacker could then attempt to unseal that BitLocker key blob by calling the TPM API from an operating system under their control. This can't succeed because when Windows seals the BitLocker key to the TPM, it does it with a PCR 11 value of 0. To successfully unseal the blob, PCR 11 in the TPM must have a value of 0. However, when the boot manager passes the control to any boot loader (legitimate or rogue) it always changes PCR 11 to a value of 1. Since the PCR 11 value is guaranteed to be different after exiting the boot manager, the attacker can't unlock the BitLocker key.
|
||||
|
||||
## Attacker countermeasures
|
||||
|
||||
@ -102,7 +102,7 @@ The following sections cover mitigations for different types of attackers.
|
||||
|
||||
### Attacker without much skill or with limited physical access
|
||||
|
||||
Physical access may be limited by a form factor that doesn't expose buses and memory. For example, there are no external DMA-capable ports, no exposed screws to open the chassis, and memory is soldered to the mainboard.
|
||||
Physical access might be limited in a form factor that doesn't expose buses and memory. For example, there are no external DMA-capable ports, no exposed screws to open the chassis, and memory is soldered to the mainboard.
|
||||
|
||||
This attacker of opportunity doesn't use destructive methods or sophisticated forensics hardware/software.
|
||||
|
||||
@ -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](configure.md?tabs=os#allow-enhanced-pins-for-startup).
|
||||
For some systems, bypassing TPM-only might require opening the case and require soldering, but can 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:
|
||||
|
||||
|
||||
@ -14,20 +14,20 @@ BitLocker is a Windows security feature that provides encryption for entire volu
|
||||
|
||||
## Practical applications
|
||||
|
||||
Data on a lost or stolen device is vulnerable to unauthorized access, either by running a software-attack tool against it, or by transferring the devices's hard drive to a different device. BitLocker helps mitigate unauthorized data access by enhancing file and system protections, rendering data inaccessible when BitLocker-protected devices are decommissioned or recycled.
|
||||
Data on a lost or stolen device is vulnerable to unauthorized access, either by running a software-attack tool against it, or by transferring the device's hard drive to a different device. BitLocker helps mitigate unauthorized data access by enhancing file and system protections, rendering data inaccessible when BitLocker-protected devices are decommissioned or recycled.
|
||||
|
||||
## BitLocker and TPM
|
||||
|
||||
BitLocker provides maximum protection when used with a Trusted Platform Module (TPM). A TPM is a common hardware component installed on Windows devices, and it works with BitLocker to ensure that a device hasn't been tampered with while the system is offline.
|
||||
BitLocker provides maximum protection when used with a Trusted Platform Module (TPM), which is a common hardware component installed on Windows devices. The TPM works with BitLocker to ensure that a device hasn't been tampered with while the system is offline.
|
||||
|
||||
In **addition** to the TPM, BitLocker has the option to lock the normal startup process until the user supplies a personal identification number (PIN) or inserts a removable device that contains a *startup key*. These security measures provide multifactor authentication and assurance that the device can't start or resume from hibernation until the correct PIN or startup key is presented.
|
||||
In *addition* to the TPM, BitLocker can lock the normal startup process until the user supplies a personal identification number (PIN) or inserts a removable device that contains a *startup key*. These security measures provide multifactor authentication and assurance that the device can't start or resume from hibernation until the correct PIN or startup key is presented.
|
||||
|
||||
On devices that don't have a TPM, BitLocker can still be used to encrypt the operating system drive. This implementation requires the user to either:
|
||||
|
||||
- use a startup key, which is a file stored on a removable drive that is used to start the device, or when resuming from hibernation
|
||||
- use a password. This option is not very secure since there's no password lockout logic. As such, this option is discouraged and disabled by default
|
||||
- use a password. This option isn't secure since it's subject to brute force attacks as there isn't a password lockout logic. As such, the password option is discouraged and disabled by default
|
||||
|
||||
Both options don't provide the pre-startup system integrity verification offered by BitLocker with a TPM.
|
||||
Both options don't provide the preboot system integrity verification offered by BitLocker with a TPM.
|
||||
|
||||
:::row:::
|
||||
:::column span="1":::
|
||||
@ -57,8 +57,8 @@ Both options don't provide the pre-startup system integrity verification offered
|
||||
BitLocker has the following requirements:
|
||||
|
||||
- For BitLocker to use the system integrity check provided by a TPM, the device must have TPM 1.2 or later versions. If a device doesn't have a TPM, saving a startup key on a removable drive is mandatory when enabling BitLocker
|
||||
- A device with a TPM must also have a *Trusted Computing Group* (TCG)-compliant BIOS or UEFI firmware. The BIOS or UEFI firmware establishes a chain of trust for the pre-operating system startup, and it must include support for *TCG-specified Static Root of Trust Measurement*. A computer without a TPM doesn't require TCG-compliant firmware
|
||||
- The system BIOS or UEFI firmware (for TPM and non-TPM devices) must support the USB mass storage device class, and reading files on a USB drive in the pre-operating system environment
|
||||
- A device with a TPM must also have a *Trusted Computing Group* (TCG)-compliant BIOS or UEFI firmware. The BIOS or UEFI firmware establishes a chain of trust for the preboot startup, and it must include support for *TCG-specified Static Root of Trust Measurement*. A computer without a TPM doesn't require TCG-compliant firmware
|
||||
- The system BIOS or UEFI firmware (for TPM and non-TPM devices) must support the USB mass storage device class, and reading files on a USB drive in the preboot environment
|
||||
|
||||
> [!NOTE]
|
||||
> TPM 2.0 is not supported in *Legacy* and *Compatibility Support Module (CSM)* modes of the BIOS. Devices with TPM 2.0 must have their BIOS mode configured as native UEFI only. The Legacy and CSM options must be disabled. For added security, enable the *secure boot* feature.
|
||||
@ -88,7 +88,7 @@ BitLocker has the following requirements:
|
||||
|
||||
## Device encryption
|
||||
|
||||
*Device encryption* is a Windows feature that provides a simple way for some devices to enable BitLocker encryption automatically. Device encryption is available on all Windows versions, including Home edition, and it requires a device to meet either [Modern Standby](/windows-hardware/design/device-experiences/modern-standby) or HSTI security requirements, and have no externally accessible ports that allow DMA access.
|
||||
*Device encryption* is a Windows feature that provides a simple way for some devices to enable BitLocker encryption automatically. Device encryption is available on all Windows versions, and it requires a device to meet either [Modern Standby](/windows-hardware/design/device-experiences/modern-standby) or HSTI security requirements. Device encryption can't have externally accessible ports that allow DMA access.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Device encryption encrypts only the OS drive and fixed drives, it doesn't encrypt external/USB drives.
|
||||
@ -106,7 +106,7 @@ Unlike a standard BitLocker implementation, device encryption is enabled automat
|
||||
>
|
||||
> If a different encryption method and/or cipher strength is needed but the device is already encrypted, it must first be decrypted before the new encryption method and/or cipher strength can be applied. After the device is decrypted, you can apply different BitLocker settings.
|
||||
|
||||
If a device doesn't initially qualify for device encryption, but then a change is made that causes the device to qualify (for example, turn *Secure Boot* on), device encryption enables BitLocker automatically as soon as it detects it (unless device encryption is disabled).
|
||||
If a device doesn't initially qualify for device encryption, but then a change is made that causes the device to qualify (for example, by turning on *Secure Boot*), device encryption enables BitLocker automatically as soon as it detects it.
|
||||
|
||||
You can check whether a device meets requirements for device encryption in the System Information app (`msinfo32.exe`). If the device meets the requirements, System Information shows a line that reads:
|
||||
|
||||
|
||||
@ -43,29 +43,20 @@ To protect the BitLocker encryption key, BitLocker can use different types of *p
|
||||
|
||||
| Key protector | Description |
|
||||
| - | - |
|
||||
| Password | To unlock a drive, the user must supply a password. This key protector can be used on non-TPM devices .|
|
||||
| TPM | A hardware device used to help establish a secure root-of-trust. BitLocker only supports TPM 1.2 or higher versions. The TPM protector can only be used with the OS drive. |
|
||||
| PIN | A user-entered numeric or alphanumeric key protector that can only be used with OS volumes and in addition to the TPM.|
|
||||
| Startup key | An encryption key that can be stored on removable media, with a file name format of `<protector_id>.bek`. This key protector can be used alone on non-TPM computers, or with a TPM for added security.|
|
||||
| Password | To unlock a drive, the user must supply a password. When used for OS drives, the user is prompted for a password in the preboot screen. This method doesn't offer any lockout logic, therefore it doesn't protect against brute force attacks|
|
||||
| Autounlock | |
|
||||
| Smart card certificate | To unlock a drive, the user must use a smart card.|
|
||||
| TPM | A hardware device used to help establish a secure root-of-trust, validating early boot components. The TPM protector can only be used with the OS drive. |
|
||||
| TPM + PIN | A user-entered numeric or alphanumeric key protector that can only be used with OS volumes and in addition to the TPM.The TPM validates early boot components. The user must enter the correct PIN before the start-up process can continue, and before the drive can be unlocked. The TPM enters lockout if the incorrect PIN is entered repeatedly, to protect the PIN from brute force attacks. The number of repeated attempts that will trigger a lockout is variable.|
|
||||
| Startup key | An encryption key that can be stored on removable media, with a file name format of `<protector_id>.bek`. The user is prompted for the USB flash drive that has the recovery key and/or startup key, and then reboot the device.|
|
||||
| TPM + Startup key | The TPM successfully validates early boot components, and a USB flash drive containing the startup key has been inserted. |
|
||||
| TPM + Startup key + PIN | The TPM successfully validates early boot components. The user must enter the correct PIN and insert a USB drive containing the startup key before the OS can boot |
|
||||
| Recovery key| An encryption key stored on removable media that can be used for recovering data encrypted on a BitLocker volume. The file name has a format of `<protector_id>.bek`|
|
||||
| Recovery password | A 48-digit number used to unlock a volume when it is in *recovery mode*. Numbers can often be typed on a regular keyboard. If the numbers on the normal keyboard aren't responding, the function keys (F1-F10) can be used to input the numbers.|
|
||||
| PublicKey (DataRecoveryAgent) | A *Data Recovery Agent* (DRA) certificate that can be used to access any BitLocker encrypted drives that is configured with the public key protector.|
|
||||
| Network (TpmNetworkKey) | A key protector that allows automatic unlocking of operating system volumes while still maintaining multifactor authentication. This key protector can only be used with OS volumes.|
|
||||
| TPM + Network Key (TpmNetworkKey) | The TPM successfully validates early boot components, and a valid encrypted network key has been provided from a WDS server. This authentication method provides automatic unlock of OS volumes while maintaining multifactor authentication. This key protector can only be used with OS volumes.|
|
||||
| Active Directory user or group | A protector that is based on an Active Directory user or group security identified (SID). This protector can't be used for OS volumes and is not supported on Microsoft Entra joined devices.|
|
||||
|
||||
### BitLocker authentication methods
|
||||
|
||||
The following table describes the authentication methods that can be used to unlock an OS volume:
|
||||
|
||||
| Authentication method | Requires user interaction | Description |
|
||||
| - | - | - |
|
||||
| TPM only| No| TPM validates early boot components|
|
||||
| TPM + PIN | Yes| TPM validates early boot components. The user must enter the correct PIN before the start-up process can continue, and before the drive can be unlocked. The TPM enters lockout if the incorrect PIN is entered repeatedly, to protect the PIN from brute force attacks. The number of repeated attempts that will trigger a lockout is variable.|
|
||||
| TPM + Network key | No | The TPM successfully validates early boot components, and a valid encrypted network key has been provided from a WDS server. This authentication method provides automatic unlock of operating system volumes at system reboot while still maintaining multifactor authentication. |
|
||||
| TPM + startup key | Yes| The TPM successfully validates early boot components, and a USB flash drive containing the startup key has been inserted.|
|
||||
| Startup key only | Yes| The user is prompted for the USB flash drive that has the recovery key and/or startup key, and then reboot the device.|
|
||||
| Password | Yes| The user is prompted for a password in the preboot screen. This method doesn't offer any lockout logic, therefore it doesn't protect against brute force attacks. |
|
||||
|
||||
#### Support for devices without TPM
|
||||
|
||||
Determine whether computers that don't have a TPM 1.2 or higher versions in the environment will be supported. If it's decided to support devices without TPM, a user must use a USB startup key or a password to boot the system. The startup key requires extra support processes similar to multifactor authentication.
|
||||
|
||||
@ -16,10 +16,10 @@ In a recovery scenario, the following options to restore access to the drive may
|
||||
|
||||
:::row:::
|
||||
:::column span="2":::
|
||||
**Recovery password**: A 48-digit number used to unlock a volume when it is in recovery mode. The recovery password may be saved as a text file, printed or stored in Microsoft Entra ID or Active Directory. The user can supply a *recovery password*, if available. A recovery password must be allowed by policy settings, so that users can print or save it.
|
||||
**Recovery password**: a 48-digit number used to unlock a volume when it is in recovery mode. The recovery password may be saved as a text file, printed or stored in Microsoft Entra ID or Active Directory. The user can supply a *recovery password*, if available. A recovery password must be allowed by policy settings, so that users can print or save it.
|
||||
:::column-end:::
|
||||
:::column span="2":::
|
||||
:::image type="content" source="images/preboot-recovery.png" alt-text="Screenshot of the default BitLocker recovery screen asking to plug a USB drive with the recovery key." lightbox="images/preboot-recovery.png" border="false":::
|
||||
:::image type="content" source="images/preboot-recovery.png" alt-text="Screenshot of the default BitLocker recovery screen asking enter the recovery password." lightbox="images/preboot-recovery.png" border="false":::
|
||||
:::column-end:::
|
||||
:::row-end:::
|
||||
:::row:::
|
||||
@ -27,29 +27,19 @@ In a recovery scenario, the following options to restore access to the drive may
|
||||
**Recovery key**: an encryption key stored on removable media that can be used for recovering data encrypted on a BitLocker volume. The file name has a format of <protector_id>.bek. For the OS drive, the recovery key can be used to gain access to the device if BitLocker detects a condition that prevents it from unlocking the drive when the device is starting up. A recovery key can also be used to gain access to fixed data drives and removable drives that are encrypted with BitLocker, if for some reason the password is forgotten or the device can't access the drive.
|
||||
:::column-end:::
|
||||
:::column span="2":::
|
||||
:::image type="content" source="images/preboot-recovery-key.png" alt-text="Screenshot of the default BitLocker recovery screen asking to plug a USB drive with the recovery key." lightbox="images/preboot-recovery-key.png" border="false":::
|
||||
:::image type="content" source="images/preboot-recovery-key.png" alt-text="Screenshot of the BitLocker recovery screen asking to plug a USB drive with the recovery key." lightbox="images/preboot-recovery-key.png" border="false":::
|
||||
:::column-end:::
|
||||
:::row-end:::
|
||||
:::row:::
|
||||
:::column span="4":::
|
||||
**Data Recovery Agent**: A Data Recovery Agent (DRA) is a type of certificate that is associated with an Active Directory security principal and that can be used to access any BitLocker encrypted drives configured with the matching public key protector. *Data recovery agents* can use their credentials to unlock the drive. If the drive is an OS drive, the drive must be mounted as a data drive on another device for the data recovery agent to unlock it
|
||||
**Data Recovery Agent certificate**: a Data Recovery Agent (DRA) is a type of certificate that is associated with an Active Directory security principal and that can be used to access any BitLocker encrypted drives configured with the matching public key protector. *Data recovery agents* can use their credentials to unlock the drive. If the drive is an OS drive, the drive must be mounted as a data drive on another device for the data recovery agent to unlock it
|
||||
:::column-end:::
|
||||
:::row-end:::
|
||||
:::row:::
|
||||
:::column span="4":::
|
||||
**Key package**: blob that can be used with the BitLocker Repair tool to reconstruct critical parts of a drive and salvage recoverable data. With the key package and either the *recovery password* or *recovery key*, portions of a corrupted BitLocker-protected drive can be decrypted. Each key package works only for a drive that has the corresponding drive identifier. A key package is not generated automatically, and can be stored on a file or in AD DS.
|
||||
:::column-end:::
|
||||
:::row-end:::
|
||||
|
||||
## BitLocker key package
|
||||
|
||||
The BitLocker key package isn't saved by default. To save the package along with the recovery password in AD DS, the **Backup recovery password and key package** policy setting must be selected in the policy that controls the recovery method. The key package can also be exported from a working volume.
|
||||
|
||||
If recovery information is not backed up to AD DS, or if you want to save a key package in an alternative location, use the following command to generate a key package for a volume:
|
||||
|
||||
``` cmd
|
||||
manage-bde.exe -KeyPackage C: -id <id> -path <path>
|
||||
```
|
||||
|
||||
A file with a `.kpg` extension is created in the specified path.
|
||||
|
||||
> [!NOTE]
|
||||
> To export a new key package from an unlocked, BitLocker-protected volume, local administrator access to the working volume is required before any damage occurrs to the volume.
|
||||
|
||||
## Common scenarios for BitLocker recovery
|
||||
|
||||
@ -98,6 +88,9 @@ To help document the BitLocker recovery process that works best for your organiz
|
||||
|
||||
### Automatic backup of recovery information
|
||||
|
||||
> [!IMPORTANT]
|
||||
> The *BitLocker key package* can be stored in Active Directory Domain Services (AD DS), not in Microsoft Entra ID.
|
||||
|
||||
#### Microsoft Entra ID
|
||||
|
||||
#### Active Directory
|
||||
@ -116,6 +109,24 @@ The common name (cn) for the BitLocker recovery object is `ms-FVE-RecoveryInform
|
||||
|`ms-FVE-VolumeGuid`| GUID associated with a BitLocker-supported disk volume. While the password (stored in `ms-FVE-RecoveryGuid`) is unique for each recovery password, the volume identifier is unique for each BitLocker-encrypted volume.|
|
||||
|`ms-FVE-KeyPackage`| Volume's BitLocker encryption key secured by the corresponding recovery password. With this key package and the recovery password (stored in `ms-FVE-RecoveryPassword`), portions of a BitLocker-protected volume can be decrypted if the disk is corrupted. Each key package will work only for a volume that has the corresponding volume identifier (stored in `ms-FVE-VolumeGuid`). The BitLocker Repair Tool can be used to make use of the key package.|
|
||||
|
||||
To learn more about the BitLocker attributes stored in AD DS, review the following articles:
|
||||
|
||||
- [ms-FVE-KeyPackage attribute](/windows/win32/adschema/a-msfve-keypackage)
|
||||
- [ms-FVE-RecoveryPassword attribute](/windows/win32/adschema/a-msfve-recoverypassword)
|
||||
|
||||
The BitLocker key package isn't saved by default. To save the package along with the recovery password in AD DS, the **Backup recovery password and key package** policy setting must be selected in the policy that controls the recovery method. The key package can also be exported from a working volume.
|
||||
|
||||
If recovery information is not backed up to AD DS, or if you want to save a key package in an alternative location, use the following command to generate a key package for a volume:
|
||||
|
||||
``` cmd
|
||||
manage-bde.exe -KeyPackage C: -id <id> -path <path>
|
||||
```
|
||||
|
||||
A file with a `.kpg` extension is created in the specified path.
|
||||
|
||||
> [!NOTE]
|
||||
> To export a new key package from an unlocked, BitLocker-protected volume, local administrator access to the working volume is required before any damage occurrs to the volume.
|
||||
|
||||
### Data Recovery Agents
|
||||
|
||||
### User backup of recovery information
|
||||
|
||||
@ -235,15 +235,13 @@ Device name: DESKTOP-53O32QI
|
||||
BitLocker recovery key: 158422-038236-492536-574783-256300-205084-114356-069773
|
||||
```
|
||||
|
||||
|
||||
|
||||
## BitLocker Recovery Password Viewer
|
||||
|
||||
BitLocker Recovery Password Viewer is an optional tool included with the *Remote Server Administration Tools (RSAT)*. With Recovery Password Viewer, you can view the BitLocker recovery passwords that are stored in Active Directory Domain Services (AD DS). The tool is an extension for the *Active Directory Users and Computers Microsoft Management Console (MMC)* snap-in.
|
||||
BitLocker Recovery Password Viewer is an optional tool included with the *Remote Server Administration Tools (RSAT)*, and it's an extension for the *Active Directory Users and Computers Microsoft Management Console (MMC)* snap-in.
|
||||
|
||||
With BitLocker Recovery Password Viewer you can:
|
||||
|
||||
- Check the Active Directory computer object's properties to find the associated BitLocker recovery passwords
|
||||
- Check the Active Directory computer object's properties to retrieve the associated BitLocker recovery passwords
|
||||
- Search Active Directory for BitLocker recovery password across all the domains in the Active Directory forest. Passwords can also be searched by password identifier (ID)
|
||||
|
||||
### Requirements
|
||||
@ -293,29 +291,16 @@ Client-driven recovery password rotation to Enable rotation on Azure AD-joined d
|
||||
Save BitLocker recovery information to Azure Active Directory to Enabled
|
||||
Store recovery information in Azure Active Directory before enabling BitLocker to Required
|
||||
|
||||
|
||||
## BitLocker Repair tool
|
||||
|
||||
If the recovery methods discussed earlier in this document don't unlock the volume, the *BitLocker Repair tool* (`repair-bde.exe`) can be used to decrypt the volume at the block level. The tool uses the *BitLocker key package* to help recover encrypted data from severely damaged drives.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> The *BitLocker key package* can be stored in Active Directory Domain Services (AD DS), not in Microsoft Entra ID.
|
||||
|
||||
The recovered data can then be used to salvage encrypted data, even if the correct recovery password fails to unlock the damaged volume. It's recommended to still save the recovery password, as a key package can't be used without the corresponding recovery password.
|
||||
|
||||
### Retrieve the BitLocker key package
|
||||
|
||||
To export a previously saved key package from AD DS, it's required to have read access to the BitLocker recovery passwords and key packages that are stored in AD DS. By default, only Domain Admins have access to BitLocker recovery information, but [access can be delegated to others](/archive/blogs/craigf/delegating-access-in-ad-to-bitlocker-recovery-information).
|
||||
|
||||
To learn more about the BitLocker attributes stored in AD DS, review the following articles:
|
||||
|
||||
- [ms-FVE-KeyPackage attribute](/windows/win32/adschema/a-msfve-keypackage)
|
||||
- [ms-FVE-RecoveryPassword attribute](/windows/win32/adschema/a-msfve-recoverypassword)
|
||||
|
||||
## BitLocker Repair tool
|
||||
|
||||
The Repair Tool can reconstruct critical parts of a drive and salvage recoverable data, as long as a valid recovery password or recovery key is used to decrypt the data. If the BitLocker metadata data on the drive is corrupt, the backup key package in addition to the recovery password or recovery key must be supplied. With the key package and either the recovery password or recovery key, portions of a corrupted BitLocker-protected drive can be decrypted. Each key package works only for a drive that has the corresponding drive identifier.
|
||||
|
||||
Use the Repair tool in the following conditions:
|
||||
|
||||
- The drive is encrypted using BitLocker
|
||||
@ -332,3 +317,5 @@ The following limitations exist for Repair-bde:
|
||||
|
||||
For a complete list of the `repair-bde.exe` options, see the [Repair-bde reference](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/ff829851(v=ws.11)).
|
||||
|
||||
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user