Enabling BitLocker on non-HSTI devices with Intune

BitLocker-DriveThis is a post about enabling BitLocker on non-HSTI devices with Windows 10 version 1809 and standard user permissions.

First of all a little background on HSTI. HSTI is a Hardware Security Testability Interface. It is an interface to report the results of security-related self-tests. Its purpose is to provide high assurance validation of proper security configuration.

The enhancement with Windows 10 version 1809 is that we are able to activate BitLocker with a MDM policy (Intune), even for non-HSTI devices and on Windows 10 Pro Edition. This was not working with Windows 10 version 1803 or lower and the community came up with custom solutions to handle this like custom PowerShell scripts deployed via Intune Management Extension. If we wanted to use Intune native MDM policies via the BitLocker CSP we needed HSTI compliant devices like the Surface devices or newer hardware devices which are mostly delivered as HSTI compliant devices now. To successful start the encryption as a standard user, a Windows 10 version 1803 was the minimum as the feature was introduced with this version.

The prerequisites for Intune BitLocker configuration are

  • Windows 10 version 1809
  • Microsoft Intune
  • non-HSTI device

Older devices can be protected by Intune BitLocker policy now?

Yes, as long as they are running Windows 10 version 1809. The most common problem is that we do not replace all devices in every Windows 10 project to have only latest HSTI compliant devices in the environment. We have to support older devices purchased maybe not long ago but not HSTI compliant. These devices can now be managed by an Intune device configuration policy to turn on BitLocker silently without administrative permissions as long as the device is a Windows 10 version 1809 device.

 

What do we need to do?

Currently at the time of writing we need two configuration policies. One endpoint protection profile and a custom profile.

The endpoint protection profile configures the silent BitLocker enforcement and other parameters like encryption strength. Go to Microsoft Intune > Device configuration – Profiles > yourpolicyname – Properties > Endpoint protection > Windows Encryption

Set Encrypt devices to Require
Set Warning for other disk encryption to Block

Sure you can set other parameters like encryption methods as well, but for a functional test this is enough.

These two settings make sure the encryption starts and it starts silently as we block the warning dialog for other disk encryption software.

Example shown below:

BitLockerIntuneEndpointProtection

The second profile is a custom profile (at time of writing it was not available in the UI) and it configures the ability to enforce the BitLocker encryption even when standard users are logging in. For example when the Windows 10 device is enrolled with an Autopilot profile where the user account type is set to standard user. AllowStandardUserEncryption is a new setting introduced with Windows 10 version 1809 BitLocker CSP and must be used in conjunction with the setting “Warning for other disk encryption set to Block” otherwise it is not functional!

The custom OMA-URI configuration must be configured like this:

OMA-URI: ./Vendor/MSFT/BitLocker/AllowStandardUserEncryption
Data type: integer
Value: 1

Example shown below:

BitLockerIntuneCustom

The two policies must be assigned to a user group or device group to test the new policies. To force the user type to a standard user after enrollment we need an Autopilot profile and assign it to our device.

AutopilotStandardUser

If we now enroll a new Windows 10 version 1809 non-HSTI device it must be encrypted silently and the recovery key must be backed up to Azure AD.

 

How can I easily verify this?

I used a Hyper-V VM Generation 2 with an enabled TPM module:

BitLockerHyperVVMTPM

To test if the VM is reporting as a non-HSTI compliant device I downloaded the Device Guard and Credential Guard hardware readiness tool and verified the HSTI status with the following PowerShell command:

.\DG_Readiness_Tool_v3.5.ps1 -Capable

The result is displayed like this:

HyperVVMHSTICheck

During my test I had to make sure that after the first restart, the Windows 10 version 1809 ISO is ejected, otherwise silent BitLocker encryption will fail. This is because the system does not have the normal start parameters during the BitLocker and TPM provisioning. The platform would take into account the additional media as the normal platform verification parameter. Which means after ejecting the ISO it would have prompted us for the recovery key. Microsoft takes care of this situation and does not start the BitLocker provisioning process at all. So, the generation of the platform default configuration parameters for later verification to unlock the TPM is prevented, as long as a removable media is inserted. See the failure event here:

BitLockerSilentEncryptionErrorIso

Without an ISO it will successfully starts the encryption and key backup to Azure AD. A success event is shown below:

BitLockerVMeventlog

The BitLocker state can be verified with the PowerShell command on the client:

Get-BitLockerVolume | fl

BitLockerVMPSStatus

In the Intune portal we can see the recovery key appended to the AAD device object:

