Intune Silent Encryption – A Deeper Dive to Explore the Internal- Part 4

I hope you all had a great time in celebrating the New Year with your loved ones. Good to meet again on this side of 2020.

Won’t spend much time on the intro as this is a continuation from where I left off in my previous article on Bitlocker Drive Encryption. If you have not read it yet, I would suggest to read that first before continuing with this.

Related Posts

• Part 1 – Bitlocker Unlocked with Joy – Behind the Scenes Windows 10
• Part 2 – Device Encryption – Bitlocker made Effortless
• Part 3 – Deciphering Intune’s Scope w.r.t Bitlocker Drive Encryption
• Part 4 – Intune and Silent Encryption – A Deeper Dive to Explore the Internal

Introduction

In this post, I will be talking mainly about

• What Remediation failed status for Configuration and Compliance means for Bitlocker?
• How to validate the failure cause of Bitlocker policy as deployed from Intune?

Also, I will cover in details, two common but mostly unexplained errors regarding Silent Encryption. And yes, at the end, I will show how it is actually implemented – a sneak peek into WMI provider class.

So let’s get started.

Bitlocker Drive Encryption Remediation Failed – A generic error?

If you check the per-settings status of the Bitlocker configuration profile, for an “all-went-good” scenario, you will see success for each settings, as below

But in reality and most cases, post deploying the policy and confirming the policy has hit the device, you will see success for all the settings except Encrypt devices

The Remediation failed error status is generic in true sense and can be due to

• Device yet to report back enforcement status to Intune.
• Encryption process failed to initiate with the configured policy settings.

How Intune gets to know the enforcement status?

When Intune generates a PUSH (ADD/REPLACE DM command) to SET some feature on the device, it also generates a simultaneous GET to track the status of the enforcement.

 <Get>
    <CmdID>28</CmdID>
       <Item>
         <Target>
           <LocURI>./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption</LocURI>
         </Target>
       </Item>
     </Get>
  <Get> 

GET operation on RequireDeviceEncryption returns the actual status of enforcement. Setting (ADD/REPLACE) this policy to 1 triggers encryption, but status of enforcement is retrieved post encryption operation completes successfully.

DM client sends the RESULT of the GET once the enforcement is complete for the ADD/REPLACE DM command on RequireDeviceEncryption.

 <Results>
       <CmdID>36</CmdID>
       <MsgRef>2</MsgRef>
       <CmdRef>28</CmdRef>
       <Item>
         <Source>
           <LocURI>./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption</LocURI>
         </Source>
         <Meta>
           <Format xmlns="syncml:metinf">int</Format>
         </Meta>
         <Data>1</Data>
       </Item>
  </Results>

The enforcement status depends on the time to complete the encryption which again depends on the amount of data in the drive.

To validate if Remediation failed error is truly an enforcement error, you need to check the encryption status manually on the device.

As such, if you see the Remediation failed for Encrypt devices property of the profile in Intune, you need to check the encryption status of the device (manage-bde -status). If you see that encryption process is in progress, then the device is yet to report back enforcement status as operration is yet to complete. Once you see encryption is complete, a manual SYNC (either device end/admin initiated from portal) will change the profile status in Intune.

However if you see the drive state as Fully decrypted, this is an enforcement error and needs validation to get to the failure cause.

If the device got encrypted due to automatic encryption, it will use the default AES-XTS 128 bit alogorithm. In such a scenario, if your silent encryption profile is also configured to use the same, then it will show as succes, but if it requires a different algorithm or key strenght, it will result in same error.

Enforcement failure reasons are discussed in details later on…

Why compliance policy has two settings for Bitlocker Encryption status evaluation?

When you create a Compliance Policy for Windows 10, you might have noticed that there are two settings available to evaluate encryption status on an endpoint.

• Encryption of data storage on device under System Security node as shown below
• Require Bitlocker settings under Device Health node

For Windows 10 version till 1809, the compliance settings property Encryption of data storage on device is based on the DeviceStatus CSP node.

This is a check to see if the encryption on the device is as per the targeted config policy and as such is mapped to RequireDeviceEncryption node of Bitlocker CSP. As such, till the time, Encrypt devices in Config policy shows Remediation failed error, the compliance counterpart will also show the same error.

The OMA-DM sync session trace looks as below

DM server initiates the status evaluation

<Get>
       <CmdID>14</CmdID>
       <Item>
         <Target>
          <LocURI>./Vendor/MSFT/DeviceStatus/Compliance/EncryptionCompliance</LocURI>
         </Target>
       </Item>
 </Get> 

