Store BitLocker Recovery Keys in Active Directory

10.3K

The Active Directory database can be used as a central location to store BitLocker recovery keys. You can configure Group Policy (GPO) to automatically save the recovery keys for BitLocker-enabled computers in AD. Administrators can then securely retrieve recovery keys for computers from AD and unlock the encrypted device drives in case a user forgets a BitLocker password.

BitLocker Management Landscape

Nowadays, the AD is no longer the primary/recommended system for BitLocker recovery key management. Today when managing BitLocker you have better cloud-based solutions:

• Microsoft Intune. It is the primary replacement for MBAM.
• Microsoft BitLocker Administration and Monitoring (MBAM) is deprecated.
• In Entra ID joined and hybrid joined environments, BitLocker recovery keys are commonly escrowed to Entra ID through Intune/device enrollment policies.

AD–based BitLocker key storage is now usually used for:

• Legacy on-premises environments
• Hybrid domain-joined devices
• Isolated/air-gapped networks

For organizations that are planning new deployments, we recommend prioritizing Intune-based BitLocker management and Entra ID recovery key escrow over legacy AD DS–based recovery storage whenever possible.

Decision rule

You should use AD DS BitLocker backup in the following cases:

• on-premises Active Directory only environment
• there is no cloud identity (Entra ID)
• your network is restricted/isolated

You should use Intune/Entra ID in the following cases:

• cloud or hybrid identity exists
• devices are Entra ID joined or hybrid joined
• Microsoft Endpoint Manager is available

Keep in mind that Entra ID/Intune is the default control plane for BitLocker recovery in modern Microsoft environments. AD DS is a legacy fallback, you should use it only in case cloud identity is not available.

Important. In case you are using Intune/Entra ID, you should skip all AD schema and GPO sections. In case you are using AD DS, skip Intune/Entra sections.

Environment Requirements and Active Directory Schema Validation

Before configuring BitLocker backup to AD, we recommend you to check if the AD schema has been extended properly and that BitLocker-related attributes are present at the schema level.

Note that BitLocker recovery key storage method depends on environment architecture. You should choose one:

• On-premises AD DS (legacy/hybrid)
• Microsoft Entra ID (cloud-native)
• Intune-managed BitLocker policies (this one is recommended modern approach)

Environment requirements

• Windows 10 or 11 computers running Pro, Education or Enterprise editions;
• The Active Directory schema should contain a set of custom computer object attributes for storing BitLocker recovery keys. These schema attributes are available in AD schema versions introduced with Windows Server 2008 and later (provided the forest schema has been updated appropriately).

To check schema version:

(Get-ADObject `
(Get-ADRootDSE).schemaNamingContext `
-Properties objectVersion).objectVersion

This checks the AD schema version to ensure schema extensions are applied at the forest level. Keep in mind that the Schema version is informational only (you should validate BitLocker readiness using ldapDisplayName presence check).

To check BitLocker schema extension presence, run the following:

$schemaNC = (Get-ADRootDSE).schemaNamingContext
Get-ADObject $schemaNC -Property objectVersion, name
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
-Filter "ldapDisplayName -like 'msFVE*'" `
-Properties ldapDisplayName |
Select-Object ldapDisplayName

BitLocker AD readiness validation should include:

1. Verifying schema version
2. Confirming the presence of BitLocker-related attributes (msFVE*)
3. At last, checking the operational readiness with the command:
   

   Get-ADReplicationFailure -Target * -Scope Forest
   Get-ADReplicationPartnerMetadata -Target * | Select LastReplicationSuccess

Even in case schema attributes are present, BitLocker backup can still fail due to:

• missing GPO enforcement
• lack of computer write permissions
• incorrect OU targeting
• hybrid device not properly joined to AD DS

For successful BitLocker deployment, you should meet all of the following conditions:

• Recovery Password protector exists
• BitLocker protection status is On
• msFVE-RecoveryInformation object exists in AD
• Recovery password can be retrieved from ADUC/PowerShell

Required Active Directory Schema Attributes

There should be five following attributes:

• ms-FVE-KeyPackage
• ms-FVE-RecoveryGuid
• ms-FVE-RecoveryInformation
• ms-FVE-RecoveryPassword
• ms-FVE-VolumeGuid

If these attributes are missing, update the AD Schema.

Note that the presence of msFVE attributes does not guarantee successful BitLocker key escrow. You need to also validate replication consistency and OU-level permissions.

Configure Group Policy to Backup the BitLocker Recovery Keys to AD

To automatically back up the BitLocker recovery keys of computers to Active Directory, configure a domain GPO:

1. Open the Group Policy Management Console (gpmc.msc)
2. Create a new Group Policy Object (GPO) or edit an existing one. Ensure that the GPO is linked to the Organizational Unit (OU) containing the computer objects to which you wish to apply the BitLocker backup policy.
   In this example, I’m creating a new GPO named “BitLocker-WS-Policy” in the “Workstations” OU.
   

   

3. Edit the GPO and navigate to Computer Configuration → Policies → Administrative Templates → Windows Components → BitLocker Drive Encryption.
   

   

4. Enable the policy “Store BitLocker Recovery information in Active Directory Domain Services”. Check the option Require BitLocker backup to AD DS and select to store BitLocker Recovery passwords and key packages.
   

   

5. Next, select one of the following GPO folders, depending the drive types for which you want to make BitLocker recovery keys recoverable.
   • Operating System Drives
   • Fixed Data Drives
   • Removable Data Drives
     In this example, I’ll choose “Operating System Drives” and open the “Choose how BitLocker-protected system drives can be recovered” policy.
     

     

6. Select Enabled and tick the box “Do not enable BitLocker until recovery information is stored in AD DS for”. This policy allows BitLocker to start encrypting drives only after the restore information is saved to AD.
   

   

7. Wait for the new GPO settings to be applied or run the gpupdate /force command to apply the policy to a computer immediately. Check if the policy is applied:
   

   gpresult /r

Turn On the BitLocker Protection on a Windows Computer

Now enable BitLocker protection on a Windows client device and check that the recovery key is stored in AD.

Use one of the following ways to enable drive protection on Windows:

• Open the File Explorer, right-click on the drive, and select “Turn on BitLocker”. Follow the simple wizard steps to enable BitLocker encryption.
• Or enable BitLocker for a drive using PowerShell:

  Enable-Bitlocker -MountPoint c: -UsedSpaceOnly -SkipHardwareTest -RecoveryPasswordProtector

After enabling BitLocker, you must explicitly verify that the recovery key was successfully backed up to AD. Note that this step confirms real escrow success, not just policy config.

Step 1. Check protector existence

manage-bde -protectors -get C:

Step 2. Confirm escrow readiness state (IMPORTANT)

(Get-BitLockerVolume -MountPoint "C:").KeyProtector |
Where-Object {$_.KeyProtectorType -eq 'RecoveryPassword'}

Step 3. Validate that recovery information exists in AD (CRITICAL)

$ComputerDN = (Get-ADComputer $env:COMPUTERNAME).DistinguishedName

Get-ADObject `
-Filter {objectClass -eq 'msFVE-RecoveryInformation'} `
-SearchBase $ComputerDN `
-Properties 'msFVE-RecoveryPassword','whenCreated'

Note that even in case Group Policy is configured correctly, BitLocker recovery keys will not be stored in AD if:

• TPM is not ready/not initialized
• Recovery password protector was not created
• Your device was encrypted before policy was applied and manage-bde backup was not executed
• A machine has no write access to msFVE-RecoveryInformation object in AD

Manually Backup Existing Keys with manage-bde

If the drives were already encrypted before BitLocker Group Policy was enabled, you can use the manage-bde tool to manually send the recovery key to AD.

1. Get the numeric password ID for protected drive:
   

   manage-bde -protectors -get c:

2. Backup the key to the AD computer account:
   

   manage-bde -protectors -adbackup c: -id "{your_numerical_password_ID}"

How to Get the BitLocker Recovery Key from Active Directory

Using Active Directory Users and Computers (ADUC)

In order to view BitLocker recovery keys in Active Directory Users and Computers snap-in (ADUC), install the BitLocker Recovery Password Viewer tools.

