valorea kahlie speech

0 views

Skip to first unread message

Florene Pothoven

unread,

Aug 3, 2024, 12:08:08 AM8/3/24

to exosgibdest

If a device or drive fails to unlock using the configured BitLocker mechanism, users may be able to self-recover it. If self-recovery isn't an option, or the user is unsure how to proceed, the helpdesk should have procedures in place to retrieve recovery information quickly and securely.

This article outlines the process of obtaining BitLocker recovery information for Microsoft Entra joined, Microsoft Entra hybrid joined, and Active Directory joined devices. It's assumed that the reader is already familiar with configuring devices to automatically back up BitLocker recovery information, and the available BitLocker recovery options. For more information, see the BitLocker recovery overview article.

If self-recovery includes using a password or recovery key stored on a USB flash drive, the users must be warned not to store the USB flash drive in the same place as the device, especially during travel. For example, if both the device and the recovery items are in the same bag, it would be easy for an unauthorized user to access the device. Another policy to consider is having users contact the helpdesk before or after performing self-recovery so that the root cause can be identified.

If BitLocker recovery keys are stored in Microsoft Entra ID, users can access them using the following URL: From the Devices tab, users can select a Windows device that they own, and select the option View BitLocker Keys.

By default, users can retrieve their BitLocker reecovery keys from Microsoft Entra ID. This behavior can be modified with the option Restrict users from recovering the BitLocker key(s) for their owned devices. For more information, see Restrict member users' default permissions.

If users saved the recovery password on a USB drive, they can plug the drive into a locked device and follow the instructions. If the key was saved as a text file on the flash drive, users must use a different device to read the text file.

The backup of the BitLocker recovery password to Microsoft Entra ID or AD DS may not happen automatically. Devices should be configured with policy settings to enable automatic backup, as described the BitLocker recovery overview article.

There are a few Microsoft Entra ID roles that allow a delegated administrator to read BitLocker recovery passwords from the devices in the tenant. While it's common for organizations to use the existing Microsoft Entra ID Cloud Device Administrator or Helpdesk Administrator built-in roles, you can also create a custom role, delegating access to BitLocker keys using the microsoft.directory/bitlockerKeys/key/read permission. Roles can be delegated to access BitLocker recovery passwords for devices in specific Administrative Units.

When devices that utilize Windows Autopilot are reused to join to Entra, and there is a new device owner, that new device owner must contact an administrator to acquire the BitLocker recovery key for that device. Custom role or administrative unit scoped administrators will lose access to BitLocker recovery keys for those devices that have undergone device ownership changes. These scoped administrators will need to contact a non-scoped administrator for the recovery keys. For more information, see the article Find the primary user of an Intune device.

The Microsoft Entra admin center allows administrators to retrieve BitLocker recovery passwords. To learn more about the process, see View or copy BitLocker keys. Another option to access BitLocker recovery passwords is to use the Microsoft Graph API, which might be useful for integrated or scripted solutions. For more information about this option, see Get bitlockerRecoveryKey.

In the following example, we use Microsoft Graph PowerShell cmdlet Get-MgInformationProtectionBitlockerRecoveryKey to build a PowerShell function that retrieves recovery passwords from Microsoft Entra ID:

For devices that are managed by Microsoft Intune, BitLocker recovery passwords can be retrieved from the device properties in the Microsoft Intune admin center. For more information, see View details for recovery keys.

To export a recovery password from AD DS, you must have read access to objects stored in AD DS. By default, only Domain Administrators have access to BitLocker recovery information, but access can be delegated to specific security principals.

To facilitate the retrieval of BitLocker recovery passwords from AD DS, you can use the BitLocker Recovery Password Viewer tool. The tool is 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.

If devices are configured with a DRA, the Helpdesk can use the DRA to unlock the drive. Once the BitLocker drive is attached to a device that has the private key of the DRA certificate, the drive can be unlocked by using the manage-bde.exe command.

If a device experiences multiple recovery password events, an administrator should perform post-recovery analysis to determine the root cause of the recovery. Then, refresh the BitLocker platform validation to prevent entering a recovery password each time that the device starts up.

If a user needed to recover the drive, it's important to determine the root cause that initiated the recovery as soon as possible. Properly analyzing the state of the computer and detecting tampering might reveal threats that have broader implications for enterprise security.

While an administrator can remotely investigate the cause of recovery in some cases, the user might need to bring the device that contains the recovered drive on site to analyze the root cause further. Here are some questions that can be used to help determine the root cause of the recovery:

To help answer these questions, you can use the manage-bde.exe -status command to view the current configuration and protection mode. Scan the event log to find events that help indicate why recovery was initiated (for example, if a boot file change occurred).

The details of the reset can vary according to the root cause of the recovery. If root cause can't be determined, or if a malicious software or a rootkit infects the device, the helpdesk should apply best-practice virus policies to react appropriately.

If the USB flash drive that contains the startup key is lost, you can unlock the drive using the recovery key. A new startup can then be created using PowerShell, the Command Prompt, or the BitLocker Control Panel applet.

This error occurs if the firmware is updated. BitLocker should be suspended before making changes to the firmware. Protection should then be resumed after the firmware update is complete. Suspending BitLocker prevents the device from going into recovery mode. However, if changes happen when BitLocker protection is on, the recovery password can be used to unlock the drive and the platform validation profile is updated so that recovery doesn't occur the next time.

Administrators can configure a policy setting to enable automatic recovery password rotation for Microsoft Entra joined and Microsoft Entra hybrid joined devices.
When automatic recovery password rotation is enabled, devices automatically rotate the recovery password after the password is used to unlock the drive. This behavior helps to prevent the same recovery password from being used multiple times, which can be a security risk.

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.

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.

Damage to the drive may not be related to BitLocker. Therefore, it's recommended to try other tools to help diagnose and resolve the problem with the drive before using the BitLocker Repair Tool. The Windows Recovery Environment (Windows RE) provides more options to repair Windows.

To export a key package from AD DS, you must 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.

I have a laptop running Windows 7 Ultimate. I have encrypted my drives using BitLocker. Now I have also installed Lubuntu along with Windows. But my encrypted drives are not visible in Linux. How can I fix this?

My problem was that I could not boot Windows, and I needed a way to access my files on a Bitlocked partition. In order to do this, you need a bitlocker recovery password (8 groups of digits) and the ability to boot your system from USB.

CryptSetup has added experimental support for BitLocker as of version 2.3.0 (February 2020), which is available in Ubuntu's repos for 20.10 Groovy onwards, although support will likely improve in later versions.

When setting up BitLocker on a device choose the option that encrypts the whole device (requires more time). The other option uses Encrypt-On-Write conversion model that makes sure that any new disk writes are encrypted as soon as you turn on BitLocker (data that existed on the device before encryption began can still be read and written without encryption) and is not supported by Cryptsetup.

Once the drive is decrypted, you can use TrueCrypt instead; reading a System Encryption volume under Linux isn't supported by default, but someone has figured out a work-around. See How to use TrueCrypt-encrypted Windows system drives on Linux.

I tried @SrjCoder's suggestion of using a VM. But with VirtualBox on the Linux host, I was not able to see the encrypted drive in the guest Windows system. The unmounted block device that had the encrypted drive was not visible in the VM. I didn't try VMware, and I'm not a VirtualBox expert, so maybe I missed something there.