DM client invokes DeviceStatus CSP (see LocURI) to handle the request, which evaluates the compliance state, with two possible outcomes

• 0 – Not encrypted as per config policy
• 1 – Encrypted as per config policy

Based on the evaluation, DM Client sends the respond back.

<Results>
       <CmdID>18</CmdID>
       <MsgRef>2</MsgRef>
       <CmdRef>14</CmdRef>
       <Item>
         <Source>
           <LocURI>./Vendor/MSFT/DeviceStatus/Compliance/EncryptionCompliance</LocURI>
         </Source>
         <Meta>
           <Format xmlns="syncml:metinf">bool</Format>
         </Meta>
         <Data>1</Data>
       </Item>
</Results> 

If the device is truly encrypted with the enforced settings, as the response is received by the DM server (Intune), status of the property setting changes to Compliant.

With Windows 10 version 1903, Microsoft introduced the node DeviceEncryptionStatus in Bitlocker CSP which also aids to evaluate the encryption status, tagged to the same compliance settings property.

Hence from 1903 onwards, you would also see the below DM message stream in the sync session

<Get>
       <CmdID>15</CmdID>
       <Item>
         <Target>
          <LocURI>./Device/Vendor/MSFT/BitLocker/Status/DeviceEncryptionStatus</LocURI>
         </Target>
       </Item>
     </Get>
 <Get>
  
 <Results>
       <CmdID>20</CmdID>
       <MsgRef>2</MsgRef>
       <CmdRef>15</CmdRef>
       <Item>
         <Source>
          <LocURI>./Device/Vendor/MSFT/BitLocker/Status/DeviceEncryptionStatus</LocURI>
         </Source>
         <Meta>
           <Format xmlns="syncml:metinf">int</Format>
         </Meta>
         <Data>2</Data>
       </Item>
  </Results> 

This evaluation is a general check of the encryption status at the OS level.

However, noticed the above snap. Though Encryption of data storage on device shows Complaint but Require Bitlocker still shows as Not Compliant.

Why is this discrepancy?

Require Bitlocker evaluation is different from Encryption of data storage on device. It depends on the DHA service and is more robust as it ensures the presence of Bitlocker at the TPM level.

I have already explained role of DHA w.r.t Intune compliance in my other article titled “Understanding Device Health Attestation Intune Device Compliance Check“

To explain in short,

DHA evaluation is based on TCG log which gets generated at the boot time. Any changes being made to device configuration post boot will not be present in the current TCG log available.

Since Bitlocker policy gets applied to the device post device boots, as such, even if configuration profile parameter Encrypt device shows as Succeeded, and also the compliance parameter Encryption of data storage on device shows Compliant, the current TCG log won’t have any entry for Bitlocker.

The TCG log gets refreshed during a restart, which causes generation of new TCG log to be sent to the DHA service, based on which the DHA service sends DHA-validation-data (device heath cert) to the device.

Intune retrieves this DHA-validation-data (device health cert) and checks back with the DHA service to validate the same for compliance evaluation.

This is how you see it in a OMA-DM sync

<Get>
       <CmdID>14</CmdID>
       <Item>
         <Target>
           <LocURI>./Vendor/MSFT/HealthAttestation/Certificate</LocURI>
         </Target>
       </Item>
</Get> 

On response the DM-Client sends the DHA-Validation-Data (if present, else will send a Not Now command and initiate a session with DHA to get the DHA-Validation-Data)

<Results>        <CmdID>15</CmdID>        <MsgRef>3</MsgRef>        <CmdRef>14</CmdRef>        <Item>          <Source>            <LocURI>./Vendor/MSFT/HealthAttestation/Certificate</LocURI>          </Source>          <Data> {DHA-Validation-Data} based on current TCG log (PCR Measurement) </Data>        </Item> </Results> 

If config profile property Encrypt devices show Success and Compliance property Encryption of data storage on device shows Compliant, but Require Bitlocker property of Compliance shows Not-Compliant – the device needs a RESTART. Post restart, initiate a SYNC and the device compliance status will change shortly.

Now, let’s move on to next part, which will let you know how to validate the policy deployment on the device.

Device End validation of the Encryption profile

Check the Work Account

Here you will see an overview of all the features that are being managed from management server. Check if Bitlocker is listed under managed Policies.

Check the MDM Diagnostic report

The diagnostic report will show you in details, the policy settings that came from management service with the default and current values for the particular feature.

Check the registry to see if the intended policy values has been applied

Reg_path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker

You will see the policy settings as configured listed here with the values. For some settings, like encryption method, you would see the corresponding reg_key points to another reg_item.

