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

0
Bitlocker Drive Encryption - Silent Encryption profile requirements

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

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.

Lets get started.

A short intro to Bitlocker Drive Encryption

Though Device Encryption allows zero administrative cost and a seamless end user experience from security perspective, still we can’t deny the fact that it is simple, basic and limited which is true to its purpose. As such, when it comes to 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 feature 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 abilities. 

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, 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) – Bitlocker policy as pushed will generate a notification to end user stating the need to encrypt device as required by organization. User needs to click on the notification and go through the guided steps to complete the encryption process.
  • Silent Encryption – Bitlocker policy as pushed to 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, user gets a notification stating that Encryption is required.

Bitlocker Drive Encryption - User Aided Flow - Windows Notifictaion stating Encryption needed
Bitlocker Drive Encryption – User Aided Flow – Windows Notifictaion stating Encryption needed

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

Windows Drive Encryption - User Aided Flow - Warning for 3rd party encryption
Windows Drive Encryption – User Aided Flow – Warning for 3rd party encryption

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

Bitlocker Drive Encryption - edpnotify.exe behind the Warning for 3rd party encryption
Bitlocker Drive Encryption – edpnotify.exe behind the Warning for 3rd party encryption

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

Bitlocker Drive Encryption - Start of Bitlocker Wizard - Backup Recovery Key information
Bitlocker Drive Encryption – Start of Bitlocker Wizard – Backup Recovery Key information

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.

Bitlocker Drive Encryption - edpnotify.exe parent process of BitlockerWizardElev.exe - Bitlocker Wizard
Bitlocker Drive Encryption – edpnotify.exe parent process of BitlockerWizardElev.exe – Bitlocker Wizard

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

Bitlocker Drive Encryption - User Aided flow - Choose encyrption type - Full or Used Space only
Bitlocker Drive Encryption – User Aided flow – Choose encyrption type – Full or Used Space only

Currently there is 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 user proceeds, Bitlocker starts the encryption process. BitlockerElevWizard.exe process calls the fvenotify.exe process to show the encryption progress status and kills itself.

Bitlocker Drive Encryption - User Aided flow - fevnotify.exe shows the encryption progress
Bitlocker Drive Encryption – User Aided flow – fevnotify.exe shows the encryption progress

The user-aided interactive enforcement depends on end user action and as such is not that preferred in enterprise scenario – both from admin perspective as well as end user experience.

This brings us to the Silent Encryption support for Bitlocker Drive Encryption, which provides an 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 pre-1803 version of Window 10, 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 much of 1709 devices around, considering the 18 months service support period for Fall updates, except for 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 purpose.

Main settings

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

Deciphering Intune's Scope w.r.t Bitlocker Drive Encryption - Part 3 1
Bitlocker Drive Encryption Policy Settings – Intune UI

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

If this is set to Block, windows will attempt to silently enable Bitlocker. 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 later to Block causes Bitlocker to follow the user aided process as explained above.

Configure encryption method

Bitlocker Drive Encryption Policy Settings - Choose Encyrption Methods
Bitlocker Drive Encryption Policy Settings – Choose Encyrption Methods
  • if set to Not configured, results Bitlocker to use the default encryption scheme of 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 failure state. You would need to manually turn off Bitlocker and decrypt and then sync the device for the policy 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 original user account is signed-in, before ESP enters the Account setup phase. Since from 1809, automatic device encryption is supported for both HSTI and non-HSTI device, you can make sure that device does not starts device encryption with a help of a device restriction profile to block Automatic Encryption during AAD.

Bitlocker Drive Encryption - Seperate restriction profile required to stop Device Encryption during AADJ
Bitlocker Drive Encryption – Seperate restriction profile required to stop Device Encryption during AADJ

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

Additional authentication at startup

This is the policy part where you configure the Authentication type for Bitlocker Drive Encryption to use. 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.

Bitlocker Drive Encryption - Require Additional Authentication
Bitlocker Drive Encryption – Require Additional Authentication

You can choose to Block Bitlocker Drive encryption on devices which do not have a compatible TPM. Setting this to Not configured allows you to setup 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 TPM manufacturer version is as stated above, check for firmware updates on the OEM site.

Bitlocker Drive Encryption - Choose the auth method.
Bitlocker Drive Encryption – Choose the auth method

