Intune compliance evaluation for Bitlocker – How it works?

This blog post is about how Intune compliance evaluation for Bitlocker works.

Why I am writing this is because if you have 

1. deployed Bitlocker Silent Encryption from Intune, and have a
2. compliance policy to evaluate the device encryption status.

Post device provisioning, you may find that the devices are reporting as non-compliant for Bitlocker. 

But when you go and check the status of the Bitlocker configuration profile, you see that it is reporting status as Success.

This is a very common scenario and this blog post helps you to understand this exact behavior.

This blog post takes your attention to the two different Intune compliance policy settings with which you can evaluate device encryption status, throwing light on the evaluation mechanism for each.

Why Intune compliance evaluation marks devices as Not-Compliant for Bitlocker?

For a device going through the OOBE provisioning, Bitlocker is not enabled on the device right out-of-box as the user powers on the device.

It’s during the OOBE provisioning that the device will

• perform the AAD or Hybrid AAD join depending on the Autopilot profile (or AAD join from OOBE if user manual).
• get enrolled to Intune.
• receive the Bitlocker configuration policy along with other appliacable policies vide enrollment.

Receiving the policy from Intune and the policy taking effect on the device are two different things.

💡 Once Intune sends the policy, the DM client receives and parses the policy to call the corresponding CSP which then is responsible for getting the settings configured on the device.

Bitlocker enforcement on the endpoint is via an enterprise encryption policy from Intune that is facilitated on the endpoint by the Bitlocker CSP.

Bitlocker silent encryption pre-requisites are listed below,

• Device BIOS mode should be set to native UEFI. [CSM mode for devices with legacy firmware is not supported.]
• Secure Boot enabled.
• TPM 2.0
• No removable drive detected on the system.
• Bitlocker Silent Encryption profile is configured correctly.

💡 If configured encryption algorithm and strength is different than the default 128-bit encryption scheme, then there must be an Intune restriction to block automatic encryption.

💡 For HAADJ, I have seen that devices must be able to establish communication with AD if on Internet for Bitlocker to escrow recovery key to AD.

If the Bitlocker silent encryption pre-requisites are met, the actual encryption process starts post the First Sign-In Animation (FSIA) after the Windows login process.

💡 This is the time when Windows logs off from the defaultuser0 built-in system account under which the OOBE process was running till now and creates and logs in the actual end-user account to complete the user profile setup.

💡 For the AAD join process, if there is no restart during the device ESP phase, the login credentials are cached to perform the Windows login automatically, which makes it seamless.
 However, if there is a restart during the device ESP for AAD join process, post device ESP, the device brings up the Windows login screen where the user has to perform sign-in, post which the FSIA is displayed.

💡 For the Hybrid AAD join process, device will always bring up the Windows login screen post completeing device ESP for user to sign-in.

💡 The FSIA, as I have seen in most environment, remains disbabled via an OMA-URI policy. As such you may find the device directly going to the User ESP post the Windows login for an AADJ sceanrio. For HAADJ, the user ESP may be skipped altogether depeding on the configuration and environment. 

Once the encryption is triggered, the device goes to the “encryption in progress” state before it finally gets to the “fully encrypted” state. Time taken for the encryption process to complete is based on the drive size and the amount of data.

For the time the device remains in the “encryption in progress” state, it’s common to see the state of the Bitlocker config policy in Intune to report as Remediation Failed.

💡 Since the policy enforcement from Intune is a POST, there is always an accompanying GET call to report the status back to Intune regarding the policy enforcement state.

As the device enters the “fully encrypted” state, the policy enforcement state reports the same back to Intune during the next check-in, post which we see the Bitlocker config policy state changes to Success.

The end-user at this point can see the Bitlocker sign on the drives.

However, even though the config profile for Bitlocker reports as Success, it’s most likely you will find the device reporting as non-compliant for Bitlocker compliance evaluation, as shown below.

💡 Ignore the Error reflecting against the System account.

This brings us to the purpose of this blog post.

Intune compliance evaluation for Bitlocker – How it works?

In your Intune compliance policy, you can evaluate the encryption status of the device vide two settings as below

• Require BitLocker
• Encryption of data storage on device

Because of the difference in the way in which the two compliance settings mentioned above are evaluated, there is a difference in the reporting behavior.

Considering the subjected Intune compliance policy for the device in context has both the settings used for encryption evaluation, let’s understand how the settings are individually evaluated.

Encryption state evaluation vide Intune compliance settings Encryption of data storage on device

This uses the DeviceStatus CSP which generically checks for the presence of encryption on the device at the OS drive level. This requires the encryption to be enforced using an enterprise encryption policy.

For Intune, this is via the Bitlocker CSP.

💡 This is why we may see the Encryption of data storage on device reporting as Error for devices having 3rd party encryptions like VeraCrypt, McAfee FDE, Symantec PGP, etc.

As per the CSP documentation, possible values for the GET call can return

• 0 – Not encrypted
• 1 – Encrypted

This means it does not understands the encryption in progress state.

As such, till the encryption process completes, during Intune check-in, the device reports encryption state as Not encrypted, and you will find the particular compliance item Encryption of data storage on device showing up as Error in the portal.

As the encryption process completes and the device checks in with Intune, you will see the compliance state for the particular compliance item Encryption of data storage on device changes from Error to Compliant, provided there was no blocker for Bitlocker silent encryption.

💡 If you see this reporting as an error, you need to check the Bitlocker API events to find out why the silent encryption failed.

At this stage, for the device in the context

• Bitlocker configuration policy status in Intune is Success.
• BitLocker is enabled on the device.
• Intune compliance policy reports that “Encryption of data storage on device” is Compliant.

But still, the overall compliance state of the device is Not-Compliant due to “Require BitLocker”. This is because of the difference in the working mechanism of how that particular setting is evaluated.

Encryption state evaluation vide Intune compliance settings Require Bitlocker

This uses the DHA CSP for its functioning.

💡 Device Health Attestation is based on the collected system boot log which contains the measurements of system boot parameters. Thus when Intune performs DHA evaluation, it basically evaluates the system boot measurements of the last system boot.

In our case, since the device has not been rebooted post the Bitlocker enablement, the last captured system boot log will still be having the measurement value for Bitlocker as Disabled/No.

💡 Bitlocker is not enabled out-of-box but was enforced vide a configuration profile during device provisioning!

As such, we see the compliance policy reports “Require Bitlocker” as Not Compliant.

This is the reason why it requires the device to be rebooted post encryption in order for the boot logs to capture the measurement of the new state of Bitlocker as part of the system boot parameters.

💡 Post reboot, when Intune requests for the DHA report, the device sends the new system boot log to the DHA service for attestation. Once it gets the report back from the DHA service, on the next check-in with Intune, the device sends it to Intune for compliance evaluation.

This is when we see the state for Require Bitlocker flip from Not Compliant to Compliant.

💡 The need to trigger a restart to get the correct Bitlocker compliance status can be achieved through user education or scheduling restarts remotely.

Ending

You can use either of the two compliance policy settings (or both) in Intune to evaluate device encryption state, but do note that the encryption state evaluation via Device Health Attestation is more robust and secure.

You can find my previous blog posts on Bitlocker listed below.

• Bitlocker Unlocked with Joy – Behind the Scenes Windows 10 – Part 1
• Device Encryption – Bitlocker made Effortless – Part 2
• Deciphering Intune’s Scope w.r.t Bitlocker Drive Encryption – Part 3
• Intune Silent Encryption – A Deeper Dive to Explore the Internal- Part 4

And, if you want to have further clarity on this behavior of compliance evaluation check for Bitlocker, do refer to this tech community article

References

• Configuring BitLocker encryption with Endpoint security
• Enabling BitLocker with Microsoft Endpoint Manager – Microsoft Intune
• Enforcing BitLocker policies by using Intune: known issues
• Troubleshooting BitLocker from the Microsoft Endpoint Manager admin center
• Troubleshooting BitLocker policies from the client side