I have seen several blog posts on how to unlock a BitLocker encrypted drive from Windows PE, using the recovery password stored in the Microsoft Bitlocker Administration and Monitoring (MBAM) SQL Server database.
What's the problem with these solutions?
All of these have one thing in common: they query the SQL database directly, requires changing SQL Server configuration and granting access to the database directly.
Why is this a problem?
Well, in my opinion this is a bad design approach, as the core purpose of implementing BitLocker volume encryption and MBAM is to secure our data from being compromised.
By allowing a user to directly query the MBAM recovery database from Windows PE, I have also exposed ALL of my recovery keys for ALL of my disk volumes in the entire enterprise, it is as easy as issuing a SELECT * FROM RecoveryAndHardwareCore.Keys query!
Some of these solutions also require that the SQL Server must be configured for basic authentication, which many a DBA will tell you is a bad practice that they will not allow…
To make things worse, the username and password for the SQL user that executes the query, is written I clear text in the script used to unlock the drive…
For these reasons I have not implemented any refresh scenarios that use offline USMT and hard links from Windows PE at my customers, as these solutions would require the unlock of the BitLocker protected volume. Well I finally got the time to attack this issue, and find a better solution.
The better solution (not perfect, but better)
Well we don’t need to query the database directly, MBAM has provided us with web based helpdesk interface that allows us to request the Recovery Password for a given volume if we provide the ID of the password. This helpdesk interface communicates with the recovery database through a WCF service, using its own application pool credentials.
To be able to use the helpdesk interface and service, the requestor must be member of active directory groups that grants them access to perform the request, ensuring that only authorized staff can access the recovery keys. In addition the request is logged in the MBAM audit database, allowing the security team to screen and identify the disclosure of recovery keys.
So this is what I came up with:
- A single script that can be added as a single step to your task sequence
- Uses WMI to get the status of the volume, no need to unlock if bitLocker is not active.
- Does not rely on piping output manage-bde.exe result to text file before parsing it to get the recovery password ID. WMI can provide this directly.
- Only requests the recovery password for the current encrypted volume based on its recovery Password ID, no way to disclose recovery keys for other volumes.
- Authenticates to the MBAM web service using windows credentials, with the Configuration Manager Network Access Account (NAA)
- Allows for full audit logging in the MBAM audit database
- Does NOT require any changes to MBAM backend, SQL Server or specifying passwords in clear text.
How to use in 3 easy steps
In this scenario, I needed to allow the use of offline USMT, that is backup user profiles from WinPE as opposed to the full running OS, but the script can be used in ANY scenario where the drive needs to be unlocked from Windows PE.
Add the script to the boot media. As the task sequence can’t download content to an encrypted disk, we need to make the script available in the boot image.
Place the UnlockDriveFromWinPE.wsf script along with the ZTIUtility.vbs script from the MDT toolkit in a prestart content folder on the ConfigMgr content share. In this case I placed them in the existing folder used with the Coretech HTA prestart scripts.
On the properties page of your boot image, go to the Customization tab and specify the path to the folder containing the script.
Notice that a command line must be entered, in this case there is already a prestart command defined, the Coretech HTA script. Just throw in a “ping.exe 127.0.0.1” if there is not already a script defined.
Update the boot image on the distribution points to include the new files.
As the script uses the network access account (NAA) defined in Configuration Manager to authenticate to the MBAM administration service, the NAA account must be added to the MBAM Advanced Helpdesk Users Active Directory security group.
Add the script to your task sequence. As mentioned earlier, I used this script in a task sequence where the USMT must be run in offline mode in Windows PE.
Just after the Restart in Windows PE (which has a condition only to run if NOT in WinPE). Add a Run Command Line step
The command line calls the script placed in the SMS10000 folder (the prestart files) with two arguments: the drive to unlock and the url and port of the MBAM server containing the web site.
cscript.exe X:\sms\pkg\SMS10000\UnlockDriveFromWinPE.wsf /Drive:C: /MBAMServerUrl:https://mbam.domain.local:4443
Note that port is not necessaryto specyfy the port number if using port 80 (http) or 443 (https), but in this case the MBAM web site was listening on a special port, namely port 4443.
That’s IT! the drive will now be unlocked if BitLocker has been applied to the volume, and the recovery key exist in the MBAM database.
After deploying the task sequence, any attempt to acquire the recovery password is logged in the MBAM compliance database, and can be audited by viewing the audit reports from the MBAM Helpdesk Portal.
Download the script here: