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!
- 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 discuss Bitlocker Drive Encryption – the fully-featured manageable version.
I will briefly discuss how Windows 10 exposes the BitLocker settings to a remote management service like MDM and 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, we still can’t deny the fact that it is simple, basic, and limited, which is true to its purpose.
When a tougher cypher strength or algorithm is required than the default one that Device Encryption offers, organizations and admins generally resort to BitLocker Drive Encryption.
One of Bitlocker Drive Encryption’s best features is its ability to enforce it silently without user interaction—a similar experience to that Device Encryption offers 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) is an on-premise tool for managing and monitoring Bitlocker deployment and status reporting. It can be used 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 a 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)-As pushed, The BitLocker policy will notify the end-user that the device needs to be encrypted as required by the organization. The user must click on the information and follow 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. This is seamless and ergonomic, similar to how 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.
User-aided interactive enforcement depends on end-user activity and is not preferred in enterprise scenarios, both from an admin perspective and from an end-user experience perspective.
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
Silent Encryption in Windows 10 1803 requires an HSTI-compliant device to function. However, in Windows 10 1809 and above, Silent Encryption is compatible with both HSTI and non-HSTI compliant devices.
Windows Versions | Requirements for Silent Encryption |
---|---|
Windows 10 1803 | HSTI compliant device to work |
Windows 10 1809 | Works for both HSTI and non-HSTI compliant devices. |
However, for devices still running the pre-1803 version of Encryption, 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
Encryptionices 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 can choose the cypher strength and encryption algorithm that Bitlocker will use 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 because the end user does not have admin rights.
The Win32_EncryptableVolume WMI class requires administrative privilege on the system—the tool mentioned works with the methods provided by this class.
Recovery configurations
This is the part of the policy where you configure the settings related to protected drive recovery. You must configure the highlighted settings in the snap; otherwise, the Silent Encryption will fail.
The following table is your reference for the Recovery configurations
Description | Status |
---|---|
OS drive recovery | Enabled |
Certificate-based data recovery agent | Enabled |
User creation of recovery password | Enabled |
User creation of recovery key | Enabled |
Recovery options in the BitLocker setup wizard | Enabled |
Save BitLocker recovery information to Azure Active Directory | Not configured |
BitLocker recovery Information stored to Azure Active Directory | Enabled |
Client-driven recovery password rotation | Enabled |
Store recovery information in Azure Active Directory before enabling BitLocker | Not configured |
Pre-boot recovery message and URL | Enabled |
Enable 48-digit recovery | Block |
Allow 256-bit recovery | Allow |
Enable pre-boot recovery message | Enabled |
Backup recovery password | Not configured |
Use default recovery key | Not configured |
Key rotation enabled | Enabled |
Require 256-bit recovery key | Enabled |
This is because Bitlocker Drive Encryption’s default behavior prompts the user to choose a recovery backup method during enablement.
It cannot proceed without this, and as such, it will result in the failure of Silent Encryption.
Noticed the new settings for Client-driven recovery password rotation. This causes a refresh of the Recovery Key every time post-recovery, resulting in the generation of a new Recovery Key, which 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: 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 eEncryption during 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, support for silently enabling Bitlocker for standard accounts 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 get affected on an end device?
This brings us to the Configuration Service Providers (CSP), a component of Windows 10 that acts similarly 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 as 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.
Intune is responsible for delivering the policy to the device. Once the procedure is delivered, the CSP 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, the 4th task Preparing your device for mobile management, when Intune bootstraps the DM client of the device, after which the DM Client establishes a session with the 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 client’s response.
As the Management Phase starts, Intune first sends a DM command to retrieve the management capabilities of the device. This essentially retrieves 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 determine the context, and hands them 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 know which CSP handles 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 the DM Server (Intune) determine the status of the DM commands sent (success/failure/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 as soon as possible. A push notification triggers 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 of how a policy from Intune is delivered to the device and implemented at the device’s end. Now, let’s move on to the next part.
Scope of Intune in enforcing Bitlocker Drive Encryption – Silent Encryption
I have often seen people erroneously state that Intune fails to encrypt the device silently. In this context, I have even heard that it is not easy to understand why the policy failed. As such, it is essential to understand Intune’s role in deploying a Bitlocker Silent Encryption profile.
Intune gives you a UI to configure the policy settings as you require. After you create the policy, Intune delivers it to the device as you make an active assignment. But this is where Intune’s role ends.
The policy, as delivered by Intune, is encryption of 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 the MDM service is not involved in this.
Implementing the policy and the device starting the encryption process is completely out of the scope of Intune.
To be continued…(Deciphering Intune’s Scope w.r.t Bitlocker Drive Encryption)
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. 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 in 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..
We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.
Author
Joymalya Basu Roy is an experienced professional in the IT services field with almost 5 years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect with Atos India. He is an ex-MSFT where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He is awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his own blog site MDM Tech Space at https://joymalya.com
Hey Joy,
Thanks for your great Bitlocker series, I really appreciate it! It helps me a lot to understand the deeper mechanics of Bitlocker.
I’m writing here because I’ve some trouble with some of our Dell laptops and the activation of bitlocker. I’ve configured one rule at intune for all of our devices. Most of them has applied the rule and bitlocker was succesfully activated.
But now I’ve a laptop we’re all requirements are met, but windows notifies me “the device encryption is blocked by computer configuration” with 0x808100D1 or event ID 851.
I’ve checked so far:
– BIOS and TPM Updates with Dell Command Update, all up to date
– TPM Version 2.0
– UEFI Mode – enabled, PCR7 Configuration – binding possible, Secure Start – enabled,
– get-tpm with powershell, all values are fine
– I’ve disabled the automatic device encryption with AAD Join and checked if the device encryption is disabled – all fine
– bitlocker configuration has landed at the registry
It is a Dell Latitude 7480
Keep getting the following error after trying to rotate the keys via the Intune console.
“BitLocker recovery password rotation cannot be performed because backup policy for BitLocker recovery information is not set to required for the OS drive.”
Tried every combination I can think of and the settings to store keys in AAD are set properly as far as I can tell… Any ideas? Key rotation from the client side works fine.