Unlock BitLocker Encrypted Drive From WinPE the Secure Way!

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.

The result

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.

Step 1

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.

2016-10-07 12_54_25-Prestart

On the properties page of your boot image, go to the Customization tab and specify the path to the folder containing the script.

2016-10-07 12_49_02-ctsccm01.coretech.intra

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”  if there is not already a script defined.

Update the boot image on the distribution points to include the new files.

Step 2

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.

Step 3

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

2016-10-11 13_07_14-Greenshot

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.

2016-10-11 13_22_59-Microsoft BitLocker Administration and Monitoring_ Reports – Google Chrome

Download the script here: zip UnlockDriveFromWinPE.zip 32.62 kB
Downloaded 171 times

Comments (7):

  1. Brien says:

    Isn’t this elevating the network access account to a dangerous level? NAA should be just a Domain User according to MS. Anyone that gets the NAA password will be able to request recovery keys, correct?

  2. Henrik Rading Henrik Rading says:

    Yes that is correct, and that’s why I wrote “Not perfect, but better”.
    In my opinion it is better to use the NAA, as it requires some more effort to retrieve the password in clear text, than reading clear text user credentials in a script.
    If you prefer using other credentials you can specify two variables in your task sequence: WebServiceUserID=”domain\account” WebServicePassword=”password” these take precedence over NAA credentials.

  3. Jeff says:

    Did you consider trying to export the powershell module?

    • Henrik Rading Henrik Rading says:

      Yes I did… bit I had some trouble getting it to work from WinPE. Also the customer that I was at did not have Powershell and .NET in their boot image due to size, so a solution that would work with vbscript was preferred.

  4. Dawn says:

    I am trying to use this script and I receive the error:

    ZTI ERROR – Unhandled error returned by UnlockDriveFromWinPE: The data necessary to complete this operation is not yet available.
    (-2147483638 0x8000000A)

    Any suggestions on how I should troubleshoot this?

    Also, we are having issues with the MBAB recovery key not being in the database after “Invoke-MbamClientDeployment.ps1” script is run. I was thinking of modifying your script to see if I could determine if the database has been populated with this information. Do you have any suggestions?

    Thank you,

  5. Henrik Rading Henrik Rading says:

    Can’t say why you get this error, I have not seen that one before…
    Make sure that you can retrieve the cay manually through the helpdesk portal, this ensures that the webservices that the script uses are working.

    To validate that the recovery keys are in the database, just query the RecoveryAndHardwareCore.Machines and RecoveryAndHardwareCore.Keys tables.

  6. Christian says:

    Hi Henrik,
    I am using newest MBAM 2.5 SP1 + KB4014009. Here i get the following error :

    NAA credentials have been specified. InstallSoftware 25-07-2017 12:50:45 1900 (0x076C)
    Sending HTTP request to web service InstallSoftware 25-07-2017 12:50:45 1900 (0x076C)
    Process completed with exit code 91 InstallSoftware 25-07-2017 12:50:45 1900 (0x076C)
    –Attempt #1 InstallSoftware 25-07-2017 12:50:45 1900 (0x076C)
    Unexpected response from web service: 415 Cannot process the message because the content type ‘application/soap+xml; charset=utf-8’ was not the expected type ‘text/xml; charset=utf-8’. InstallSoftware 25-07-2017 12:50:45 1900 (0x076C)

    Any idea how to fix that ?

Leave a Reply