BitLockerIntuneAADDeviceRK

 

Further information

What’s new in Windows 10, version 1809 for IT Pros
https://docs.microsoft.com/en-us/windows/whats-new/whats-new-windows-10-version-1809#bitlocker

Device Guard and Credential Guard hardware readiness tool
https://www.microsoft.com/en-us/download/details.aspx?id=53337

Hardware Security Testability Specification
https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/hardware-security-testability-specification

 

Go ahead and start encrypting all your Windows 10 devices to strengthen your security level 👍

Configuring Windows Defender Credential Guard with Intune

The Windows Defender Credential Guard is a feature to protect NTLM, Kerberos and Sign-on credentials. Windows 10 Enterprise provides the capability to isolate certain Operating System (OS) pieces via so called virtualization-based security (VBS). NTLM and Kerberos credentials are normally stored in the Local Security Authority (LSA). Once VBS is enabled the LSASS process will be split into an isolated process (protected by virtualization based security)  called LSAiso and the LSASS process. The LSAiso process can not be accessed by other OS components than the LSASS. This approach protects credentials from malicious tools which gained system context access. A well known tool to accomplish extraction of credentials from LSASS in system context is Mimikatz. This will not work after enabling Windows Defender Credential Guard as the only process validated to gain access to LSAiso process is LSASS.

With that in mind Credential Guard can protect an attack vector used by a lot of bad guys trying to steal sensitive information. It’s really worth considering to turn this protection on for Windows 10 Enterprise x64 (no support for x86) devices.

CredentialGuardDesign

Further information of Credential Guard:
https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-how-it-works

 

How do we configure this via Modern Management in Intune?

Since Windows 10 Version 1709 Microsoft provides Policy CSP support to configure Credential Guard via custom OMA-URIs. We can create a custom device profile:

CreateDeviceProfile

and then choose Profile type: custom

CredentialGuardDeviceProfile

Here we add the following OMA-URIs to configure Credential Guard with default settings and additional DMA Protection:

Name: DeviceGuard/EnableVirtualizationBasedSecurity
OMA-URI: ./Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurity
Data type: integer
Value: 1 (enable virtualization based security)

Name: DeviceGuard/LsaCfgFlags
OMA-URI: ./Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlags
Data type: integer
Value: 1 (Enabled with UEFI lock)

Name: DeviceGuard/RequirePlatformSecurityFeatures
OMA-URI: ./Vendor/MSFT/Policy/Config/DeviceGuard/RequirePlatformSecurityFeatures
Data type: integer
Value: 3 (Turns on VBS with Secure Boot and direct memory access (DMA). DMA requires hardware support.)

Further information regarding Policy CSP values:
https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-deviceguard

As a last step we assign the new device configuration profile to our user group we want to provide the additional Credential Guard protection.

 

How to verify successful configuration?

First of all we verify if Intune applied the configuration successfully:

CredentialGuardDeploymentStatus

Then you can verify the applied registry settings on the target device of the user:

CredentialGuardRegistrySettings

Further information regarding registry settings:
https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-manage

Make sure the device was restarted after successful configuration! This is needed as Credential Guard relies on Hyper-V technology for virtualization-based security and therefore it will enable the feature Hyper-V Hypervisor component.

We can have a look for the LsaIso.exe process in task manager:

CredentialGuardProcess

Finally we open up msinfo32.exe and verify if virtualization-based security is running and Credential Guard is activated:

CredentialGuardMsinfo32

If everything went well your machine is now protected against stealing of password secrets (hashes) which can be used by attackers for Pass-The-Hash (PTH) attacks. Keep in mind that this will not protect against attacks like key loggers. The solution is an effective way to protect credential stealing from memory.

 

How to test this in a Hyper-V Virtual Machine?

When using Microsoft Hyper-V you can enable nested virtualization on the VM and enable the Trusted Platform Module. Now you can test Credential Guard in your Hyper-V VM.

Enabling nested virtualization on Hyper-V VM:

Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true

Further information on nested virtualization:
https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization

Enabling the TPM on Hyper-V VM:

HyperVTPM

 

Additional things to consider?

The target hardware must support Credential Guard
https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-requirements

Compatibility problems
https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-considerations

Limitation in protection
https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-protection-limits

 

UPDATE

Virtualization based security (VBS) will be available for non-Enterprise SKUs and starting with RS4+ VBS will be automatically enabled for clean installs!

 

If you are using Windows 10 please try Credential Guard in your environment as it is a really big security enhancement of Windows 10 Enterprise.