Hardware independent automatic Bitlocker encryption using AAD/MDM
Windows 10 delivers a "mobile-first, cloud-first"? approach of simplified, modern management using cloud-based device management solutions such as Microsoft Enterprise Mobility Suite (EMS). This offers mobile users to be more productive regardless of location. At the same time organizations will require data to be safe, especially keeping 2018's GDPR in mind. Most organizations require a form of disk encryption like BitLocker.
In one of my previous blog posts you might have read about the requirement for InstantGo capable devices to automate BitLocker configuration on the device and backup the recovery key to the user's Azure AD account. Windows 1703, also known as the Creators Update, offers a wizard where users are prompted to start encryption regardless of the hardware used. This post describes how to fully automate BitLocker encryption without end-users being prompted.
Recently I received a few scripts that allow the triggering of a fully automated BitLocker encryption process regardless of hardware capabilities. The solution has been developed by Paul O Connor (DXC) and Adam Lyndersay (DXC) which leverages the previous powershell script work by Jan and Sooraj (DXC).
I've added some enhancements, wrapped them into an MSI - ready to be uploaded in Intune and deployed to a group of users. For specific scenarios where end-users are not part of the local admin group an alternative solution is available.
How does this solution work?
The TriggerBitLocker MSI attached to this blog does the following:
- Deploys three files into C:\Program Files (x86)\BitLockerTrigger\
- Imports a new scheduled task based on the included Enable_Bitlocker.xml
The scheduled task will run every day at 2PM and will do the following:
- Run Enable_Bitlocker.vbs which main purpose is to call Enable_BitLocker.ps1 and make sure to run minimized.
- In its turn, Enable_BitLocker.ps1 will encrypt the local drive and store the recovery key into Azure AD and OneDrive for Business (if configured)
- The recovery key is only stored when either changed or not present
What if users are not part of the local admin group?
The first user that joins a device to Azure AD is a member of the local admin group by default (unless you are using Windows AutoPilot). If a second user – part of the same AAD tenant – logs on to the device, it will be a standard user. This is typically used in the scenario where a Device Enrollment Manager account takes care of the Azure AD join before handing over the device to the end-user. For this scenario you will find a modified MSI (TriggerBitlockerUser) at the bottom of this blog, some changes are:
- The BitlockerTrigger scheduled task will run in the System Context and will:
- Copy the recovery key to the Azure AD account of the user who joined the device to AAD.
- Copy the recovery key to Systemdrive\temp (typically C:\Temp) temporarily.
- A new script MoveKeyToOD4B.ps1 is introduced and runs daily via a scheduled task called MoveKeyToOD4B. This scheduled task runs in the users context. The recovery key will be moved from systemdrive\temp to the OneDrive for Business\recovery folder.
If you are going to use this alternative scenario, make sure to download TriggerBitlockerUser at the bottom of this post. Deploy this via Intune to the group of end-users, not the Device Enrollment Manager group/account used to join the device to Azure AD.
How can users get access to their recovery key?
This recovery key is written to two locations, both the Azure AD account and into a recovery folder in the OneDrive for Business (if configured). Users can retrieve the recovery key via http://myapps.microsoft.com and navigating to their profile, or in their OneDrive for Business\recovery folder.
Azure AD (make sure you log on with the account used to join the device to AAD):
OneDrive for Business:
Important to know:
- After the script has run (most likely after 2 PM) a reboot will be required before the initial BitLocker encryption starts - users will be prompted. You could force a reboot by changing the scripts. The recovery key will be written to Azure AD and/or OneDrive For Business the next time the scheduled task is run, this could be 2 PM the next day.
- Upload the MSI to Intune as a "Line-of-business" app. I've successfully tested by deploying towards a User Group as "required" using the new portal at http://portal.azure.com.
- The script doesn't take any potential 3rd party encryption software into account. Only deploy this MSI to devices where BitLocker will be the only disk encryption solution in place.
- BitLocker won't start the encryption process if any removable drives are attached/mounted. Automatic removal can also be added to the script (see the comment from Jos Lieben below).
- Please test this MSI on your own devices and in your own environment before broadly deploying.
- This solution has only been tested on Windows 10 1703 x64. You can even test on a Virtual Machine, as long as you assign a Virtual TPM.
- Consider using Microsoft Intune Compliance policies in combination with Conditional Access to make sure only BitLocker encrypted devices can access company resources.
A lot of time and testing has gone into this project, if you find it useful - please consider leaving a reply.
- June 21 - 2017
- Uninstall removes the scheduled task(s)
- If available, uses new PowerShell commandlet to backup key to AAD
- Use TLS1.2 when connecting to AAD
- Better error handling and minor reliability fixes in script
- August 1 - 2017
- Better error handling in non-admin scenario (TriggerBitlockerUser).