B for Bitlocker

This blog will discuss configuring Bitlocker and the Bitlocker recovery key and how to ensure they are escrowed to Azure/Entra. I will also show you what options you have to ensure your recovery keys are safe.

1. Configuring Bitlocker

Bitlocker is one of the many security measures you must implement to ensure the data is safe when the device is stolen. It encrypts the data on the device so it can’t be read without authenticated decryption using a recovery key.

There are multiple options available to turn on Bitlocker. I am going to show you two options here.

1. Endpoint Protection Profile
2. PowerShell

1.1 Endpoint Protection Profile

The first option I will show you explains how to turn on Bitlocker by creating a new Endpoint Protection Profile in Intune.

Please ensure you are configuring the requirement of “Encrypt Devices,” and don’t forget to hide the prompt about third-party encryption so that standard users can enable encryption during Azure AD / Entra Join.

Also, please make sure you configure the Bitlocker OS drive settings as shown below.

• Additional authentication at startup – Require
• BitLocker with non-compatible TPM chip – Block
• Compatible TPM startup – Require TPM
• Other Compatible TPM options – Do Not Allow!

Please Note: Configuring any of the other compatible TPM settings as required will cause silent encryption to fail! so make sure you configure those Compatible TPM Startup PIN and Key Settings to blocked

OLD BitLocker Policy

New BitLocker Policy

Also, please make sure you are saving the Bitlocker recovery information to Azure Active Directory. If this information is not escrowed, you could end up in a bad situation!

1.2. PowerShell

Let’s take a look at the second option, the PowerShell Option. Configuring BitLocker with PowerShell is very easy, just download the Zip below and upload the PowerShell script into Intune.

This PowerShell script will ensure that the contents of this script are moved to your device itself. Looking at the script below, you will notice it will try to turn on Bitlocker, depending on the encryption percentage.

It will make sure it is executed at each login to ensure your hard drive is secured with BitLocker.

This wonderful PowerShell script will also ensure that all media (Mounted ISOs, USB sticks) are ejected before the encryption kicks in.

Last but not least, this PowerShell script will also make sure that it will set all the necessary Bitlocker FVE Policies because, for example, we really want to have a backup of our recovery key before protection is enabled…

To finish it off, the PowerShell script will start the scheduled task and will wait until it’s fully encrypted. If it’s fully encrypted it will Backup the Bitlocker Key Protector to Azure Ad.

Please Note: I added a check to ensure the device is Azure Ad Joined. Otherwise, it couldn’t back up its recovery key, and you will end up with a PowerShell timeout during Autopilot Pre-Provisioning.

If you don’t want to use a PowerShell file on the disk itself (which is kind of obvious), you could also change a couple of lines and use an encoded command instead of a file.

2. Bitlocker Recovery Information

As shown earlier, it is very important to escrow the Bitlocker recovery key to Azure. Let me tell you why!

One downside is the support tickets that could be created when a user simply does not remember their password anymore and has tried it too many times.

Luckily, in a normal situation, you have ensured a backup of the recovery key in Azure. An admin could query the device to get the recovery key.

Or the end-user itself could log in to my account from any device to retrieve the recovery key

My Account (microsoft.com)

But wait, what if there is no backup in Azure Ad? How are you going to monitor this or ensure that a recovery key is always present?

3. Bitlocker Recovery key not Escrowed to AAD

This week we had a customer who entered the wrong password too many times. The device ended up booting into the Bitlocker screen. So as the good admins we are, we opened the Azure Active Directory to look up the recovery key but no single recovery key was available!!!

At that point, I was very glad we were also using Solarwinds/N-Able to monitor the devices. One of the scripts we made sure was implemented was to show the recovery key in Solarwinds. The end-user was very grateful to get the recovery key so he could get back to work. The problem is solved, you might think, but I was very curious why there wasn’t a backup recovery key available.

We started searching, and the first place we looked was the Bitlocker event log. It showed us the event 846 with a nice error: Unknown HResult error code: 0x801c0450

This is the problem. Googling the error did not result in any useful hits. It only mentioned the fact that Secure Boot needs to be enabled, but I guess that’s a no-brainer because we also required secure boot in a compliance policy.

Besides using the GUI you could also use PowerShell to query the event log:

Let’s try to reproduce the error and try to back up/escrow the recovery key again. We opened a PowerShell session and launched this script.