This is because, the policy settings as received are first implemented under Reg_path:  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\Providers\<Provider GUID>\default\Device\BitLocker from where it gets implemented to the current node of PolicyManager which then triggers the encryption process.

At this point you can confirm if the policy settings as configured in the portal got implemented at the device level or not. Once the policy gets implemented at the registry level, it is the Bitlocker components present in the OS that takes over.

Check the encryption status on the device

The most easy way to check encryption status is to use the manage-bde command line tool

The important parameters are Conversion Status and Protection Status. I can see that encryption is complete using the cipher strength/algorithm as I specified in the policy. With this, let’s see the success events

Check the Bitlocker-API events

For a successful encryption, you get the below events as listed

Event ID 796: Bitlocker Drive Encryption is using software-based encryption to protect volume C:
Event ID 768: Bitlocker encryption was started for Volume C: using XTS-AES 256 algorithm.
Event ID 775: A Bitlocker key protector was created. Protector GUID: <> Identification GUID: <>
Event ID 845: Bitlocker Drive Encryption recovery information for volume C: was backed up successfully to your Azure AD 
Event ID 817: Bitlocker successfully sealed a key to the TPM. PCRs measured include (7, 11) 

Now this was a validation run showing a typical success scenario.

But if you see that encryption status on device is still Fully decrypted and you get any error listed in Bitlocker API events, then as stated earlier, the Remediation failed error is an actual error.

In case device is enabled with Device encryption, the configured profile will be in conflict if you have chosen an encryption method other than AES-XTS 128 bit and as such will report as an enforcement failure. This is because, once the device has started encryption, or is already encrypted, you cannot change the encryption method.

For a properly configured profile to enable Silent Encryption, I have not seen any errors in implementation, neglecting device related issues. For most of the time, the error is due to misconfiguration of profile.

With this, let’s check the break points for Bitlocker Drive Encryption. Includes failure points for both Silent and User-aided enforcement flow.

Failure Points for Bitlocker Drive Encryption

• Presence of attached Bootable Media
• Invalid (corrupt) or no WinRE
• System in Legacy BIOS
• Failed to backup BitLocker Drive Encryption recovery information to Azure AD.

There are two more failure points, but with different outcomes for User-Aided vs Silent mode as I have seen.

• TPM not available (or non-compatible TPM)

In this case, if you have Bitlocker with non-compatible TPM chip set to Not configured

User aided mode still continues and will prompt you to create either StartupKey or PIN, but Silent Encryption will fail due to TPM requirement.

If you encounter this error, you need to confirm the TPM status on the device. TPM needs to be in Ready state.

• Secure Boot state Off

If Secure Boot is disabled, Bitlocker Drive Encryption will not be able to use the PCR 7 measurement to seal VMK to TPM.

PCR7 binding is a requirement for Silent Encryption

This essentially results in failure for Silent Encryption, but for user-aided mode, it will still proceed and seal the VMK to TPM using the PCR profiles 0, 2, 4, 11 (BIOS is UEFI mode)

The causes and resolutions for the above mentioned failure points are already covered in this Microsoft article as such I will not waste time re-explaining…

However, there are two more failure scenarios for Silent Encryption. Due to the lack of any good explanations to be found on the internet, I decided to explain them in details as below.

Failure scenario #1 – Silent Encryption failed due to Automatic Encryption

I have two profiles deployed to the device in context of Bitlocker

• Stop Automatic Encryption to prevent device to undergo Device Encryption
• Silent Bitlocker which is set to use AES-XTS 256 bit encryption method (pre boot auth is set to the defaults)

Snap of profile status of this device from portal shows both the policies “Stop Automatic Encryption” and “Silent Bitlocker” failed.

Note: This error also occurs if you actually do not have any profile to block automatic encryption during AADJ.

Since the policy to stop automatic encryption failed (whatsoever reason), during AADJ provisioning the device underwent Device Encryption. This resulted the silent Bitlocker policy to fail and report as an error. Let’s follow same validation check sequence that I explained above.

Drilling down the Silent Bitlocker policy, I see that it reports Error because Encrypt devices status is in Remediation failed state. As I checked for the Encryption status on the device, I see it is actually encrypted (?).

Did you noticed that it is not using the XTS-AES 256 bit algorithm as required by the policy but instead is using the XTS-AES 128 bit (default scheme) – an indication enough to understand the device got encrypted due to the automatic encryption triggered during AADJ provisioning.

If you require to have a cipher strength/algorithm different than the default that is used, you would first need to block the device from triggering automatic encryption (Device Encryption) during the provisioning. If the device starts automatic encryption, then even if you deploy an Endpoint policy that requires a different cipher algorithm/strength, the policy will get delivered to the device but it won’t get implemented and report back as error.

However, if your silent encryption profile matches the bitlocker default scheme as used by device encryption, this will not cause an error and report as success. Since enforcement check ensures if the device is encrypted with the policy settings which will match for defaults.

Let’s continue to see how we can make our Bitlocker policy to take effect on the same device.

Device already went through Automatic Encryption? How to revert and make your custom policy enforce silently…

First and foremost, we would need to manually decrypt the device. You can use the Bitlocker Management console from Control Panel or use the handy manage-bde tool.

Once manage-bde -status shows that Protection Status is Off and Conversion Status is Fully Decrypted, considering the Silent Bitlocker policy is still assigned, perform a SYNC and check the Bitlocker API events once more.

Event ID 770 (Warning) confirms that Bitlocker decryption started. 
Event ID 778 confirms that decryption is complete.

Post SYNC, in some cases you might come across these two events (I have only seen them once while testing)

(Warning) Event ID 816 - Bitlocker cannot use Secure Boot for integrity
because TCG Log for PCR [7] contains invalid entries. 
(Information) Event ID 834 stating Bitlocker determined that the TCG log
is invalid for use of Secure Boot.  

At this stage, though these are Warning and Information events only, but if not taken care of, can result in failure of Silent Encryption. To resolve this, you just need to restart your device.

TCG log is only generated during boot time as such anything that happens post boot is not present in the TCG logs. As such to refresh the TCG logs, you need to restart your device which causes re-generation of new TCG log with the updated changes.

Post restart, I ran SYNC once more and checked the events. The events for TCG log warnings did not reappear, and I could also see that Bitlocker Encryption got triggered using XTS-AES 256 bit algorithm as in the policy.

Failure Scenario #2 – Silent Encryption failed due to Conflicting GPO

To recreate this sceanrio, I made a few modifications to the Silent Bitlocker profile in Intune. It still uses the AES-XTS-256 bit encrypt method (which succeeded) but this time I have enforced a pre-boot auth check setting.

In this case, the profile Stop Automatic Encryption reports success and thus we can ignore automatic encryption to be the error cause for the silent encryption profile (as was in the previous case).

Checking the Encryption status of the device reveals the device is in fully decrypted state. Checking the MDM diagnostics shows that the intended policy has indeed been sent to the device and checking the registry shows that the policy settings implemented.

Where did it failed then? Checking the Bitlocker API event shows

(Error) Event ID 851 - Group Policy settings for Bitlocker startup
options are in conflict and cannot be applied

Conflicting GPO error in a cloud domain joined device?

On a Hybrid AAD joined system, this error may seem to be valid due to the chances of a GPO being applied to the OU of which the device is a part. But on an Azure AD joined Intune managed device, this error ideally makes no sense at the beginning.

If you encounter this error on an AADJ system and you check the RSOP data, you will see no Group Policies being applied, either to the System or User account. (Provided user has not manually edited any policy using gpedit.msc)

Generally the question comes, what is this GPO conflict error, when the device do not actually have any GPO applied?

Cause

The error occurs due to any of the reasons below

• Profile configuration has invalid pre-boot auth method.
• Profile configuration is not configured to backup Recovery information to AAD.

Silent Encryption does not supports enforcing startup authentication other than the default TPM. If your profile has authentication method set to Require for TPM+PIN or TPM+StartupKey, causes this failure.

Even if you set Allow TPM to Require than the default Allow, I have seen it results the same error…(?)

If recovery method is not set and is not configured to backup to AAD before enabling encryption, the profile fails with the same error event.

Explanation

The purpose of Silent Encryption is to trigger Bitlocker Drive Encryption without any user interaction or notification, imitating the style of Bitlocker Device Encryption.

This only happens if Bitlocker is set to use the default TPM only authentication method – no pre-boot authentication method. To set a pre-boot auth like PIN or StartupKey, Bitlocker needs to prompt the user which defies the purpose of Silent Encryption.

If you have not configured your profile to backup recovery info to AAD, causes Bitlocker to fail as this a mandate step in the Bitlocker Drive Encryption workflow for which it again needs to prompt user, which defies the purpose of Silent Encryption.

Now I think you will understand and agree with why I said that Silent Encryption fails due to misconfigured profile.

Bitlocker Drive Encryption – A look into the WMI

On an end device, you have the following tools at your disposal to play with Bitlocker

• PowerShell Bitlocker Module

• manage-bde tool

• Bitlocker Management GUI tool accessible from Control Panel

But all of these actually relies on WMI class Win32_EncryptableVolume which hosts all the methods and properties of available drives in the system.