On Windows Server, run the following command:

Install-WindowsFeature RSAT-Feature-Tools-BitLocker-BdeAducExt

On Windows 10/11 (RSAT Features on Demand):

Add-WindowsCapability -Online -Name Rsat.BitLocker.Recovery.Tools~~~~0.0.1.0

Run the ADUC (dsa.msc), open the target machine properties, and navigate to the BitLocker Recovery tab. It contains recovery passwords that you can provide to users to unlock their BitLocker-protected drive.

There is also a built-in Find BitLocker recovery password tool available in ADUC. Click Action → Find BitLocker recovery password. Enter the first eight characters of the password ID and click Search. If the partial password ID is valid, you will see the corresponding BitLocker recovery password, as shown below.

Using PowerShell to Retrieve Keys

Or, use PowerShell to get the BitLocker recovery key for an AD computer object:

$PCname = 'NY-PC123'

$ComputerDname = (Get-ADComputer $PCname).DistinguishedName

Get-ADObject -Filter {objectclass -eq 'msFVE-RecoveryInformation'} -SearchBase $ComputerDname -Properties *| select 'msFVE-RecoveryPassword', whenCreated

Search by Recovery ID

If you do not know the computer name, you can find the recovery key by using the ‘Recovery ID’:

$BitLockerGUID = '4beabab4-c3f9-4916-8a2b-d13d9e011936'

Get-ADObject `
-Filter {
objectClass -eq 'msFVE-RecoveryInformation' -and
msFVE-RecoveryGuid -eq $BitLockerGUID
} `
-Properties 'msFVE-RecoveryGuid', 'msFVE-RecoveryPassword', 'whenCreated' |
Select-Object DistinguishedName, msFVE-RecoveryGuid, msFVE-RecoveryPassword, whenCreated

Recovery Password Rotation

Recovery passwords should not remain valid indefinitely after they have been used. If a BitLocker recovery password is exposed/used to unlock a device, Microsoft supports automatic recovery password rotation for Microsoft Entra joined and Microsoft Entra hybrid joined devices.

In Microsoft Intune, you should config the Configure recovery password rotation policy:

• 1 – Rotate recovery password on use for Microsoft Entra joined devices
• 2 – Rotate recovery password on use for Microsoft Entra joined and Microsoft Entra hybrid joined devices

When enabled, Windows generates a new numeric recovery password after the existing recovery password is used and backs up the new recovery info to the configured recovery store.

The policy is provided through the BitLocker CSP (ConfigureRecoveryPasswordRotation) and is not available as a Group Policy setting. It requires recovery password backup to Microsoft Entra ID/AD DS to be configured as required.

Delegating Permissions to View BitLocker Recover Keys in AD

By default, only domain administrators can retrieve BitLocker recovery keys from AD.

Security note. Keep in mind that delegating read access to BitLocker recovery objects grants full access to encrypted data. This should be treated as high-privilege access equivalent to domain-level control in some environments.

Delegating Control in AD

You can delegate this task in Active Directory to your HelpDesk team.

1. Right-click on the Active Directory OU that contains the computer objects with BitLocker recovery keys and click Delegate Control.
   

   

2. Add the delegate group and click Next.
   

   

3. Select the “Create a custom task to delegate” option and click Next.
   

   

4. Select the “Only the following objects in the folder” option, tick the “msFVE-RecoveryInformation objects” box.
   

   

5. Select the “Read” permissions, as shown below, and click Next.
   

   

6. All users added to the “BitLocker Password Viewers” group can view the Recovery tab with BitLocker recovery information.

In case the command returns one or more msFVE-RecoveryInformation objects with populated msFVE-RecoveryPassword attributes, it means that the BitLocker recovery key was successfully escrowed to AD.

Wrapping up

Keep in mind that within large AD forests, schema validation should rely on schema metadata and ldapDisplayName queries rather than simple name matching (which may produce inconsistent results across domains/replicas).

You should always align your BitLocker recovery architecture with identity strategy:

• AD DS (legacy/hybrid)
• Entra ID (cloud-native)
• Intune (managed endpoint security platform)