Deciphering Intune’s Scope w.r.t Bitlocker Drive Encryption – Part 3

This is the 3rd article of the Bitlocker series. Links to previous parts are mentioned below. Give them a read if you have not yet!

Related Posts

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

Today in this post, we will be talking about Bitlocker Drive Encryption – the fully-featured manageable version.

I will briefly talk about how Windows 10 exposes the Bitlocker settings to a remote management service like MDM, along with the role and scope of Intune as an MDM service for enforcing Encryption on an endpoint.

Let’s get started.

A short intro to Bitlocker Drive Encryption

Though Device Encryption allows zero administrative cost and a seamless end-user experience from a security perspective, still we can’t deny the fact that it is simple, basic, and limited, which is true to its purpose.

When it comes to the requirement for tougher cipher strength or algorithm than the default one that Device Encryption offers, organizations and admins generally resort to Bitlocker Drive Encryption.

One of the best features of Bitlocker Drive Encryption is the ability to enforce it silently without the need for user interaction – a near similar experience as offered by Device Encryption but with administrative skills. 

Bitlocker Drive Encryption – different ways of administering to suit your existing environment

Bitlocker Drive Encryption is the standard version with full administrative capabilities present in the Pro, Enterprise, and Education SKU of Windows 10.

Depending on your environment, be it On-premises local AD joined devices managed via Group Policy or Config Manager, Cloud only Azure AD joined (corporate-owned) or Azure AD registered (personal) devices managed via Intune or a Hybrid environment where both on-premise and cloud co-exists, you have

• Microsoft Bitlocker Administration and Monitoring (MBAM), an on-premise tool to manage and monitor Bitlocker deployment and status reporting, is available as a stand-alone product or integrated with Config Manager.

• AD Group Policy for domain joined devices – Computer Configuration > Administrative Templates > Windows Components > Bitlocker Drive  Encryption

• Intune (any MDM solution) for cloud managed devices – Intune has native UI flow to manage Bitlocker encryption via Device Configuration (Policy) > Windows 10 and later (Platform Type) > Endpoint Protection (Policy Type) > Windows Encryption

Bitlocker Drive Encryption – Modes of enforcement

Enforcement of Bitlocker Drive Encryption can be

• User Aided (Interactive) – The BitLocker policy, as pushed will generate a notification to the end-user stating the need to encrypt the device as required by the organization. The user needs to click on the information and go through the guided steps to complete the encryption process.

• Silent Encryption – The BitLocker policy, as pushed to the endpoint, will silently encrypt the device without any user notification. Seamless and ergonomic, similar to the fashion in which Device Encryption works.

A quick overview of the User Aided (Interactive) Bitlocker Drive Encryption enforcement flow

As soon as the policy gets effected, the user receives a notification stating that Encryption is required.

This is a normal Windows Notification clicking on which the user is presented with the below screen

This is actually edpnotify.exe process [Note the PID 6900]

As the user proceeds with the selection, the user is presented with the below screen. This is where Bitlocker Drive Encryption wizard starts.

edpnotify.exe process calls BitlockerWizardElev.exe and kills itself. This can be seen from the below snap. Parent process of BitlockerWizardElev.exe is a non-existent process with the PID of edpnotify.exe process.

Considering the user chose Azure AD account to backup Recovery Key, the next screen that is presented is (This is also the BitlockerWizardElev.exe process)

Currently, there are no native UI settings to configure this from Intune. By default, Silent Bitlocker Encryption enforcement from Intune uses Used Disk Space only. Silent Encryption is discussed later below.

As the user proceeds, Bitlocker starts the encryption process. BitlockerElevWizard.exe process calls the fvenotify.exe the function to show the encryption progress status and kills itself.

The user-aided interactive enforcement depends on end-user activity and, as such is not preferred in enterprise scenarios – both from an admin perspective as well as end-user experience.

This brings us to the Silent Encryption support for Bitlocker Drive Encryption, which provides a user experience similar to Bitlocker Device Encryption (Automatic Encryption) with the added advantage of administrative abilities.

Requirements for Silent Encryption – Bitlocker Drive Encryption

• For Windows 10 1803 – Silent Encryption requires HSTI compliant device to work.
• For Windows 10 1809 and above – Silent Encryption works for both HSTI and non-HSTI compliant devices.

However, for devices still running the pre-1803 version ofEncryption0, a Bitlocker policy to enforce silent encryption will resort back to User Aided mode.

Win 10 v1909 being currently in SAC, there will not be many of 1709 devices around, considering the 18 months service support period for Fall updates, except for the LTSC channel…

Understanding the Bitlocker Drive Encryption settings available in Intune UI

Profile Path: Device Configuration > Windows 10 > Endpoint Protection > Windows Encryption

All the policy settings are direct mapping to nodes in Bitlocker CSP, introduced with Windows 10 version 1703 for advanced manageability and reporting purposes.

Main settings

EEncryptionices set to Require is what will trigger the encryption on the device.

Warning for other disk encryption can be set to Block or Not Configured. This is the actual setting responsible for Silent Encryption.

If this is set to Block, windows will attempt to enable Bitlocker silently. However, it might fail, and in such case, you will get an error event in Bitlocker-API events stating “Failed to enable Silent Encryption.”

If you have not set the latter to Block causes Bitlocker to follow the user-aided process as explained above.

Configure encryption method

• if set to Not configured, results in Bitlocker using the default encryption scheme of the XTS-AES 128-bit algorithm.

• If set to Enable, you get to choose the cipher strength and encryption algorithm to be used by Bitlocker for FVEK creation.

Note: If you want to choose a cipher strength or cipher algorithm different than the Bitlocker default AES-XTS 128 bit, for devices already enabled with Device Encryption, the policy will result in a failure state. You would need to manually turn off Bitlocker and decrypt and then sync the device for the procedure to succeed.

For devices provisioned from OOBE, Bitlocker Encryption is triggered post-ESP Device setup phase during the FSIA, when the defaultuser0 account is logged off, and the original user account is signed-in in before ESP enters the Account setup phase. Since 1809, automatic device encryption has been supported for both HSTI and non-HSTI device. You can make sure that machine does not start device encryption with the help of a device restriction profile to block Automatic Encryption during AAD.

Previously, this was done via using OMA-URI as Intune did not have a native UI setting for this.

Additional authentication at startup

This is the policy part where you configure the Authentication type for Bitlocker Drive Encryption. If you wish to configure, you have to set this to Require if you want to use an authentication method different than the Bitlocker default TPM-only authentication.

You can choose to Block Bitlocker Drive encryption on devices that do not have a compatible TPM. Setting this to Not configured allows you to set up Bitlocker without TPM using a startup key or startup PIN (or combo) instead.

Note: There is a known issue of Bitlocker Silent Encryption failure with TPM manufactured by STM, manufacturer version 71.4. If your device’s TPM manufacturer version is as stated above, check for firmware updates on the OEM site.

For a device with compatible TPM, you can choose to require any one of the Authentication methods below.

• TPM only
• TPM + Startup PIN (6-20)
• TPM + Startup Key (256 bit AES)
• TPM + Startup PIN + Startup Key [This is not recommended to be set.]

Note: If you want to require the use of a startup PIN and a USB flash drive, you must configure BitLocker settings using the command-line tool manage-bed instead of the BitLocker Drive Encryption setup wizard. Ref Bitlocker CSP.

For every authentication method, you get to choose three options from the drop-down

• Allow,
• Do not allow and
• Require

Ideally, if you want to enable Bitlocker on devices without a TPM, you would be setting BitLocker with a non-compatible TPM chip to Block.

Leaving it as Not-configured allows the manual setup of Bitlocker on the end-point. However, for such a device, Silent encryption will always fail.

For Silent Encryption, you can leave all the Authentication methods as allowed. By default, it will use the TPM as the key protector (it fails if TPM is not in a ready state).

If you set change the Compatible TPM startup value from Allow to Require, I have seen the profile fails to enable Silent Encryption.

For the other auth methods, you can decide if you want to Allow or Do not allow them.

If you have set them to Allow like, as shown in the above snap, it means the end user can add additional protectors using

• the manage-bde command line tool [manage-bde – protectors]
• the Bitlocker Management tool from Control Panel – Change how drive is unlocked at startup

If you have set the rest to Do not allow, end-users won’t be able to add additional protectors using the above-mentioned tools.

Note 1: If you have configured Auth method to Require either TPM+PIN or TPM+StartupKey combo, Silent Encryption will fail.

