BitLocker in modern device management: Automating recovery key escrow

Security is a top priority in all enterprise IT teams. One important security requirement enterprises look to address is the protection of corporate data at rest on devices, and thus provide data protection in the event of a device being lost or stolen.

BitLocker Drive Encryption is the Microsoft tool that can satisfy this use case and is included as part of Windows 10 Pro, Enterprise and Educational editions. BitLocker has been around since the days of Windows Vista and today is considered one of the most important security features included in Windows 10. Since BitLocker is native to the OS and does not require additional licensing, it becomes an attractive encryption mechanism.  However, organisations need to understand the costs to escrow the encryption key, enable self-service recovery of the key, and what service level is required to restore a computer in the event of a failure.  Depending on the requirements, enterprises can see a reduction in management costs compared to third-party tools or they can experience a significant increase in total cost.

The key challenge faced by enterprises, as they look to uplift machines to secure Windows 10 and move towards the modern management model, is an automated way to enable BitLocker and escrowing of the recovery key to a secure location that provides self-service recovery. Unfortunately, the maturity of automation is not as mature as with traditional PC management with Group Policies and key escrow with Microsoft BitLocker Administration and Monitoring (MBAM).

While modern devices with Connected Standby / Instant Go certification will automatically enable BitLocker and escrow the key by performing an Azure Domain Join (use of Azure AD Premium provides self-service to retrieve the recovery key), the majority of devices within the enterprise today do not meet this criterion.  While Microsoft continues to improve the BitLocker Configuration Service Provider (CSP) that is utilized by mobile device management consoles such as Airwatch and Intune, as of Windows 10 Creators (1703), the CSP does not yet support the full automation of BitLocker enablement and key escrow to Azure AD for non-InstantGo devices. Consequently, this activity must be carried out by the user performing some BitLocker configuration steps manually.

Technical Context

This section briefly introduces key technical components to be discussed, and sets a common baseline for wide readership.

The following components discussed are intrinsic to the BitLocker security feature. In developing a solution, the key issue is understanding the limitations that exist for BitLocker key escrow and how this translates to lightweight management of Windows 10 devices that are Azure AD joined.

The following diagram outlines the typical scenario envisioned for BitLocker key escrow for each management style.

Figure 1: Traditional BitLocker vs Modern BitLocker Management

BitLocker recovery key

Once BitLocker Drive Encryption is used to encrypt the local drive on a device, it is a common enterprise requirement to backup the recovery key. The recovery key is needed to unlock your device in the event it goes into recovery mode.

There are several reasons that could mandate that a PC enter the recovery mode. For example, your organization might have a password security policy that locks you out after a certain number of failed attempts to sign in. Or perhaps your PC encountered a hardware malfunction, an unexpected configuration change such as a firmware update, or a security event. Requiring a recovery key helps ensure that only an authorized person can unlock your PC and restore access to your encrypted data.

BitLocker recovery key escrow

Storing the recovery key in a safe yet accessible location in the event of experiencing a device lockout is a fundamental consideration to any BitLocker implementation. With traditional device management where the device is on premises AD joined, there are two options when it comes to the automatic BitLocker key escrow. You could either escrow the keys to the computer object in Active Directory, which requires certain Group Policy Objects (GPO), or implement a Microsoft BitLocker Administration and Monitoring (MBAM) server.

MBAM provides a simplified administrative interface that you can use to manage and monitor BitLocker Drive Encryption in the enterprise. MBAM requires Microsoft Desktop Optimization Pack (MDOP), which is part of the Software Assurance licensing model, but it’s not a given that all organisations have this by default. MBAM requires devices to be on premises AD domain joined.

Since both the Active Directory with GPOs and the MBAM method both require the devices to be domain joined, they cannot be used to support devices that are Azure AD joined.

In the new lightweight management model where devices are Azure AD joined, Microsoft’s vision for BitLocker key escrow is that the recovery key would be saved to the computer object in Azure. Users can access their recovery key by going to the Azure MyApps portal. (Sign in with your organization’s Office 365 credentials.)

InstantGo-capable device

InstantGo (formerly known as Connected Standby) is a very low power state that a limited number of hardware devices support. It maintains network connectivity when your screen is off in standby mode, allowing the system to update things in the background, and keeping it ready to instantly resume. Examples include: sync your email, or Skype calls still reaching you while the screen is off. InstantGo was developed based on the requirement to reduce power consumption when in standby mode and to be instantly ready for your next interaction.

As soon as an InstantGo-capable device running Windows 10 is joined to Azure Active Directory, BitLocker is enabled automatically and the local drive is encrypted while the BitLocker recovery key is escrowed to the computer record in Azure AD.