The WMI class mentioned resides in the root\cimv2\security\MicrosoftVolumeEncryption namespace. Actually there is another WMI class on which Bitlocker operations depends, the Win32_TPM which resides under root\cimv2\security\MicrosoftTpm namespace.

In total, there are 86 methods available in the Win32_EncryptableVolume class responsible for Bitlocker operations.

Refer to https://docs.microsoft.com/en-us/windows/win32/secprov/win32-encryptablevolume-methods

All the actions that we perform over PS or via the Bitlocker Wizard or the Silent enforcement are actually facilitated via these methods of this WMI class.

For example, let us consider this small script snippet which queries the KeyProtectorIds for the System Drive.

$OSDrive=$env:SystemDrive 
$BLV = Get-BitLockerVolume -MountPoint $OSDrive
$BLV.KeyProtector

Behind the scene, this Get-BitLockerVolume cmdlet essentially makes a WMI query to the Win32_EncryptableVolume WMI class to use of the methods available for retrieving the required data. Sample script snippet

$OSDrive=$Env:SystemDrive
$Get-BitLockerVolume = Get-WmiObject -Namespace
"Root\cimv2\Security\MicrosoftVolumeEncryption" -Class "Win32_EncryptableVolume" -Filter "DriveLetter ='$OSDrive'" 

$Get-BitLockerVolume containing all the Bitlocker related data (unstructured raw form) for System Drive, you can play with you as you want

All the settings configured from Intune as well compliance evaluation of encryption status (except the DHA scenario) are facilitated by the methods of this WMI Provider class.

If the methods of Win32_EncryptableVolume WMI class facilitates Bitlocker operations, where are this methods implemented (?)

The methods of the Win32_EncryptableVolume WMI class is implemented in the functions exported via the “dlls” – fveapi.dll

To understand, let’s take a look at how the recovery key is stored to Azure AD.

• Using manage-bde tool, that would be “manage-bde -protectors -aadbackup C:” in the simplest form
• With PS script, the same can be achieved using BackupToAAD-BitLockerKeyProtector cmdlet
• BitlockerWizardElev.exe prompts user to Save to your Azure AD account

Behind the scene, all utilizes the BackupRecoveryInformationToCloudDomain method of the same Win32_EncryptableVolume WMI class.

This method is implemented in the function as exported via fveskybackup.dll which is statically linked to fveapi.dll

A few other activities are also involved with this task which is required like fetching the tenant info and device ID (as such you will see dsreg.dll linked with fveskybackup.dll since it uses the exported function DsrGetJoinInfo for tenant details). This is required as in the backend it creates a POST to send the key details to Azure AD which will be stored against the AAD device object.

Sample script snippet to mimic the actions

$url = "https://enterpriseregistration.windows.net/manage/$tenant/device/$($deviceid)?api-version=1.0"
$req = Invoke-WebRequest -Uri $url -Body $body -UseBasicParsing -Method
Post -UseDefaultCredentials -Certificate $cert
$req.RawContent 

where

$cert = Get-ChildItem Cert:\LocalMachine\My\ | Where-Object { $_.Issuer -match "CN=MS-Organization-Access" }
$id = $cert.Thumbprint
$tenant = (Get-ItemProperty
HKLM:\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\JoinInfo\$($id)).UserEmail.Split('@')[1]
$deviceid = $cert.Subject.Replace("CN=", "") 

$body in the $req is created as

$OSDrive = $env:SystemDrive
$keys = (Get-BitLockerVolume -MountPoint $OSDrive).KeyProtector | Where-Object {$_.KeyProtectorType -eq 'RecoveryPassword'} 
ForEach ($key in $keys) 
{
Write-Verbose "kid : $($key.KeyProtectorId) key: $($key.RecoveryPassword)"
$body="{""key"":""$($key.RecoveryPassword)"",""kid"":""$($key.KeyProtectorId.replace('{','').Replace('}',''))"",""vol"":""OSV""}"
} 

Note: This is a just simplified explanation to show the backup mechanism – saving the Recovery Key to Azure AD. Originally it uses the functions as implemented in the “dll” 

Finally The End…

If you have read till this investing your valuable time, I really hope that I made it worth it.

Before I end, I would like to give a shout out to Oliver Kieselbach for his excellent SyncML Viewer tool to trace OMA-DM sessions. All the traces which I have used are captured using this little powerful tool of his. Check out his blog post on the same here.

As this completes the Bitlocker series, which I started last year, now is time to take a break for me. Will return with some other topics on Intune, but as I say, till then, keep reading, keep learning…