Note 2: You cannot enforce an Endpoint Protection policy from Intune with auth method TPM+PIN or TPM+StartupKey or TPM+PIN+StartupKey for a system provisioned with Standard User Account.

To implement such a policy, Bitlocker Drive Encryption will resort to using the Bitlocker Wizard, which will fail due to end-user not having admin rights.

Administrative privilege on the system is a requirement of the Win32_EncryptableVolume WMI class – the mentioned tool works on the methods provided by this WMI class.

Recovery configurations

This is the part of the policy where you configure the settings related to protected drive recovery. It is necessary to configure the highlighted settings in the snap otherwise, the Silent Encryption will fail.

This is because the default behavior of Bitlocker Drive Encryption is to prompt the user to choose a recovery backup method during enablement.

It cannot proceed without this, and as such it will result in failure of Silent Encryption.

Noticed the new settings Client-driven recovery password rotation. These causes a refresh of the Recovery Key every time post-recovery resulting generation of a new Recovery Key, and the same is backed up to AAD. This is a mapping to the Bitlocker CSP node ConfigureRecoveryPasswordRotation. There is one more node in the Bitlocker CSP related to this, and that is RotateRecoveryPasswords. This is not associated with the Bitlocker policy but more of an admin-initiated action.

Account Context for BDE – Silent Encryption with Standard Account

Configuration Bitlocker on OS/Fixed data drive requires local Admin rights on the system. However, to comply with enterprise scenarios where not all end users are given local admin rights on the device, from Windows 10 1809 onwards, Microsoft added the support to enable Bitlocker Drive Encryption on OS/Fixed Data drive using the standard account as well.

If you are doing an Autopilot deployment wiEncryptionle set to create a Standard user account, you need to have the settings Allow standard users to enable eEncryptionduring Azure AD join configured to Allow.

For Windows 10 1803, support for automatic encryption (Device Encryption) with Standard Account was added for AADJ HSTI devices. With Windows 10 1809, the support for enabling Bitlocker for standard accounts silently is extended to non-HSTI devices.

Encryptions 10 devices that are provisioned using Bulk Enrollment (provisioning package using WICD tool), silent encryption won’t work for end-user account, even if the policy has the above settings configured. In such a scenario, you would better resort to using PS script.

With the understanding of the policy settings available in Intune Endpendpointtection policy UI, let’s check the exact profile settings for a triggering successful Silent Encryption on an endpoint (considering it meets the hardware requirement – TPM in a ready state)

How does the policy gets affected on an end device?

This brings us to the Configuration Service Providers (CSP), a component of Windows 10 that acts similar to Client-Side Extension (CSE) for Group Policy.

CSPs expose manageable settings of device features to a remote management service (MDM). With Windows 10 v1703 above, Bitlocker CSP reveals the Bitlocker features to an MDM solution for management.

As such, if your MDM solution does have a native UI flow to manage Bitlocker, you can always resort to using a custom OMA-URI profile as per Bitlocker CSP.

Bitlocker CSP forms the Management Object (MO) of the device DM tree, exposing the manageable features to a remote MDM server like Intune.

The responsibility of Intune is to deliver the policy to the device. Once the procedure is delivered, it is the CSP that implements the settings as received (in the form of SyncML) parsed by the OMA-DM client.

Behind the scenes – modern management of Windows 10 (MDM)

All the device configuration policies sent from an MDM are tagged to the MDM Provider (in this case, Intune), which is the Enrollment ID with which Intune provisions the OMA-DM client of the device during initialization.

This is theoretically tracked during the ESP Phase 1 – Device preparation, 4th task Preparing your device for mobile management, when Intune bootstraps the DM client of the device, post which the DM Client establishes a session with DM server (Intune) to fetch the policies from Intune.

DM session occurs in two phases.

• DM session Setup phase – The DM client invoked by a trigger initializes communication with the DM server. This phase includes authentication. Once the session is established, starts the next step of the DM session.

This is how it appears in DeviceManagement-Enterprise-Diagnostics-Provider (dmenterprisediagnostics.dll) event

MDM Session: OMA-DM session started for EnrollmentID ({EnrollmentID}) with
server: (MS DM Server), Server version: (), Client Version: (), Origin: (),
Initiator: (), Mode: (), SessionID: (), Authentication Type: ().

• DM Session Management phase – This phase comprises the actual exchange of management commands from the DM server to the client and the response from the client.

As the Management Phase starts, at first, Intune sends a DM command to retrieve the management capabilities of the device. This is essentially retrieving the CSPs present in the widget to construct a DM tree for the device.

The DM client responds by sending the DM tree to Intune (All the CSPs available in the OS form the nodes of the DM tree)

Intune also retrieves the platform details (OS, OS version, Dev info) in the same way. With the DM tree constructed and platform information available, Intune evaluates if a policy as configured is applicable for the device before sending it.

The policy is sent a series of DM commands. The DM client receives the DM commands as SyncML, reads the settings to know the context, and handles it over to the corresponding CSP, which is responsible for the implementation.

Breaking it down w.r.t Bitlocker Drive Encryption

Let’s check how Intune instructs the DM client of the device to implement the configured policy settings. bitlo

The below sample shows the DM command sent by Intune to the DM client to enable a particular Bitlocker policy setting. (All the settings come down to the DM client as shown below)

From this DM command, the DM client checks the LocURI to identify the context of the policy settings

• ./Device identifies the policy settings as a system context 
• ./User determines the policy as user context

This is also roughly how ESP (Enrollment Status Page) gets to know what policy to track in what phase.

The LocURI also helps the DM Client to know which CSP is responsible for handling the particular policy settings. In this case, it invokes the Bitlocker CSP to handle the request.

The response status codes returned for the SyncML operations help DM Server (Intune) know the status of the DM commands sent (success/failed/in-progress).

Status Code ref: https://docs.microsoft.com/en-us/windows/client-management/mdm/oma-dm-protocol-support#syncml-response-codes

This is how it appears in the device managemeEncryptionise-Diagnostics-Provider (dmenterprisediagnostics.dll) event

MDM PolicyManager: Set policy int, Policy: (RequireDeviceEncryption), Area:
(Bitlocker), EnrollmentID requesting set: (BA1B8C5F-96D2-43F9-8786-8B5FC84645C1),
Current User: (Device), Int: (0x1), Enrollment Type: (0x6), Scope: (0x0), 
Result:() {Outcome}..

Bitlocker CSP then implements the settings in the registry (MDM registry hive), the encryption is handled via the Bitlocker components in the OS.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\ Is the MDM registry hive. However, the policy is first implemented on the path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Providers\<Provider GUID>\default\Device\BitLocker

Intune – Device communication a Push-Pull model

By default, the DM Client on the device is configured to connect back to the DM server every 8 hours to check with the service for any changes.

This is a Pull. However, If anything changes at the DM server end, Intune tries to Push the changes to the device at the earliest. This is via Push Notification to trigger the DM client to connect to the service to get the changes.

This is how a Push looks in the event (Windows Notification Service is the Push service backend for the Windows platform)

The DM client will establish a session with the DM server and retrieve the new/changed policy settings. The responsible CSP will then implement the new settings in the registry. This is how it looks in the event

I hope this gives you a fair understanding about how a policy from Intune is delivered to the device and is implemented at the device end. Now let’s get to the next part.

Scope of Intune in enforcing Bitlocker Drive Encryption – Silent Encryption

I have often seen people erroneously stating that Intune fails to encrypt the device silentlyIn this context, I have even heard that it is not easy to understand why the policy failed.

As such, it is very much needed to understand the role of Intune in deploying a Bitlocker Silent Encryption profile.

Intune gives you a UI to configure the policy settings as required by you. Post creating the policy, Intune delivers the same to the device as you make an active assignment. But this is where the role of Intune ends.

The policy as delivered by Intune isEncryption the OMA-DM client on the device, which is then handled by the Bitlocker CSP to implement the settings in the registry. The device’s encryption is then handled by the Bitlocker components present in the OS. Intune or MDM service is nowhere involved in this.

Implementation of the policy and the device starting the encryption process is completely out of scope for Intune.

To be continued…

Due to the length of the post, I will stop here today. But don’t forget to check out the next part of this article which will be even more interesting, where I will cover the failure points and give you a look into how Bitlocker is implemented on the system. It will be the concluding post to my Bitlocker series. As such keep an eye on it !!!

Before I end today, I want to wish everyone a very happy and prosperous New Year. We will meet on the other side of 2020. Till then, enjoy your holidays as you gather energy to drive through another year of opportunities, accomplishments, and last but not least..