The msFVE-RecoveryPassword attribute stores the 48-digit BitLocker recovery password for an encrypted volume. It lives on msFVE-RecoveryInformation child objects that Active Directory (AD) creates automatically under a computer object whenever BitLocker is configured to back up its recovery key to AD DS. The attribute is classified as confidential, meaning standard AD read permissions are not sufficient to retrieve it: callers need an explicit Control Access right in addition to Read, which limits retrieval to Domain Admins and explicitly delegated accounts by default.
This article covers what msFVE-RecoveryPassword is, how the BitLocker key escrow structure works, and how to view and manage it using Active Directory Users and Computers (ADUC), PowerShell, and ManageEngine ADManager Plus.
| LDAP display name | msFVE-RecoveryPassword |
| CN | ms-FVE-RecoveryPassword |
| Syntax | String (Unicode), attributeSyntax 2.5.5.12, omSyntax 64 |
| Attribute ID (OID) | 1.2.840.113556.1.4.1964 |
| System ID GUID | 43061ac1-c8ad-4ccc-b785-2bfac20fc60a |
| Single- or multi-valued | Single-valued |
| Maximum length | 256 characters |
| Indexed | No |
| In Global Catalog | No |
| Replicated | Yes, to writable DCs within the domain. Filtered from RODCs (fRODCFilteredAttribute). |
| Confidential attribute | Yes—requires Read + Control Access right to retrieve. Standard authenticated-user read access is not sufficient. |
| Preserved on deletion | Yes (fPRESERVEONDELETE)—the value survives tombstoning of the parent object. |
| System-Only (writable) | False—BitLocker writes it automatically; admins can also write it via manage-bde or PowerShell. |
| Applies to | msFVE-RecoveryInformation class (child objects of computer objects) |
| First implemented | Windows Server 2008 |
| Source schema | Microsoft core AD schema (BitLocker / Full Volume Encryption) |
| Microsoft reference | Win32 ADSchema · MS-ADA2 · ms-FVE-RecoveryInformation class |
Important: msFVE-RecoveryPassword carries the fCONFIDENTIAL search flag. Reading it requires both the Read permission and the Read msFVE-RecoveryPassword Control Access right on the msFVE-RecoveryInformation object. Domain Admins have this right by default. Standard users, even those with generic read-all rights on the computer OU, cannot retrieve the value. Do not grant this right broadly; treat it as equivalent to granting access to the encrypted data on the disk.
Understanding msFVE-RecoveryPassword requires understanding the object hierarchy it lives in. The attribute does not sit directly on the computer object. When BitLocker backs up a recovery key to AD, Windows creates a new child object of class msFVE-RecoveryInformation under the computer object in AD DS. Each such child object holds exactly one recovery password, identified by a GUID that forms part of the object's CN.
A typical distinguished name for a BitLocker recovery information object looks like:
CN=2024-03-15T08:42:11-05:00{A1B2C3D4-E5F6-7890-ABCD-EF1234567890}, CN=LAPTOP-01,OU=Workstations,DC=contoso,DC=com
The CN encodes the timestamp of when the key was backed up and the Recovery Key ID (GUID) in braces. Multiple child objects can exist under one computer if the key has rotated.
The msFVE-RecoveryInformation class has two mandatory attributes:
Two optional attributes may also be present on the child object:
Note: A computer object can have multiple msFVE-RecoveryInformation child objects if BitLocker has rotated its recovery key, if multiple volumes are encrypted, or if the key was manually rotated. When retrieving recovery passwords, sort by whenCreated descending to identify the most recently backed-up key.
msFVE-RecoveryPassword was introduced in Windows Server 2008 alongside BitLocker Drive Encryption in Windows Vista. Its purpose is to give organizations a centralized, auditable location to store BitLocker recovery keys for domain-joined computers. This helps desk staff retrieve a recovery password when a user is locked out of their encrypted device without the need for out-of-band key management solutions.
Common operational scenarios that involve this attribute:
AD DS vs. Microsoft Entra ID escrow: On Entra-joined or hybrid-joined devices, BitLocker recovery keys are typically escrowed to Microsoft Entra ID rather than AD DS, and are retrievable from the Microsoft Entra admin center or via the Microsoft Graph API. AD DS escrow applies to domain-joined devices managed via Group Policy. Both can coexist in a hybrid environment, but they are separate stores. Verify your BitLocker GPO settings to confirm where keys are being sent.
ADUC exposes BitLocker recovery information through the BitLocker Recovery tab on computer object properties, but only after the BitLocker Recovery Password Viewer RSAT feature is installed. Without this feature, the tab does not appear and the recovery objects cannot be viewed through the ADUC interface.
To search by Recovery Key ID when you do not know the computer name:
Because msFVE-RecoveryPassword lives on msFVE-RecoveryInformation child objects rather than on the computer object itself, you always use Get-ADObject with ObjectClass -eq 'msFVE-RecoveryInformation' to retrieve it. Run PowerShell as an elevated session under an account with the Read msFVE-RecoveryPassword Control Access right; otherwise the attribute returns empty.
$computerDN = (Get-ADComputer -Identity LAPTOP-01).DistinguishedName
Get-ADObject -Filter {objectClass -eq 'msFVE-RecoveryInformation'} `
-SearchBase $computerDN `
-Properties 'msFVE-RecoveryPassword', whenCreated |
Sort-Object whenCreated -Descending |
Select-Object Name, 'msFVE-RecoveryPassword', whenCreated
Returns all BitLocker recovery passwords for LAPTOP-01, sorted newest first. The Name column contains the CN which encodes the Recovery Key ID.
$keyID = "A1B2C3D4" # First 8 characters from the BitLocker recovery screen
Get-ADObject -Filter {objectClass -eq 'msFVE-RecoveryInformation'} `
-Properties 'msFVE-RecoveryPassword', 'cn' |
Where-Object { $_.cn -match $keyID } |
Select-Object Name, 'msFVE-RecoveryPassword'
Searches the entire domain for an msFVE-RecoveryInformation object whose CN contains the specified Recovery Key ID fragment. Use when you know the key ID but not the computer name.
Get-ADObject -Filter {objectClass -eq 'msFVE-RecoveryInformation'} `
-Properties 'msFVE-RecoveryPassword', whenCreated |
ForEach-Object {
$computer = ($_.DistinguishedName -replace '^CN=.+?,(?=CN=)') -replace ',.*$'
[PSCustomObject]@{
Computer = $computer
RecoveryKeyID = ($_.Name -replace '^.+{|}.*$')
CreatedDate = $_.whenCreated
HasPassword = $null -ne $_.'msFVE-RecoveryPassword'
}
} | Export-Csv .\bitlocker-escrow-audit.csv -NoTypeInformation
Enumerates all msFVE-RecoveryInformation objects in the domain, extracts the computer name and Recovery Key ID from the DN and CN, and exports a coverage audit to CSV.
$ouDN = 'OU=Workstations,DC=contoso,DC=com'
$withKeys = (Get-ADObject -Filter {objectClass -eq 'msFVE-RecoveryInformation'} `
-SearchBase $ouDN -SearchScope Subtree |
ForEach-Object { ($_.DistinguishedName -split ',CN=')[1] }) | Sort-Object -Unique
Get-ADComputer -Filter * -SearchBase $ouDN |
Where-Object { $_.Name -notin $withKeys } |
Select-Object Name, DistinguishedName |
Export-Csv .\no-bitlocker-escrow.csv -NoTypeInformation
Identifies domain-joined computers in the specified OU that have no BitLocker recovery key escrowed in AD DS. Use this to target devices for manual key backup.
# Run on the target computer (requires elevation)
$keyID = (Get-BitLockerVolume -MountPoint 'C:').KeyProtector |
Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' } |
Select-Object -ExpandProperty KeyProtectorId
manage-bde -protectors -adbackup C: -id $keyID
Retrieves the Recovery Key ID for the C: drive and uses manage-bde to back up the existing recovery password to AD DS. Run on the target computer with local admin rights.
$staleKey = 'CN=2019-01-10T09:00:00-05:00{OLDGUID},CN=LAPTOP-01,OU=Workstations,DC=contoso,DC=com'
Remove-ADObject -Identity $staleKey -Confirm:$true
Removes a specific msFVE-RecoveryInformation object. Use when cleaning up stale keys after a device has been wiped or decommissioned. Always confirm the current key exists before deleting historical
ADManager Plus supports BitLocker recovery key management through its computer management and reporting workflows, giving help desk staff and security teams a centralized interface to retrieve and audit msFVE-RecoveryPassword values without requiring PowerShell access or Domain Admin rights.
To allow help desk staff to retrieve BitLocker recovery passwords for computers in a specific OU, without granting Domain Admin rights, use help desk delegation:
The msFVE-RecoveryPassword attribute grants access to the decryption key for a BitLocker-protected volume. Access to it is equivalent, in practical terms, to access to the data on the encrypted disk. Microsoft reflects this by marking the attribute fCONFIDENTIAL, which requires an explicit Control Access right to read, and fRODCFilteredAttribute, which prevents the value from replicating to RODCs where it could be exposed if a branch-office DC is physically compromised.
The BitLocker Recovery Password Viewer RSAT feature is not installed. Open Server Manager, go to Add Roles and Features, and install BitLocker Recovery Password Viewer under Remote Server Administration Tools > Feature Administration Tools > BitLocker Drive Encryption Administration Utilities.
The account running ADUC does not have the Read msFVE-RecoveryPassword Control Access right on the msFVE-RecoveryInformation object. Log in with a Domain Admin account, or confirm the help desk delegation has been configured correctly via Active Directory Users and Computers > right-click OU > Delegate Control, or via dsacls to verify the ACE is present.
The PowerShell session is running under an account that lacks the Read msFVE-RecoveryPassword Control Access right, or the session is targeting a RODC. Restart PowerShell as a Domain Admin, or use -Server <writable-dc-fqdn> to force the query to a writable DC.
BitLocker is either not enabled on the device, or the GPO to back up recovery keys to AD DS is not applied or was not applied before BitLocker was enabled. Check the BitLocker GPO (Computer Configuration > Policies > Windows Settings > Security Settings > BitLocker Drive Encryption > Choose how BitLocker-protected drives can be recovered) and confirm it is applied to the device. For devices encrypted before the GPO was in place, run manage-bde -protectors -adbackup C: -id <KeyID> on the target device to manually escrow the existing key.
Sort the objects by whenCreated descending. The most recently created object contains the current recovery password. Older objects correspond to previous keys that have since been rotated. Once you have confirmed the current key is backed up, you can remove stale objects using Remove-ADObject as part of routine hygiene.
The BitLocker key may have been rotated on the device after the password was escrowed to AD, and the new key was not successfully backed up. Check for a more recent msFVE-RecoveryInformation object (higher whenCreated timestamp) under the computer object. If none exists, you may need to use msFVE-KeyPackage data recovery tools, or if those are unavailable, the drive data cannot be recovered without the key.
ADManager Plus gives your help desk staff a secure, auditable interface to retrieve BitLocker recovery passwords, audit escrow coverage across OUs, and delegate recovery key access without granting Domain Admin rights. Every retrieval is logged in the ADManager Plus audit trail.
Only Domain Admins and the SYSTEM account have the Read msFVE-RecoveryPassword Control Access right by default. Any other account, including those with standard read permissions on the computer OU, will see an empty value when querying the attribute. Delegation must be configured explicitly for help desk accounts.
It replicates to all writable DCs within the domain but not to RODCs. The fRODCFilteredAttribute flag prevents the value from being included in RODC replication, reducing exposure in branch-office scenarios where physical DC security cannot be guaranteed.
A 48-digit numeric key displayed in eight groups of six digits, separated by hyphens (for example, 465762-121880-049797-598411-533643-549890-128436-549736). Each group is divisible by 11, which allows BitLocker to detect transcription errors when a user types the key manually.
Yes, technically the same password remains valid until the key is rotated. However, Microsoft recommends treating any used recovery password as compromised and rotating the BitLocker key immediately after it has been used to unlock a device.
No. msFVE-RecoveryPassword is an on-premises AD DS attribute and is not synchronized to Microsoft Entra ID by Microsoft Entra Connect. BitLocker recovery keys for Entra-joined or hybrid-joined devices are stored in Microsoft Entra ID and are retrievable via the Entra admin center or Microsoft Graph API, not from AD DS.
Because the attribute carries the fPRESERVEONDELETE flag, the msFVE-RecoveryInformation child objects and their msFVE-RecoveryPassword values persist in the AD tombstone for the duration of the tombstone lifetime (default 180 days). After tombstone expiration they are permanently purged. This means recovery keys for recently decommissioned computers remain available for a grace period, but it also means stale keys accumulate and should be cleaned up as part of device offboarding.