Bitlocker management via Intune- The Complete Guide
My name is Saurabh Sarkar and I am an Intune engineer in Microsoft. I have a YouTube channel ‘EverythingAboutIntune’ and you can subscribe to the same to learn more about Microsoft Intune.
The entire demonstration of this post which illustrates a deep dive on Bitlocker can be found below-
In this post we are going to understand the background of Bitlocker and the various ways of managing\administering the same via Intune along with some common use cases and the relevant logs
Comparison of EFS with Bitlocker:
- As we have known, EFS is also something that inherently protects the files\folders in the device.
- On the other hand bitlocker is a feature in the OS which is protecting the data in the device. Hence it is important for us to understand that how both of them are working together in the same device and the key differences
| Bitlocker | EFS |
| Bitlocker encrypts volumes (as one unit) | EFS encrypts files and directories |
| Bitlocker encrypts system files as well! | EFS can not encrypt system files(C:\Windows\System32) |
| Bitlocker uses symmetric and asymmetric encryption | EFS uses asymmetric encryption |
| Bitlocker does not protect your data while a system is turned on | EFS protects your data while a system is turned on |
Hence as established, both are not replacement of each other, but are supposed to work together! They are supposed to compliment each other.
They can provide layered defense against threat to the info in the device.
Bitlocker Working:
#1- Each sector of the drive that we wish to encrypt is encrypted using FVEK
FVEK is a symmetric key and It uses the AES 128 bit algorithm which can be changed as per org policy.
#2- Now obviously the FVEK is very precious… as it can only decrypt the data in the disk so it has to be kept safe.
Now instead of just securing the FVEK , we add a second layer. i.e. we encrypt the FVEK (using another key called VMK)
Now obviously VMK becomes precious too… as whosoever has access to VMK can decrypt the FVEK and using FVEK can view the data in the disk.
#3- So now we secure the VMK using “Protectors”
Using the Protectors is a mechanism of securing the VMK.
There are many kinds of Protectors that can be used, viz- TPM\PIN\Startup Keys or a combination of the same.
- There is an additional partition present\created (for bitlocker encryption to work) which does not store the user’s data and this volume is NOT encrypted.
- This is the “System” partition and contains just enough information (like the boot loaders) so that the OS can begin to load and start the boot process.
Boot Sequence:
OS loads from the System partition which was not bitlocker encrypted>When we are using only TPM as the protector, the TPM performs measured boot, and if it detects that the device has not been tampered with, it releases the keys and unlocks the OS drive >Which releases the VMK which in turn is used to decrypt the FVEK and then the data.
Bitlocker Types and Management:
- If we want to encrypt a device via Bitlocker- we have 2 possible approaches to take viz- Bitlocker Device Encryption and Bitlocker Drive Encryption.
- Both at the end of the day use the same mechanism and logic to encrypt the volumes.
- Bitlocker Device Encryption is something that cannot be administered and it happens automatically during the AAD join phase of the device(if the device meets a set of pre-reqs)
- Bitlocker Drive Encryption can be administered via a variety of approaches viz- SCCM, MBAM, Group policy and MDM(Intune)
- When a device is Azure AD joined, an evaluation is made of the device. If the device meets the needed parameters(HTSI compliance etc..) the device gets automatically encrypted using Bitlocker Device Encryption.
- As an admin, we always have an option of deploying MDM policies to devices enrolled to Intune which would do Bitlocker Drive Encryption.
Device encryption VS Drive Encryption
| Device Encryption | Drive Encryption |
| TPM/Modern Standby/HSTI compliance compulsory | TPM and Modern Standby is not compulsory |
| Available for all SKUs | Available for limited SKUs |
| Cannot be managed by the admins | Can manage the deployment/behavior/methodology |
| Can manage the encryption deployment via GPO/MBAM/MDM | |
| Can do things like- Silent encryption, key rotation etc.. | |
| Uses default Bitlocker settings | Admin can specify the bitlocker settings to be used |
| No admin overhead | Admin overhead- creating policies and tracking |
| Enablement is automatic with less features | Enablement is manual(by admin) and has more features |
The above comparison should help us in understanding the similarities\differences betwwen both the approaches.
While one is automatic and not configurable, the other is admin deployed and more customizable!
Bitlocker Enforcement Modes:
- If we want to do Bitlocker drive encryption via Intune then we have 2 possible approaches. Viz- User Aided and Silent Encryption.
- User Aided is a user driven process where the user has to make some selections for the encryption process to go through
- Silent encryption is seamless and there is no user intervention needed to trigger\complete the encryption process
#User-Aided
- In this kind of Bitlocker encryption, the end user gets an intuitive prompt which guides him through the encryption process and selection
- This is a user-guided and user dependent process
- Below are the prompts a user gets when he undergoes a user aided bitlocker encryption
It is important to note here that- the user aided bitlocker encryption is user dependent. Meaning after the policy is deployed to the device the actual encryption would not happen\succeed unless the user clicks and makes the relevant selections in the prompts.
#Silent Encryption
- Silent Encryption is one of the most used feature during a Bitlocker encryption of a device via Intune
- The major value add here is- There is NO user dependency for the encryption process to trigger\complete.
- In this case we donot set any user facing protector(Like PIN\usb drive) to safeguard the VMK, as that would need user inputs
- TPM acts as the protector in this case which automatically unlocks the drive if the needed pre-reqs are met.
- The device needs to be AADJ or HAADJ to support Silent Bitlocker encryption via Intune.
Key Points:
- If we have configured Auth method to Require for either TPM+PIN or TPM+StartupKey combo, Silent Encryption will fail. So the same should NOT be allowed
- “Allow standard users to enable encryption during AADJ” should be set to Allowed
- “Waring for other disk encryption” should be set to “Blocked” so that the end user doesn’t get a warning prompt while the encryption process(Which is needed for Silent encryption)
- “Save Bitlocker recovery information to AAD” needs to be Enabled
- “Save Bitlocker recovery information to AAD before enabling Bitlocker” needs to be set to required
Ways of configuring Bitlocker via Intune:
- We can manage 2 attributes of a Windows device wrt Bitlocker from Intune- Its Bitlocker Compliance and Bitlocker Configuration
#Endpoint Protection(Device Config) Profile
#Disk Encryption(Endpoint Security)Profile
#Security Baselines
#CSPs
- The CSP tree structure as per MS official documentation can be found below which can be targeted via OMA-URI accordingly.
Intune + Bitlocker + Workgroup – TPM
- Wanted to clearly document that- we can administer Bitlocker in a device from Intune irrespective of whether the device has a TPM and is joined to a domain or not
- If the device does not have a TPM, we can have a user facing protector for the encryption(like a Pin\usb etc)
- Below is an illustration of Bitlocker management of a device without TPM via Intune
Once the device is bitlocker encrypted, the user will have to enter the pin(User facing protector) at each bootup before the OS drive can be decrypted and the OS can fully load.
If the policy is not correctly made at the Intune end which specifies that-User facing protector should be used |The encryption should happen without TPM in the device | Recovery option must be correctly configured –> We might encounter the below errors
Below are the settings needed for doing Bitlocker encryption from Intune on a device without TPM
3Rs:Rotation, Recovery and Retention
#Key Rotation:
- The device must be-> Win 10 1909 or later
- The device must be-> AADJ or Hybrid AADJ
There are 2 kinds of Bitlocker Key Rotation:
Server side rotation. -> The admin can rotate it manually from the portal end.
Client side rotation -> Automatically triggered when the key is used by the admin
- The client-side key rotation wont work, unless we use the key on the client.
- If we read the key on the portal OR copy paste/download it, The server side key rotation won’t be triggered.
- In MBAM– whenever we read the key from MBAB portal the key was marked as disclosed in the database and it was rotated on the client.
Below is the sequence of events we see in Bitlocker-API logs in case of a successful bitlocker sever-side key rotation(from the portal)
| EventMessage | EventId |
| Recovery Password Rotation initiated. | 855 |
| BitLocker 845 Encryption recovery information for volume C: was backed up successfully to your Azure AD. | 845 |
| A BitLocker key protector was created. | 775 |
| A BitLocker key protector was removed. | 776 |
| Recovery Passwords Rotation and AAD Deletion requests processing initiated successfully | 864 |
| Recovery Passwords Rotation done successfully | 857 |
| BitLocker Drive Encryption recovery information for volume \\.\C: was deleted successfully from your Azure AD. | 4123 |
#Key Recovery:
- The recovery password is a 48-digit, randomly-generated number that is created during BitLocker setup
- If the computer enters recovery mode, the user will be prompted to type this password using the function keys (F0 through F9).
- The end user can view the recovery password for all the devices enrolled by him(if the keys were backed up in Azure AD) in the URL- https://account.activedirectory.windowsazure.com/r/#/profile
- The site is not blocked by CA and can be accessed from an unenrolled device as well. The Key access is logged in the AAD event logs.
- We must be a primary user of the device to access the keys. i.e. if we are the secondary user in a shared PC, or if its a comanaged device without any primary user –> Cant access it
| Common causes of Bitlocker Recovery Screen: |
| Moving the BitLocker-protected drive into a new computer. |
| Installing a new motherboard with a new TPM. |
| Turning off, disabling, or clearing the TPM. |
| Updating the BIOS\TPM firmware update |
| Updating optional read-only memory (option ROM) |
| Upgrading critical early boot components that cause system integrity validation to fail. |
| Forgetting the PIN when PIN authentication has been enabled. |
| Losing the USB flash drive containing the startup key when startup key authentication has been enabled. |
| Complete depletion of charge of battery |
#Key Retention
- Recovery keys in AAD are tied to the lifetime of the AAD device object
- If the device object gets deleted (either as part of device offboarding, cleanup or accidentally), the recovery key becomes inaccessible from the customer helpdesk.
- On-prem recovery key information is never removed or deleted from the database, even after the client has gone inactive or is deleted from the console.
- There is a current gap in the story with AAD to improve longevity of the recovery key stored in cloud, Hopefully fixed in the future
LOGS:
- Below are the various logs that we can check when troubleshooting any Bitlocker related issue on a Windows device.
#SyncML Logs:
- SyncML logs would be our first tracking point for policy delivery at the device end.
- Any policy delivered from Intune to a Windows 10 device can be seen in the SyncMl trace.
Below are the relevant info we see in the SyncML trace when a Bitlocker policy is deployed to the device, which is in accordance with the policy created by the admin at the portal.
If we take a close look into the SyncMl trace, we can see all the attributes coming down to the device from Intune(Like the encryption cipher to be used, the protectors, recovery key backup information etc)
#EventLogs
#DMP:
Below is a crux of the eventlogs (in sequence) we see in DMP during a successful bitlocker policy delivery via Intune
- Below is the processing of the logs:
#Bitlocker-API events
- Below is the sequence of events we see in the Bitlocker-Api logs in case of a successful encryption
| Source | EventId | Message |
| BitLocker-API | 796 | BitLocker Drive Encryption is using software-based encryption to protect volume C:. |
| BitLocker-API | 817 | BitLocker successfully sealed a key to the TPM. PCRs measured include [7,11]. |
| BitLocker-API | 840 | A trusted WIM file has been added for volume C:. |
| BitLocker-API | 775 | A BitLocker key protector was created. Protector GUID: |
| BitLocker-API | 845 | BitLocker Drive Encryption recovery information for volume C: was backed up successfully to your Azure AD. |
| BitLocker-API | 768 | BitLocker encryption was started for volume C: using AES-CBC 128 algorithm. |
| BitLocker-API | 840 | A trusted WIM file has been added for volume C: |
| BitLocker-API | 775 | A BitLocker key protector was created. Protector GUID: |
| BitLocker-API | 845 | BitLocker Drive Encryption recovery information for volume C: was backed up successfully to your Azure AD. |
| BitLocker-API | 768 | BitLocker encryption was started for volume C: using AES-CBC 128 algorithm. |
#MDM Diag Logs:
Bitlocker Registry
- Below are the 3 relevant registry locations wrt Bitlocker
| Registry Hive |
| 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 |
| Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE |
Bitlocker reporting- from Intune
- Bitlocker reporting of devices via Intune is also of paramount importance.
- Firstly its because just like other device configuration policy deployment-reporting, Bitlocker policy reporting is also done at the portal.
- This helps us to understand how many devices got correctly encrypted and hence the corrective actions can be taken accordingly.
- Secondly, and most importantly, Intune service evaluates and reports bitlocker related status of devices which are not getting any bitlcoker policy as well–>Meaning all Windows devices
- For any Windows device enrolled to Intune, the service would evaluate-
#If the device is already Bitlocker encrypted
#If the device has a TPM present and initialized
#If the device which is not encrypted- does it have the readiness to undergo a Bitlocker encryption, if the need be.
- This reporting is very verbose and important as it can help in planning\evaluating the Bitlocker deployment to the environment
- If the devices fail Bitlocker enablement, we will see error codes to help us troubleshoot and take the appropriate remedial action
Bitlocker Compliance from Intune
There are 2 ways of managing Bitlocker Compliance of a Windows device via Intune.
#‘Reqiire Bitlocker’ setting:
- The “Require Bitlocker” setting in the compliance policy is checked by the Windows Device Health Attestation (DHA) service’s report.
- Windows Compliance>Device Health> Windows Health Attestation Service evaluation rules
#’Encryption of data storage‘ setting:
- The “Encryption of data” storage setting in the Compliance policy checks if the data in the device is encrypted via Bitlocker by referencing DeviceStatus csp
- This setting can be found in the location –> Windows Compliance>System Security> Encryption
Using script to decrypt bitlocker
Usecase:
- Device is already encrypted with 128 bit but we want 256 bit in the device as per Org’s requirement
- The only option now is- decrypting the device first and then encrypting them again– the option is not there natively in the UI
- Feature maybe coming in new release wherein this would be possible via the portal itself
- Currently we can deploy a PS script to do the decryption
The below PS script would first get a list of all the volumes in the machine>then Decrypt all of them
Below is the processing of the PS script we see in the IME logs-
Once the device is decrypted via the above PS script, it can be encrypted as per the org’s requirement via profiles
Bitlocker + Comanagement
- Bitlocker policies are governed by the Endpoint Protection slider
- Key escrow does not happen automatically to AAD with this slider – need to do a key rotation, or manage-bde to get keys escrowed
- Big use case if cx is moving to on-prem to cloud management
- Might have another feature for this at some time
Bitlocker + Autopilot
#Use case:
- As soon as the device boots up, if it sees the device meets the automatic encryption requirements it will start encrypting.
- Windows 10 device runs through the Out Of Box Experience (OOBE), and an AADJ occurs during OOBE, BitLocker may be automatically enabled on modern hardware with the default XTS-128-bit encryption algorithm –> This is Bitlocker Device Encryption
- And that give you no time to get a new set of BitLocker settings to the device first, so it starts encrypting with the default XTS-AES 128-bit settings.
- Too late to make changes, hence the note in the portal about having to decrypt to make the change.
- An IT Administrator can set this algorithm to AES-CBC 128-bit, AES-CBC 256-bit, XTS-AES 128-bit or XTS-AES 256-bit encryption.
- This causes a situation whereby the BitLocker disk encryption does not meet the IT administrator’s defined requirements in Intune.
Solution\Fix-
- We made some changes to the Windows Autopilot build process that enables Windows to consume the IT administrator’s MDM settings before automatic encryption is started
- We made some changes in Windows 10 1809 and above to fix this problem when you are using BitLocker with Windows Autopilot and the Enrollment Status Page.
- With these changes, BitLocker will wait to begin encrypting until the end of OOBE, after the ESP device configuration phase has completed.
- That gives Intune sufficient time to get the BitLocker policies applied to the device first, so when BitLocker starts encrypting,
- This is applicable for Windows 10 October 2018 Update and later
Configure the encryption method settings in Intune –>Target the encryption method policy to your Autopilot group of devices –> Enable the Autopilot Enrollment Status Page (ESP) for your users/devices.
Note:
- The Bitlocker policy needs to be processed as a device targeted policy, not a user targeted policy.
- If the ESP is not enabled, the above policy will not apply before encryption starts.
By meeting these configuration requirements, Autopilot configured devices will now honor the BitLocker encryption algorithm setting and will encrypt with your specified encryption algorithm.
Coming soon (probably!)
- User self-service key recovery using the Company Portal app
- Do a full drive encryption from Intune
- BitLocker Management support over CMG
- Listing on-prem stored BitLocker recovery key for ConfigMgr tenant attach in the MEM portal
