3 Things You Should Know Before Deploying BitLocker with Intune

In my previous blog, I walked through the basics of getting started deploying BitLocker with Intune. Now, I want to share a few more lessons learned after going down this path myself. So before you embark on deploying BitLocker with Intune (MEM), here are three things you should know.

Table of Contents

• Automatic Encryption Requires a Logged-in User
  • Pre-Encryption BitLocker Script
  • SCCM/MDT Pre-Provision BitLocker
  • Conditional Access Rule
• Escrowing Keys to Azure AD
• Multiple BitLocker Keys
  • Removing Multiple Keys
• Wrap Up

Automatic Encryption Requires a Logged-in User

The BitLocker profile configured in the Endpoint Security center deploys as a device profile. This means that the settings will successfully apply to the device without any user logged in. It doesn’t matter if the device is Hybrid Azure AD or Azure AD joined. Makes sense right?

What is not expected though is the fact that BitLocker encryption simply will not turn on even though “Enable full disk encryption for OS and Fixed Data Drives” is set in the profile.

It will wait for a user log-in event to happen before it triggers encryption and escrowing of the BitLocker key to Azure. For some use cases, like Autopilot with Azure AD join, this may not matter too much as enrollment is happening at the same time the user is logging in. But for Hybrid Azure AD joined systems, this can become a bigger problem as the user log-in part can be delayed.

At my org, we require all systems to be fully encrypted (and verified as such) before handing off to the new user. I spent hours trying to figure out why the device wasn’t encrypting even though all of the BitLocker settings (including “RequireEncryption” ) were on the client. It wasn’t until I logged in with a user account that BitLocker would kick-off. I also verified this behavior with Microsoft. I am not sure if this was intentionally designed this way or just an oversight by the devs.

There are a few ways you can mitigate this:

Pre-Encryption BitLocker Script

You can deploy a PowerShell script that leverages the BitLocker PowerShell cmdlets to enable encryption. The MSEndpointMgr blog has a great guide on how to do this with Autopilot.

I also have a script that does nearly the same thing. You can deploy via Intune PowerShell or another method if you are doing OSD with MDT or a similar tool.

SCCM/MDT Pre-Provision BitLocker

If you are using SCCM, check out Gary Blok’s blog on how to enable BitLocker during a Task Sequence. And for MDT, check out the MS docs or use my script above during the task sequence.

Conditional Access Rule

You can also set up a compliance policy tied to a conditional access rule that will block access to corporate resources if the device isn’t encrypted. While this can work, the compliance evaluation requires an additional reboot for it to take effect. And not only that, setting up a conditional access rule to block access to company resources can be a VERY impactful thing. Be sure to test extensively. Here is a good blog that goes into more detail on conditional access.

One person on Twitter noted that they show a toast notification asking the user to reboot as soon as BitLocker is done in order to be in a compliant state (since compliance for BitLocker requires a reboot). Pretty cool idea!

We force reboot as soon the bitlocker is done with toast notification to end user that your device needs reboot to be in complaint state ☺

— Eswar Koneti | MVP (@eskonr) July 5, 2022

Now that we have a way to pre-encrypt the devices with BitLocker, we still need to save the key to Azure AD so that it can be accessed via Intune.

Escrowing Keys to Azure AD

Intune will only escrow the key if it is the one enabling BitLocker in the first place (i.e. after the user sign-in). If the BitLocker profile is already deployed to an encrypted system, Intune will not add its own key. To make this work you will need to use this PowerShell command:  BackupToAAD-BitLockerKeyProtector. This involves passing the “keyprotectorID” as a parameter so using a few lines of code can get the job done. I am using index 0 of the array just in case there are multiple recovery keys on the drive (more on that in the next section).

$BLV = Get-BitLockerVolume -MountPoint "C:" | select *
[array]$ID = ($BLV.KeyProtector | Where-Object {{ $_.KeyProtectorType -eq 'RecoveryPassword' }).KeyProtectorId
BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $ID[0]

Simply deploy this script via Intune and it will backup the key that was put in place from your initial pre-encryption process. The recovery key will then be accessible via Intune.

Multiple BitLocker Keys

At my org, we were migrating from McAfee Management of Native Encryption (MNE) to Intune. As part of testing, I began to see an odd issue: multiple recovery keys were appearing on systems. Since I knew that Intune doesn’t add its own key to already encrypted systems, I was very confused as to what could be causing it. I would find systems with two, three, or even eight recovery keys on the OS drive. For example, one system looked like this:

I confirmed the keys were saved locally on the device as well (running manage-bde -protectors -get c:). After further testing, I was able to reproduce the issue:

If you suspend BitLocker and then “sync” Intune, Intune will re-enable encryption. This is good. But what isn’t good is that it also “adds” an additional key protector to the system. You can keep doing this and it will add a new key each time. And per Maurice Daly on Twitter, you can get all the way up to 200 keys!

And when it hits 200 keys, you can no longer rotate or force an escrow against the device… Worst case scenario of course

— Maurice Daly [MVP] (@modaly_it) May 19, 2022

I reached out to Microsoft on this and apparently it is not the intended behavior so hopefully, a fix is coming soon.

One of the main reasons I was very concerned about this is because we were suspending BitLocker during BIOS updates in order to prevent the device from going into recovery mode. Did you know that this is no longer necessary assuming you have devices on UEFI with Secure Boot enabled? If you run the command manage-bde -protectors -get c: in an elevated window and you have PCR Validation Profile set to 7,11 (Uses Secure Boot for integrity validation), then suspending BitLocker is not required for servicing the BIOS. Pretty awesome! You can read all the nitty-gritty details on how this works on this Microsoft page.

Removing Multiple Keys

If you’d like to clean out multiple keys on the client, you can run this PowerShell script. It will skip the first key and delete the rest.

$BLV = Get-BitLockerVolume -MountPoint "C:" | select *

[array]$ID = ($BLV.KeyProtector | Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' }).KeyProtectorId

if($ID.Length -gt 1){

#looping through all the keys IDs, but skipping the first one.

foreach($item in ($id | select -skip 1)){

    $item

    Remove-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $item

    }

}

If you want more information on how to deal with BitLocker recovery keys leveraging Graph API, here is a pretty good blog to get you started.

Wrap Up

And that’s it! Now you know that BitLocker encryption won’t kick off without a user logging in, how to mitigate that with a pre-encryption script, how to escrow keys into Azure AD as well as how to deal with multiple BitLocker keys saved on the device.