With Windows 10’s new features, the productivity of users has increased leaps and bounds. That’s because Windows 10 introduced its approach as ‘Mobile first, Cloud first’. It is nothing but the integration of mobile devices with the cloud technology. Windows 10 delivers the modern management of data using cloud-based device management solutions such as Microsoft Enterprise Mobility Suite (EMS). With this, users can access their data from anywhere and anytime. However, this kind of data also needs good security, which is possible with Bitlocker.
Bitlocker encryption for cloud data security
Bitlocker encryption configuration is already available on the Windows 10 mobile devices. However, these devices needed to have InstantGo capability to automate the configuration. With InstantGo, the user could automate the configuration on the device as well as backup the recovery key to the user’s Azure AD account.
But now the devices will not require the InstantGo capability anymore. With Windows 10 Creators Update, all Windows 10 devices will have a wizard where users are prompted to start the Bitlocker encryption regardless of the hardware used. This was mainly the result of users’ feedback about the configuration, where they wished to have this encryption automated without having the users do anything. Thus, now the Bitlocker encryption has become automatic and hardware independent.
How does the Bitlocker encryption work
When the end-user enrolls the device and is a local admin, the TriggerBitlocker MSI 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 2 PM and will do the following:
- Run Enable_Bitlocker.vbs which the 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
Users who are not part of the local admin group, need to follow a different procedure. By default, the first user that joins a device to Azure AD is a member of the local admin group. If a second user, who is a part of the same AAD tenant, logs on to the device, it will be a standard user.
This bifurcation is necessary when a Device Enrollment Manager account takes care of the Azure AD join before handing over the device to the end-user. For such users modified MSI (TriggerBitlockerUser) has been given Windows team. It is slightly different from that of local admin users:
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.
For the non-local admin scenarios, users need to deploy the TriggerBitlockerUser file via Intune to the group of end-users. This is not deployed to the Device Enrollment Manager group/account used to join the device to Azure AD.
To get the access to the recovery key, users need to go to either of the following locations:
- Azure AD account
- A recovery folder in the OneDrive for Business (if configured).
Users are suggested to retrieve the recovery key via http://myapps.microsoft.com and navigate to their profile, or in their OneDrive for Business\recovery folder.
For more information on how to enable the Bitlocker encryption, read the complete blog on Microsoft TechNet.
Leave a Reply