$BLV = Get-BitLockerVolume -MountPoint "C:" | select *
BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[1].KeyProtectorId

And the backup of the recovery key was done?

That’s odd because when the device was enrolled the same script did not do its job.  To be sure, we checked all the other devices in the company but all the devices had their recovery key uploaded.

Please note that sometimes even manually running that BackupToAAD script isn’t working. If it’s not working you will also notice the event 846 in the event log but this time with an “Access is denied” error

(Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

If that’s the case, a proxy could be configured. Please make sure you can access this URL from the device that is experiencing the issue

http://enterpriseregistration.windows.net

4. Fixing the Escrow

As stated before, for now, we are using Solarwinds. But what if you don’t have Solarwinds monitoring configured? I am going to show multiple options on how you can make sure the recovery key is safe.

1. Powershell / Win32 Bitlocker Script
2. Intune Device Configuration
3. Proactive Remediation

4.1.Powershell Script

Using PowerShell, you can ensure Bitlocker is enabled and configured on the device. Adding a task schedule to the PowerShell script and deploying it has some benefits.

Normally, when BitLocker fails to back up the key to Azure, it will not try again, and you will end up with a device without BitLocker. But with this Win32app/Powershell script, which I also showed you earlier, you can be pretty sure it will try to encrypt the device and back up the key to Azure each time you log in. It will use the BackupToAad PowerShell command. Even when you forget to unplug the installation media, this is no problem at all.

if($BLinfo.EncryptionPercentage -eq '100'){
$BLV = Get-BitLockerVolume -MountPoint "C:" | select *
BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[1].KeyProtectorId
}

Download Link: (Powershell script and the PowerShell Script converted to a Win32 App)

https://call4cloud.nl/wp-content/uploads/2021/05/Windows10_enalebitlocker.zip

The script also contains some policies to make sure the backup is required before encryption. One of the policies is also necessary when you want to manually perform a key rotation

4.2. Intune

I prefer using Intune as much as possible to deploy settings. It’s a lot easier when every setting or configuration on the device is visible in one place.

Changing your configuration is much easier within the Intune portal than using Powershell script to deploy settings. When you are using PowerShell scripts you will need to get back your scripts first before you add some changes to them.

You can deploy Bitlocker in Intune by creating a new device configuration profile or an Endpoint security Profile.

When you want to make sure the recovery keys are uploaded, please configure these settings.

4.3. Proactive Remediation

You could also create a proactive remediation script and schedule it to run each hour. It will try to find the event 846 which I showed you earlier and when it’s found it will try to back up the key.

Detection script:

Try {
$Result = get-winevent -FilterHashTable @{LogName="Microsoft-Windows-BitLocker/BitLocker Management";StartTime=(get-date).Addseconds(-86400)}|Where-Object{($_.id -eq 846)} | ft message
$ID = $Result | measure-Object
If ($ID.Count -lt 5)
{
    Write-Output "Bitlocker backup to azure add succeeded"
    Exit 0
}
Else
{
    Write-Output $result
   Exit 1
}
}

catch

{
Write-Warning "Value Missing"
Exit 1
}

When looking at the detection script, you will notice the 86400 seconds.  When a device is enrolled and this error would occur, endpoint analytics will make sure it will try to resolve it.

Remediation script (very small)

$BLV = Get-BitLockerVolume -MountPoint "C:" | select *
BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[1].KeyProtectorId

Let’s check if it’s working. Open pro active remediations and select all at the detection and remediation status to get a better overview and some more information when your remediations are failing.

As shown above, everything is fine and luckily the specific event log is not detected within the last 24 hours. With this remediation, you can be a little bit more sure the recovery key is uploaded.

This blog is not really about how Proactive remediations are launched, but why not? When you have configured proactive remediations, the Powershell scripts are stored on the device itself.

They are handled by the Intune Management Extension (Sidecar agent) who invokes the Agent executor to trigger the execution of the PowerShell scripts. Let’s open the agentexecutor.log first to determine where the Powershell scripts are stored.  

It’s nice to see where the PowerShell scripts are stored (You will need admin rights to access this folder)

Conclusion:

Not monitoring your devices and just trusting everything would just work, is not that smart.

You need to make sure the BitLocker keys are safe or upload the recovery key before encryption! This is the way.