As of Windows 10 Creators, non-InstantGo-capable devices are not yet supported when using the BitLocker CSP to automate BitLocker and the escrowing of the Recovery Key to Azure AD. Consequently, this activity must be carried out by the user using the BitLocker application from within the running Windows 10 OS.

Azure AD

With the industry move to the cloud services, Microsoft has provided Active Directory in the cloud, known as Azure Active Directory. It provides identity and access management from the cloud to both cloud and on-premises resources. Azure AD also provides enhanced identity security with the use of Multi Factor Authentication (MFA).

Key challenges

BitLocker CSP does not provide automatic BitLocker enablement and key escrow to Azure AD for non-InstantGo devices. For DXC Technology customers who have a security requirement to enforce automatic BitLocker encryption with key escrow, an alternative approach is required. The challenges faced with securing non-InstantGo Windows 10 devices considered by this tech brief are:

  1. Automate the BitLocker enablement and key escrow upon Azure AD join for non-InstantGo devices.
  2. Minimize or remove the end user effort to secure the device.

DXC Automated BitLocker Enablement

The DXC approach defined below addresses the requirement for automatic BitLocker enablement and key escrow to Azure AD for non-InstantGo devices and proposes the use of a PowerShell script, packaged into a single MSI file so that it can be deployed via Intune upon device enrollment.

The diagram below provides a visual representation of this alternative approach.

Figure 2: Automate BitLocker enablement and key escrow approach

The BitLocker enablement PowerShell script is available here.

This approach has already been implemented into a customer account and demonstrates the value of a partnership with DXC.

Simplify user self-service BitLocker enablement

Microsoft has acknowledged the need to automate BitLocker enablement for non-InstantGo devices, but as of yet has only developed OMA-URIs that can simplify the user experience.

With the release of Windows 10 Creators Update (1703), there are four OMA-URI settings that can be deployed via Intune policy to simplify the manual end user experience.

./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption
./Device/Vendor/MSFT/BitLocker/AllowWarningForOtherDiskEncryption
./Device/Vendor/MSFT/BitLocker/EncryptionMethodByDriveType
./Device/Vendor/MSFT/BitLocker/SystemDrivesRecoveryOptions

The first setting “/RequireDeviceEncryption” displays a “Toast” notification to the end user, encouraging him or her to enable BitLocker.

The next three reduce the BitLocker screens the end user needs to navigate in order to enable BitLocker by allowing the Intune administrator to pre-configure the responses. The diagram below provides a visual representation of how these settings are deployed to simplify the manual BitLocker enablement and key escrow process.

Figure 3: Intune OMA-URI settings simplify end user BitLocker enablement

Further BitLocker CSP policy details are available here.

InstantGo enabled devices — caveat

As has been mentioned earlier, InstantGo capable devices will have BitLocker automatically enabled and the key escrowed to Azure once they are Azure AD joined and enrolled into Intune. Where devices are shipped with a default Windows 10 build, the default BitLocker encryption method and Cipher strength of XTS-AES 128-bit is used upon Azure AD join.

What is not apparent is that DXC customers who have a requirement to use an increased encryption method and cipher strength should be made aware that the default Windows 10 image with InstantGo-capable devices will not meet their requirement.

To meet this requirement you have to set the BitLocker configuration prior to the Azure AD join, as changing the encryption method has no effect if the drive is already encrypted or if the encryption is in progress. To achieve this it is recommend to leverage the DXC Lightweight image, which can have the increased encryption method and Cipher strength pre-configured.

Conclusion

This blog identified an issue associated with securing a Windows 10 device with BitLocker in the modern management model with automation. Microsoft had not fully considered this use case, given its focus on hardware-specific devices at the expense of legacy device design considerations. As a result, the ability to automate BitLocker recovery key escrow to Azure AD join is not yet natively supported. This blog details the DXC method for addressing this.

Microsoft has been informed, a resolution to this agreed, and it is now on Microsoft’s roadmap, which the company expects to address with Windows 10 RS3, due out in late 2017.


Paul O’Connor is the converged management architect in DXC Technology’s Workplace and Mobility product development group based in Galway, Ireland. Paul has deep architectural and engineering skills, with a focus on Microsoft System Center and Microsoft Enterprise Mobility and Security. Connect with Paul on Twitter at @E30paul and on LinkedIn.

RELATED LINKS

Empowering workforces with invisible IT

DXC and Microsoft: The power of partnership

Industry 4.0 and IoT pose new security challenges

Comments

  1. Manjunath Bhat says:

    Does the end user on the PC need local administrator rights? or can it be a standard user?

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

%d bloggers like this: