How to migrate BitLocker to Workspace ONE
Most costumers already have BitLocker in place for drive encryption. It is a free possibility to encrypt the hard disk with Windows built-in mechanism. Also, the management of the recovery key is quite easy, because it is possible to safe the recovery key to Active Directory or even Azure Active Directory. For most customers there is no need for a separate management solution like MBAM (Microsoft BitLocker Administration Management) or McAfee Management of Native Encryption (MNE).
The benefits of using Workspace ONE for managing BitLocker are:
- Single point of contact – all device data on one platform
- easy to take over management from other solutions
- easy to manage via profiles
- good reporting
- compliance checks and remediation
- self-service portal for end users
The following topics will be covered in this article:
- Prerequisites
- Breakout – why pre-boot authentication is not necessary anymore?
- Without pre-boot authentication
- With pre-boot authentication
- Summary
Prerequisites
- Create a BitLocker encryption profile in Workspace ONE
- Make sure you activated the checkbox for “Default to System Encryption Method” – otherwise the already encrypted devices will report an error because they might be encrypted with another encryption algorithm.
- Also make sure you entered the right custom URL for the recovery screen. With this URL the user is able to get the recovery key with another device.
The URL for the Workspace One self service portal has the following schema:
https://[Your Device Services Host Name]/MyDevice
Breakout – why pre-boot authentication is not necessary anymore?
Here is my reason why I think you can disable the PIN on BitLocker:
First, you have to ask yourself the question, what is the purpose of pre-boot authentication. This should protect Windows devices from physical attacks.
Mainly it was about DMA ports that allow direct access to RAM and thus it would be possible to read data directly from memory. However, this functionality can be prevented with appropriate GPOs, and from Windows 10 1803 with the kernel DMA protection.
This does not provide 100% protection, because at the time when the BitLocker releases the hard disk, there is a small window of time until the policy is pulled, when this function is not yet blocked.
The time window in which this happens is very, very limited, so the attacker must be very skilled.
With the interaction of Windows Defender Credential Guard (https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard) and TPM Lockout (https://docs.microsoft.com/en-us/windows/security/information-protection/tpm/manage-tpm-lockout) brute-force and pass-the-hash-ticket attacks are useless.
There are even more security-relevant settings that make it more difficult to read out of RAM (of course only after Windows has been loaded):
https://docs.microsoft.com/en-us/windows/security/threat-protection/overview-of-threat-mitigations-in-windows-10#kernel-pool-protections
Microsoft recently started recommending pre-boot authentication again (this was different in Windows 8 and in the beginning of Windows 10):
https://docs.microsoft.com/en-us/windows/security/information-protection/BitLocker/BitLocker-countermeasures
But you always must see the additional effort of users and also of the administration and ask yourself how high is the probability that such an experienced attacker gets a notebook.
Furthermore, with Enterprise Wipe there is the possibility to “delete” the device remotely – of course, the device must be connected to the Internet for this.
You should not underestimate the added value of the simple login for the user, which is why I personally have been in favor of BitLocker without a PIN for years and why many of my former customers (except for German government agencies which unfortunately depend on the BSI (German Information Security agency) have chosen BitLocker without a PIN for Windows 10.
Of course, devices that are particularly worthy of protection should still be provided with Pre-Boot Auth (e.g. research and development etc.).
Without pre-boot authentication
The following examples are for BitLocker management without the use of pre-boot authentication – like PIN.
Active Directory managed BitLocker
Let’s start with the most common one – the recovery key is stored in Active Directory.
Most customers using BitLocker pre-provisioning during the initial imaging process. That means, that the device will be fully encrypted when the user receives the device. The BitLocker activation will be done once the device is fully booted – so after the restart from Windows PE to the new Windows installation. In this scenario the device will safe the recovery key to Active Directory.
There is no built-in end user self-service which means that there is always a support call is required to get the recovery key.
How to migrate
It is straight forward and easy to do because there is not much to do.
If you have any GPO for BitLocker configured make sure it doesn’t override the BitLocker profile (for more information, see THIS post). So best way would be create either a dedicated OU for the migration or exclude the devices from the BitLocker GPO.
After you disabled/unassigned all GPO’s, you assign the BitLocker profile to the device. After a few minutes Workspace ONE take overs the management and will save the recovery key to the Workspace ONE database.
How it works
First, we take a look at the manage-bde -status on the device.
We see that the device is fully encrypted and uses XTS-AES 128bit encryption.
The Workspace ONE Profile is configured to use XTS-AES 265bit encryption.
You can review the current recovery password with “manage-bde -protectors -get C:”
The current password is:
275517-643753-336578-203973-606320-217019-678623-138842And the current recovery key that is stored in Active Directory is also the same key:
After the Workspace ONE BitLocker profile is assigned and installed, the key is also in the Workspace ONE console:
So, it is quite simple to migrate the management from BitLocker with standalone Active Directory to Workspace ONE.
Azure Active Directory managed BitLocker
The process is nearly the same if you are using Azure Active Directory instead of on-prem Active Directory.
The only difference is that you don’t have any GPO’s here – so it’s even easier to migrate.
Also so you have the opportunity to use a self-service portal so the user is able to get his recovery key by its own.
How it works?
Starting with the manage-bde status:
And the protectors:
The current recovery password is:
178563-681362-389829-094952-443058-478357-150865-018997The same recovery key is stored in AAD:
After we checked that the recovery keys are the same, we take over the management with Workspace ONE by assigning the BitLocker profile to the device.
And now we see a small but significant difference:
Workspace One will add a recovery key after it takes over the management.
When looking locally on the client with manage-bde we see that there now two passwords stored.
Hybrid-Join scenario
There is not much to talk about in a hybrid-join scenario – the client behavior is the same as in the Azure Active Directory scenario. Means, that the recovery key gets added after Workspace ONE takes over the management.
3rd Party BitLocker management
This topic is already described in this article:
Also, straight forward – remove the agent and assign the Workspace ONE profile to the device.
MBAM managed BitLocker
MBAM was an easy way to have a reporting function for BitLocker. But due to the high effort of making the databases high available most customers decided against MBAM. For all customers that still uses MBAM – time to migrate! Windows 10 1903 looks like the last version that is supported.
For all that need to migrate – here is how you can easily migrate to Workspace ONE.
How it works
We assume that the device is encrypted and managed by MBAM.
The device is encrypted and managed with MBAM. Like before – the device is encrypted with 128 Bit XTS-AES.
And the protectors:
The recovery key is stored in MBAM – in this case we can access the recovery key via self-service portal.
After removing the GPO’s for MBAM management, we can assign the BitLocker profile to the device.
As soon as the profile is installed, the recovery key is stored in Workspace ONE. Also like in the Azure Active Directory scenario, the key is created by Workspace ONE.
Like in the AAD scenario, the new recovery password is added to the protectors configuration.
With pre-boot authentication
There are two different scenarios we cover. 1st is to remove the pre-boot authentication; 2nd is to reset the PIN. In both scenarios the devices are AAD joined.
- Remove PIN during migration
- Keep PIN during migration
Remove PIN during migration
I’ve already written why it could be possible to remove the pre-boot authentication. For removing the PIN during the migration you have not to use the option:
If your device is currently configured to use a pre-boot PIN the client shows the following status in manage-bde:
So configured are TPM and PIN as protectors.
After the BitLocker profile is assigned and installed, the key protectors look like this:
Means that the profile without activated “Enforce Encryption PIN on Login” will remove the pre-boot authentication.
The new recovery key is added to the device and saved to Workspace ONE.
Keep PIN during migration
If you want to keep the pre-boot pin you need to set the “Enforce Encryption PIN on Login” setting to enable.
The current system is encrypted and has TPM and PIN as protectors configured.
In the protectors view we see, that TPM and PIN are configured, and the recovery password is set.
Recovery key is saved in AAD.
After applying the BitLocker profile to the device, the PIN is removed from the proctor list.
The recovery key is already saved to Workspace ONE
Thanks to the setting we activated in the profile, the intelligent hub agent pops up and asks for a new pre-boot PIN.
After adding the pin via the hub agent, PIN is also added again to the proctor list and is fully configured.
Means, that there is NO decryption and re-encryption. The only thing that is temporary removed is the PIN itself. After setting the PIN again the configuration is the same as before – only managed by Workspace ONE.
MBAM with pre-boot PIN
If you are using MBAM with pre-boot PIN the migration behavior is basically the same like without.
Means you need to enable the setting “Enforce Encryption PIN on Login” to use the PIN – if you don’t enable the profile setting, the PIN gets removed.
The starting position is like always the device is encrypted and managed by MBAM.
As you can see the devices is configured with TPM and PIN.
The recovery key is stored in the MBAM database.
After removing the MBAM GPO’s from the devices and assigning the BitLocker Workspace ONE profile, the PIN gets removed.
Now the Workspace ONE Intelligent Hub pops up and asks for a new PIN.
After setting the PIN via Intelligent Hun, the devise is configured again with the pre-boot PIN.
The recovery key that is added by Workspace ONE is saved to the Workspace ONE database.
Like in the previous section, the device is not decrypted during this process. The only thing that is changed is that the user needs to add a new PIN – and of cause it could be the old PIN if the PIN meets all criteria.
Summary
BitLocker migration to Workspace ONE is quite simple and straight forward in all scenarios.
Make sure that you have no policies (GPO’s, Scripts, SCCM compliance settings….) deployed to the device before you deploy the BitLocker Workspace ONE profile.
If you want to keep or add pre-boot Authentication, activate the option “Enforce Encryption PIN on Login” in the profile. If you want to disable the PIN or just don’t want to use the PIN, disable the setting.
There will be no decryption if you already use a pre-boot authentication with AD, AAD or MBAM.
Of cause there also will be no decryption during the migration of the BitLocker management.
Empowering customers in client management since 2012.
Empowering customers in modern management since 2018.