Configuration Manager Bitlocker Management: data drives during OSD

Question

I'm trying to figure out how BitLocker Management is supposed to work for fixed data drives in case of a re-installation.
I would like to keep the data on fixed data drives (configured for auto-unlock) while formatting the system drive during OSD. It should work from PE-Boot in case the system doesn't boot from the disk anymore. Is there any way to do this using Bitlocker Management in Configuration Manager?
For the system drive and maybe for initial encryption of data drives, I thought about using the Invoke-MbamClientDeployment.ps1 script during OSD.

As far as I understand it, the decryption key for data drives is stored on the system drive. This obviously gets lost during formatting and might not be accessible in the first place if the system isn't bootable anymore. Does the BitLocker Management agent have some functionality to obtain the recovery keys from the ConfigMgr database and restore access to the data drive(s) or does this require manual steps (getting the recovery keys from the self service portal or through the helpdesk)?
What would be the recommended approach to restore (reinstall) such a system?

Are there any more advanced approaches that could work? I'm thinking about providing the recovery key(s) as a TS variable or getting the key(s) from a web service after OSD. Both approaches seem complicated an potentially insecure.

Answer 1

But to my understanding I would first need to unlock the data drive before I can add an additional protector or re-enable auto-unlock.

Yes.

Therefore the only remaining way to unlock the drive would be using the recovery password from the self service website

Yes, but you can also just disable protection on the volume in the OS before the system volume is wiped as part of the TS.

This is the pain of having additional data drives or volumes and hopefully by now you are questioning their value.

Answer 2

Don't conflate the auto unlock keys with recovery keys -- they are equivalent keys to my knowledge but not the exact same keys. You'll most likely have to reenable auto lock during the TS using the Enable-BitLockerAutoUnlock cmdlet.

But to my understanding I would first need to unlock the data drive before I can add an additional protector or re-enable auto-unlock. Right?
And to my knowledge the data drive can only be unlocked with either the information on the system drive (which is lost after formatting) or the recovery password (which would require manual steps). I'm assuming Network Unlock is not used.
The TPM protector only unlocks the system drive but can't unlock the data drive directly. Therefore the only remaining way to unlock the drive would be using the recovery password from the self service website (or through the helpdesk). Only after that manual step, it should be possible to re-enable auto-unlock using the cmdlet or the GUI.
Am I missing something?

Answer 3

Terminology is super important as I can only read what you write.

Does the Bitlocker Management Agent get any recovery information from the database in order to unlock the data drive?

As noted, no. That's not how it works. BitLocker recovery key information flows in one direction only with ConfigMgr, MBAM, or AAD. The only way for BitLocker to query an external system to unlock a volume is if you use the BitLocker Network Unlock service.

Will users just have access to data drives without any manual actions?

Don't conflate the auto unlock keys with recovery keys -- they are equivalent keys to my knowledge but not the exact same keys. You'll most likely have to reenable auto lock during the TS using the Enable-BitLockerAutoUnlock cmdlet.

Answer 4

this statement is incorrect: "As far as I understand it, the decryption key for data drives is stored on the system drive."

Maybe I wasn't quite correct with the exact terminology. What I meant is that auto-unlock uses data stored on the C (system) drive to unlock the D (data) drive.

BitLocker stores these keys for the fixed data drives of a system on a volume that hosts a BitLocker-enabled operating system volume so that it can automatically unlock the fixed and removable data volumes in a system. This makes it easier for users to access data volumes.

Source: https://learn.microsoft.com/en-us/powershell/module/bitlocker/clear-bitlockerautounlock?view=windowsserver2019-ps

No. Does conflate the recovery key and encryption key. They are two different things. Also, there is no decryption key as this is symmetric encryption.
You shouldn't have to do anything special here at all to my knowledge to handle this scenario.

Ok some errors with terminology on my part. When talking about getting the recovery keys from the self service portal, I actually meant the recovery password ("48-digit number used to unlock a volume when it is in recovery mode").
I'm not quite sure I understand what you are saying, though. Does the Bitlocker Management Agent get any recovery information from the database in order to unlock the data drive? What's that "nothing special" exactly? Will users just have access to data drives without any manual actions?

Thanks a lot for your time! :)

Answer 5

I don't have a full answer here to the entire scenario, but this statement is incorrect: "As far as I understand it, the decryption key for data drives is stored on the system drive."

From https://learn.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-key-management-faq#where-are-the-encryption-keys-stored:

The full volume encryption key is encrypted by the volume master key and stored in the encrypted drive. The volume master key is encrypted by the appropriate key protector and stored in the encrypted drive.

• Does the BitLocker Management agent have some functionality to obtain the recovery keys from the ConfigMgr database and restore access to the data drive(s) or does this require manual steps (getting the recovery keys from the self service portal or through the helpdesk)?

No. Does conflate the recovery key and encryption key. They are two different things. Also, there is no decryption key as this is symmetric encryption.

You shouldn't have to do anything special here at all to my knowledge to handle this scenario.