BitLocker Silent Encryption not enabling for standard user

Brass Contributor

Hello Intune Community, I'm looking for some assistance with our Intune/Autopilot configuration please.

 

For the life of me, I can't get BitLocker Silent Encryption to enable for a standard user during a Autopilot White Glove enrolment.

 

Our environment:

 

-HP ZBook Firefly 14 G7 laptop (Fully updated, TPM 2.0, Secure Boot etc enabled) with latest driver pack

-BitLocker settings configured via Endpoint Security - Drive Encryption settings (I can post the full settings on request

-Endpoint OS is Windows 10 21H1 Enterprise X64

-Device Restriction added to Disable Automatic BitLocker During AAD Join (prevents Bitlocker enabling too early - during Device phase of enrolment and in AES 128 mode)

-Deployment profile set to Standard User

 

Upon completing enrolment, if I sign in with a Standard User, BitLocker FDE does not automatically begin. If I then 'Switch User' to an account with Local Administrator rights, it does....

 

Any help, tips on how to diagnose, investigate (logs, event logs etc) or resolve would be much appreciated.

 

Thanks

 

Jonathan

17 Replies

@jdseymour1978 

You could check the BitLocker-API Eventlogs for any clues:

Microsoft-Windows-BitLocker/BitLocker Management

To be sure

BitLocker policy configuration:

The following two settings for BitLocker base settings must be configured in the BitLocker policy:

Warning for other disk encryption = Block.
Allow standard users to enable encryption during Azure AD Join = Allow

The last one you mentioned as you were telling : Deployment profile set to Standard User
But to be sure the first one I mentioned is also configured? so we can rule this prereqs out?

@Rudy_Ooms_MVP @gerald_doeserich  thank you both for you replies.

 

My config is as follows:

 

Endpoint Security - Disk Encryption

EPS-Disk Encryption-Bitlocker Basic.png

Assignment: All Devices

 

Endpoint Security - Baselines - Windows Defender Baseline

 

EPS-Windows Defender Baseline-AllUsers.png

Assignment: All Devices

 

Devices - Configuration Profiles - Endpoint Protection

Devices - Configuration - Bitlocker Settings.pngDevices - Configuration - Bitlocker Settings - Summary.png

 

Assignment: All Devices

 

Devices - Configuration Profiles - Device Restrictions

Devices - Configuration - Device Restrictions - Password.png

 

Assignment: All Devices

I know it's a mess, but it's the best I've managed to get working after tens of rebuilds of my test laptops...

Is no-one able to offer any assistance? I have now pared back the configuration to just the Endpoint Security - Disk Encryption settings, but still it does not enable for a standard user, only when you subsequently log in as an admin.

 

Did you test it out on multiple different hardware devices?

https://rahuljindalmyit.blogspot.com/2020/11/intune-bitlocker-silent-and-automatic.html

 

And just wondering but what happens when changing the encryption back to the default:

XTS-AES 128 . It could be worth a try?

Something else I thought of, are these hybrid joined or azure ad joined?
Hi Jonathan,

I also have a multi-user scenario, with users without local admin permissions. I have just compared the Bitlocker settings with mine, and these are identical.

As you’ve already brought the settings down to only Disk Encryption, what you can try is reset or re-image the device and test it again. It wouldn’t surprise me if there are conflicts because of the many configurations you had. Please let me know. I am more than happy to assist you.

Hello everyone, thank you all for your replies.

 

This is occurring consistently on a HP ZBook Firefly G7 and a Dell Latitude 7390 using bare-metal rebuilds from USB boot media configured with the latest driver pack for each device. Before each rebuild all traces of the laptops are purged from MEM, from Devices, Device Enrolment, and Azure AD -> Devices.

 

Some key facts from my testing:

 

- This is a Azure AD environment, not Hybrid

- Sometimes - not consistently - BitLocker will enable during OOBE during the Get-AutoPilotInfo -Assign stage - i.e. before the White Glove profile is assigned to the device. This is in AES-128 Used-Space only mode. Reading some information on the Microsoft site, this can occur during OOBE when a user signs in with a Microsoft or Azure account. The only way to stop this is to add the following lines to the autounattend.xml file on the USB stick:

 

<settings pass="oobeSystem">
<component name="Microsoft-Windows-SecureStartup-FilterDriver" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<PreventDeviceEncryption>true</PreventDeviceEncryption>
</component>
</settings>

 

- This seems to ignore the Device Restriction policy setting Do Not Enable BitLocker during AADJ Join, which I have assigned to All Devices

- I am using Windows 10 Enterprise 21H1 X64

- The only BitLocker settings now are under Endpoint Protection - Disk Encryption now, aside from the Device Restriction setting above

Consistently the autopilot procedure will complete, signing in as a Standard User without enabling BitLocker. As soon as I 'Switch User' to an account with Admin rights, automatic encryption begins, in the correct AES-XTS 256 Full Disk mode. 

 

I hope that this information is helpful, and I am grateful for any assistance or guidance you can provide.

Hi,

I sended you a pm. to make sure i am not polluting this thread :p
Hello All,

Apologies for disappearing, only to return. I have finally gotten around to doing some more testing. By enabling some additional logging (via the excellent AutopilotOOBE project), I have seen multiple entries similar to the following in the logs:

08/24/2021 15:43:07 ERROR:404 MDM ConfigurationManager: Command failure status. Configuration Source ID: (B4265C48-4F41-414D-AF5F-686CBF866DC0), Enrollment Name: (MDMDeviceWithAAD), Provider Name: (BitLocker), Command Type: (Add: from Replace or Add), CSP URI: (./Vendor/MSFT/BitLocker/ConfigureRecoveryPasswordRotation), Result: (The request is not supported.).

Any ideas?
This specific error is related to key the key rotation setting. I would disable that in your encryption policy and try again.
Thanks for your reply and suggestion Nathan. I've now tried with:

Configure client-driven recovery password rotation: Not configured
Compatible TPM startup: Allowed
Compatible TPM startup PIN: Allowed
Compatible TPM startup key: Blocked
Compatible TPM startup key and PIN: Blocked

Recovery key file creation: Allowed
Require device to back up recovery information to Azure AD: Yes
Recovery password creation: Allowed
Enable BitLocker after recovery information to store: Yes
Block the use of certificate-based data recovery agent (DRA): Not configured

With still the same symptoms - no automatic BitLocker enablement when using Whiteglove and signing in as a Standard User UNTIL I then switch user to an Admin
Hi did you take a look at the pm I sended some time ago ? To try it with a powershell script/win32 app instead of a device configuration policy? I know it's better to use a device configuration profile... but maybe it can help you to rule some stuff out
I'm wondering if you fixed this issue or not. I can read you've already had lot's of great feedback and suggestions so hope my take on this adds value. You've already mentioned that some devices configure encryption during OOBE. I'm trying to find out if you can pinpoint a device that did not use default encryption during OOBE.

- Try to boot the (Autopilot) device from a fresh install (OOBE)
- Hit Shift+F10 during OOBE to start a command prompt
- type manage-bde -status
look at the output. The "Conversion status" should be "Fully decrypted" and "Protection status" should be "Protection Off"

If this is the case. I would expect your policy to work (but it seems not to). But if this is not the case, (bitlocker default encryption enabled) then I'm starting to think your policy conflicts with the default encryption setting which is XTS- AES 128-bit. I read that you've set this to 256. Try to use the default value of XTS- AES 128-bit and see it that works.

@Oktay Sari 

 

Hello, yes, I have had some very helpful replies to assist with my troubleshooting of this issue, but sadly none have provided a solution.

 

As per one of my previous posts, here is the current situation:

 

- Sometimes - not consistently - BitLocker will enable during OOBE during the Get-AutoPilotInfo -Assign stage - i.e. before the White Glove profile is assigned to the device. This is in AES-128 Used-Space only mode. Reading some information on the Microsoft site, this can occur during OOBE when a user signs in with a Microsoft or Azure account. The only way to stop this is to add the following lines to the autounattend.xml file on the USB stick:

 

<settings pass="oobeSystem">
<component name="Microsoft-Windows-SecureStartup-FilterDriver" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<PreventDeviceEncryption>true</PreventDeviceEncryption>
</component>
</settings>

 

This is apparently the 'automatic device encryption' setting (https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-bitlocker) that occurs when someone signs in with a AAD or Microsoft Account. The problem is, as I describe above, it is doing so too early - before the enrolment part of the Intune Whiteglove procedure has been completed - i.e. before the profile is applied to the device (5x Win key etc)

 

Consistently the autopilot procedure will complete, signing in as a Standard User without enabling BitLocker. As soon as I Switch User to an account with Admin rights, automatic encryption begins, in the correct AES-XTS 256 Full Disk mode. 

- I see multiple entries in logs for the following:

08/24/2021 15:43:07 ERROR:404 MDM ConfigurationManager: Command failure status. Configuration Source ID: (B4265C48-4F41-414D-AF5F-686CBF866DC0), Enrollment Name: (MDMDeviceWithAAD), Provider Name: (BitLocker), Command Type: (Add: from Replace or Add), CSP URI: (./Vendor/MSFT/BitLocker/ConfigureRecoveryPasswordRotation), Result: (The request is not supported.).

I have tried various settings around the Key Rotation Settings as suggested but this has not changed the situation