For device with compatible TPM, you can choose to require any one of the Authentication method as 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-bde 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 do want to enable Bitlocker on devices without a TPM, you woud be setting BitLocker with non-compatible TPM chip to Block. Leaving it as Not-configured allows 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 Allow. By default it will use the TPM as the key protector (fails if TPM is not in ready state).

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

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

If you have set them to Allow like as shown in the above snap, means 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
Bitlocker Drive Encryption - Bitlocker Management tool to add/modify key protectors
Bitlocker Drive Encryption – Bitlocker Management tool to add/modify key protectors

If you have set the rest to Do not allow, means 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 for 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.

This is because, to implement such policy, Bitlocker Drive Encryption will resort to use 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 very much needed to configure the highlighted settings in the snap otherwise the Silent Encryption will fail.

Bitlocker Drive Encryption - Configuring the recovery options
Bitlocker Drive Encryption – Configuring the recovery options

This is because, the default behavior of Bitlocker Drive Encryption is to prompt user to choose recovery backup method during enablement. It cannot proceed without this and as such which will result failure of Silent Encryption.

Noticed the new settings Client-driven recovery password rotation. This causes 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 related to the Bitlocker policy in itself but more of an admin initiated action.

Intune Portal - Device Overview blade - Admin initiated Bitlocker key rotation option
Intune Portal – Device Overview blade – Admin initiated Bitlocker key rotation option

Account Context for BDE – Silent Encryption with Standard Account

Configuration of 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 standard account as well.

If you are doing an Autopilot deployment with profile set to create Standard user account, you need to have the settings Allow standard users to enable encryption during Azure AD join configured to Allow.

Bitlocker Drive Encryption - Allow standard users to enable encryption
Bitlocker Drive Encryption – Allow standard users to enable encryption

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 account silently is extended to non-HSTI devices as well.

For Windows 10 devices which are provisioned using Bulk Enrollment (provisioning package using WICD tool), silent encryption won’t work for end user account, even if 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 Endpoint Protection policy UI, let’s check the exact profile settings for a triggering successful Silent Encryption on a endpoint (considering it meets the hardware requirement – TPM in ready state)

How does the policy gets effected on an end device?

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

CSPs exposes manageable settings of device features to a remote management service (MDM). With Windows 10 v1703 above, Bitlocker CSP exposes the Bitlocker features to an MDM solution for management. As such, if your MDM solution do 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.

Responsibility of Intune is to deliver the policy to the device. Once the policy is delivered, it is the CSP which implements the settings as received (in 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 is 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 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 the authentication. Once the session is established, starts the next phase of the DM session.

This 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 device to construct DM tree for the device.

DM Session - DM client sending CSPs to DM server to construct the DM tree
DM Session – DM client sending CSPs to DM server to construct the DM tree

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

DM Session - DM client sending the DM tree to DM server
DM Session – DM client sending the DM tree to DM server

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

Below sample shows the DM command send by Intune to the DM client to enable a particular Bitlocker policy settings. (All the settings comes down to the DM client as shown below)

DM Command to implement Bitlocker Drive Encryption.
DM Command to implement Bitlocker Drive Encryption

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 identifies 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 to handle 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 helps 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 DeviceManagement-Enterprise-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 being handled via the Bitlocker components in the OS.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\ is the MDM registry hive. However, the policy is actually first implemented at 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 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 back 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 Windows platform)

Intune triggeres Push to notify policy settings changed
Intune triggeres Push to notify policy settings changed

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 to the registry. This is how it looks in the event

M Client establishes session to retrieve the new policy settings for implementation
DM Client establishes session to retrieve the new policy settings for implementation

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

Often I have seen people erroneously stating that Intune failing to silently encrypt the device. In this context I have even heard that it is very difficult 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 give you an UI to configure the policy settings as required by you. Post creating the policy, as you make an active assignment, Intune delivers the same to the device. But this is where the role of Intune ends.

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

Implementation of the policy as well as 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 look into how Bitlocker is actually 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, want to wish everyone a very happy and prosperous New Year. Will meet on the otherside of 2020. Till then, enjoy your holidays as you gather energy to drive through another year of opportunites, accomplishments and last but not the least…

Leanings. šŸ™‚

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.