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

I hope you all enjoyed celebrating the New Year with your loved ones. It will be good to meet again on this side of 2020.

I won’t spend much time on the intro as this continues my previous article on Bitlocker Drive Encryption. If you have not read it yet, I suggest reading that first before continuing with this.

• 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

In this post, I will be talking mainly about

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

Also, I will cover in detail 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 the WMI provider class.

Index
Bitlocker Drive Encryption Remediation Failed – A generic error?
Why does the compliance policy have two Bitlocker Drive Encryption status evaluation settings?
Why is there a discrepancy?
Failure Points for Bitlocker Drive Encryption
Failure scenario #1 – Silent Encryption failed due to Automatic Encryption
Failure Scenario #2 – Silent Encryption failed due to Conflicting GPO
Bitlocker Drive Encryption – A look into the WMI
Finally, The End (Bitlocker Drive Encryption)

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 setting, 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

• The device has yet to report back enforcement status to Intune.
• The encryption process failed to initiate with the configured policy settings.

How does Intune get 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 enforcement status.

 <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.

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

 <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 it takes to complete the encryption, which again depends on the amount of data in the drive.

To validate if the 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 the 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 the encryption process is in progress, the device has yet to report back enforcement status as the operation is complete. Once you see encryption is complete, a manual SYNC (either device end or admin initiated from the portal) will change the profile status in Intune.

However, if you see the drive state as fully decrypted, this enforcement error needs to be validated to determine the failure cause.

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

Enforcement failure reasons are discussed in detail later on…

Why does the compliance policy have two Bitlocker Drive Encryption status evaluation settings?

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 a device under the 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 the device is based on the DeviceStatus CSP node.

This is a check to see if the device’s encryption is as per the targeted config policy. As such, it is mapped to the RequireDeviceEncryption node of Bitlocker CSP. Until Encrypt devices in Config policy show a 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), the status of the property setting changes to Compliant.

With Windows 10 version 1903, Microsoft introduced the node DeviceEncryptionStatus in Bitlocker CSP, which also aids in evaluating 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 the Encryption of data storage on the device shows Complaint Require, Bitlocker still shows as Not Compliant.

Why is there a discrepancy?

Require Bitlocker evaluation is different from encrypting data storage on the 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 the 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 the TCG log, which is generated at boot time. Any changes made to device configuration post-boot will not be present in the current TCG log.

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

The TCG log gets refreshed during a restart, which causes the generation of a 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 an 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 the next part, which will explain 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 detail, the policy settings that came from the management service with the default and current values for the particular feature.

Check the registry to see if the intended policy values have 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, 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 whether the policy settings configured in the portal were implemented at the device level or not. Once the policy is implemented at the registry level, the Bitlocker components present in the OS take over.

Check the encryption status on the device

The easiest 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 cypher 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 the device’s encryption status 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.

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

I have not seen any errors in implementation for a properly configured profile to enable silent encryption, neglecting device-related issues. Most of the time, the error is due to a profile misconfiguration.

With this, let’s check the breakpoints for Bitlocker Drive Encryption. The list 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 a non-compatible TPM chipset to Not configured

The user-aided mode continues and will prompt you to create either StartupKey or PIN, but Silent Encryption will fail due to the 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 cannot 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. Because the internet lacks good explanations, I explained them in detail below.

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

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

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

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

Note: This error also occurs if you have no profile to block automatic encryption during AADJ.

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

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

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

If you require a cypher strength/algorithm different from 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 cypher algorithm/strength, the policy will get delivered to the device, but it won’t get implemented and will report back as an error.

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

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

Has the device already gone through Automatic Encryption? How to revert and make your custom policy enforce silently?

First and foremost, we would need to decrypt the device manually. You can use the Bitlocker Management console from the 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 again.

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; if not addressed, they can cause Silent Encryption to fail. To resolve this, you 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 the re-generation of the 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 the XTS-AES 256-bit algorithm as in the policy.

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

To recreate this scenario, 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, so we can ignore automatic encryption as the error cause for the silent encryption profile (as was the case in the previous case).

Checking the Encryption status of the device reveals the device is in a 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 are implemented.

Where did it fail, 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?

This error may seem valid on a Hybrid AAD-joined system 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 initially.

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

Generally, the question comes: What is this GPO conflict error when the device does not actually have any GPO applied?

Cause

The error occurs due to any of the reasons below

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

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

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

If the recovery method is not set and is not configured to back up 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 a 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 the Control Panel

But all of these actually rely on the 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 depend, 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

These WMI class methods facilitate all the actions we perform over PS via the Bitlocker Wizard or through Silent enforcement.

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 scenes, this Get-BitLockerVolume cmdlet essentially makes a WMI query to the Win32_EncryptableVolume WMI class to use 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 it as you want

The methods of this WMI Provider class facilitate all the settings configured from Intune and compliance evaluation of encryption status (except the DHA scenario).

If the methods of Win32_EncryptableVolume WMI class facilitate Bitlocker operations, where is this method implemented (?)

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

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

• Using the 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 the user to Save to your Azure AD account

Behind the scenes, all utilize 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 required activities are also involved with this task, 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 (Bitlocker Drive Encryption)

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

Before I end, I would like to thank Oliver Kieselbach for his excellent SyncML Viewer tool for tracing OMA-DM sessions. This little powerful tool captures all the traces I have used. Check out his blog post on the same here.

As this completes the Bitlocker series I started last year, now is the time to take a break. I will return with some other topics on Intune, but as I say, keep reading and learning until then.

We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.

Author

Joymalya Basu Roy is an experienced IT service professional with almost 5 years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect with Atos India. He is an ex-MSFT, where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He is awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his own blog site MDM Tech Space at https://joymalya.com