Setting 256-bit encryption for BitLocker during Autopilot with the Windows 10 October 2018 Update
Published Jan 22 2019 09:20 AM 24.8K Views

By Matt Shadbolt | Intune Sr. Program Manager

 

Microsoft Intune provides a comprehensive set of configuration options to manage BitLocker on Windows 10 devices, October 2018 update.

 

One such setting allows the IT Administrator to set the BitLocker encryption algorithm. The BitLocker encryption algorithm is used when BitLocker is first enabled and sets the strength to which full volume encryption should occur. An IT Administrator can set this algorithm to AES-CBC 128-bit, AES-CBC 256-bit, XTS-AES 128-bit or XTS-AES 256-bit encryption.

 

By default, Windows 10 will encrypt a drive with XTS-AES 128-bit encryption. Encryption can be enabled on unencrypted Windows 10 PCs using MDM policy, such as when the device becomes Azure AD Joined (AADJ).

 

When a Windows 10 device runs through the Out Of Box Experience (OOBE), and an AADJ occurs during OOBE, BitLocker may be automatically enabled on modern hardware with the default XTS-128-bit encryption algorithm before the Intune MDM policy is processed and the IT administrator’s configuration is applied.

 

This causes a situation whereby the BitLocker disk encryption does not meet the IT administrator’s defined requirements in Intune.

 

bitlocker_blogpost.png

 

Microsoft Intune recently made some UI changes to call out that these settings only apply at first encryption. To help improve this experience, we made some changes to the Windows Autopilot build process that enables Windows to consume the IT administrator’s MDM settings before automatic encryption is started.

 

From Windows 10 October 2018 Update, the BitLocker encryption algorithm can be changed during an Autopilot build. To achieve this, you need to configure the following:

  1. Configure the encryption method settings in the Windows 10 Endpoint Protection profile to the desired encryption algorithm.
  2. Target the encryption method policy to your Autopilot group of devices. This is required as the policy needs to be processed as a device targeted policy, not a user targeted policy.
  3. Enable the Autopilot Enrollment Status Page (ESP) for your users/devices. This is required because if the ESP is not enabled, the policy will not apply before encryption starts.

By meeting these three configuration requirements, your Autopilot configured devices will now honor the BitLocker encryption algorithm setting and will encrypt with your specified encryption algorithm.

 

Let us know if you have any questions on this expanded feature set. 

19 Comments
Brass Contributor

Question for me.   Windows 10 October 2018 Update ties back to 1809 build.   We have several devices on 1809 that are Hybrid DJ in AutoPilot yet the Bitlocker is now kicking off automatically.   Is there a dependency that is also tied to Win10 being on Enterprise vs Pro?   Reason why it would not be running automatically.

Certain this is in doc's, but quoting directly from one of our Intune experts, Courtenay Bernier- "Beginning with Windows 10 Creators Update (1703) BitLocker can also be managed and enabled with Microsoft Intune by using Configuration Service Provider (CSP) settings.  Note: Windows Business/Enterprise/Education is required.https://blogs.technet.microsoft.com/cbernier/2017/07/11/windows-10-intune-windows-bitlocker-manageme... 

Iron Contributor

Hi Intune Support Team, I am looking for some confirmation that in order to enforce 256bit encryption, the Bitlocker policy needs to be assigned to a DEVICE group and not a USER group to make sure it gets pulled down early enough during the ESP. This blog post is the only place where I have been able to find any reference for this requirement. If this is indeed required, my plan is to target the policy to the same AAD device groups that I use to assign the AutoPilot profiles. You mention to target the 'Autopilot group of devices', which I read to be the same approach. Any confirmation or link to additional information on this topic would be greatly appreciated. Thanks, Jan

 

Update: I feel that Oliver K. Has been able to answer my question about DEVICE vs. USER targeting in the comments section of his blog post  @ 

https://oliverkieselbach.com/2018/10/23/enabling-bitlocker-on-non-hsti-devices-with-intune

Iron Contributor

The blog post states that 'To help improve this experience, we made some changes to the Windows Autopilot build process that enables Windows to consume the IT administrator’s MDM settings before automatic encryption is started.'

 

It is my understanding (and that of the Microsoft engineer working on a case on this exact question) that most modern hardware (InstantGo) will start automatic encryption with 128bit when the PC first boots up, right at the start of OOBE. This is before any of the MDM settings can be applied.

 

Can you please explain how we can enforce 256bit encryption using MDM settings and the ESP as described in this blog post for those 'modern' devices?

Microsoft

Hi Jan. You're right, InstantGo devices will automatically enable device encryption on Azure AD Join. Per this blog post, if you're using Autopilot and target the configuration correctly (to a device group, ESP, etc), the policy is received by the client early enough before auto encryption starts. This means the 256-bit encryption requirement will be honored when auto encryption begins. 

Hope that helps clear it up. 

Matt 

Iron Contributor

Hi Matt,

Maybe I am confusing InstantGo with something else here, but what I was trying to say is that we have devices that auto-encrypt at first boot! This is at the very beginning of the OOBE when the user selects the region, so before Internet/AutoPilot/Intune has even been contacted. If that happens, 128bit encryption is used and MDM/ESP even when targeted to a device group will not be able to change it because encryption has already started. Not sure why some devices auto-encrypt that early in the process, and unfortunately there is no mention of this in any of the MS blogs/docs.

We have an open case with MS on this, so please feel free to look at that if you have access: 119030526001011

Regards,

Jan

Copper Contributor

Hi @Jan Gutjahr , was this ever resolved for you? We have been struggling with the same issue for months now and have multiple MS support tickets open. Our entire Auto Pilot program has come to a screeching halt because of this. @Matt Shadbolt if you have any other info on checking settings or things to look out for, we would appreciate it. Thanks

Iron Contributor
Hi @Asif Mahmud, we have been told by MS that 'the fix will be part of May End Windows Update'. As a temporary workaround, they have suggested to disconnect the power adapter on first boot as that may prevent Bitlocker from auto-encrypting.
Microsoft

Even after enabling all these settings, if you still find that the device is getting encrypted with 128 bit. Make sure, you create a Device Restriction policy and configure this setting.

 

Intune> Device Configuration > Create a new policy > Windows 10 and later > Device restrictions > Password > Automatic encryption during AADJ > Block

Copper Contributor

@Intune_Support_Team  Followed the article steps and partially works. The machine goes through the autopilot process and encrypts with AES-256, but the device has an additional device configuration profile attached with User Principal Name "System Account" in error state.  This makes the machine not compliance.

 

@HimanshuIntune Followed your instruction on creating another device restriction policy to block AADJ automatic encryption.  This partially works.  It blocks the device from encrypting during AADJ, but the machine didn't auto encrypt during the user setup phase.  Once into the machine I cannot turn on encryption on the new Windows 10 setting page.  I had to use the Manage BitLocker page to encrypt the device.  

 

Tested with windows 1809 and 1903.

Hi @kensoom, If you continue facing an issue with the Device Configuration profile not deploying as expected, please open a support case via the Intune Admin console's Help and Support. Our support team would be happy to further assist with resolving your issue. Feel free to direct message us with your support case number for follow up!

Copper Contributor

Using 1903 with latest updates seems to have finally resolved this issue for us. 

Iron Contributor

Dear All, Few questions on 128 vs 265,

 

1. I read in some forums that "Microsoft reduced their guidance in the Windows 10 baseline from 256 to 128, due to performance on some systems, and the requirement to decrypt if moving to 256." - Is this the case? I can not find any official coms.

2. Is there a way to gather BitLocker settings 128 vs 256 using Endpoint Manager or Security Center? Recommend monitoring option at https://docs.microsoft.com/en-us/mem/intune/protect/encryption-monitor "Select Devices > Monitor, and then under Configuration, select Encryption report." does not provide details. Is there an upcoming improvement for this?

3. Can you please provide a link to Microsoft recommended/endorsed process for converting devices from 128 to 256 in Azure AD joined estate.

 

@Intune_Support_Team- are you able to comment?

 

Regards,

Serg

 

Iron Contributor

Every laptop we have in office be it a Surface Books, Dell 5580, 5590, 5501 all show this error in DMAC. Not one device that has received this configuration profile has the Encrypt Device line item as Succeeded, always an Error.

Capture.PNG

Copper Contributor

@DBR14 Hello, we need to first check if the issue is related to enforcement or something else. Could you please follow this article and check steps listed ?

https://techcommunity.microsoft.com/t5/intune-customer-success/support-tip-troubleshooting-bitlocker...

 

Once you verify that the correct registries and values in MDM Diagnostics are in place then we can check event viewer logs.

Specifically, please check BitLocker API Event viewer logs to find if the initiated the enforcement or not. 

Copper Contributor

Hi @Intune_Support_Team ,

 

Sorry to resurrect an old thread, but did this ever get resolved? My organisation has a practically identical situation as Jan, in which the encryption is happening as soon as Windows is installed, even by the time you reach the language selection of the OOBE.

 

Given this is far before the machine would be enrolled or talk with any configuration platform, it feels very much like an OS issue...

 

Regards,

Ashley

Copper Contributor

I have the same problem.

The device is encrypted with 128, but in my Endpoint Policy I set 256.

Running autopilot and the other requirements that is described here.

My only solution is to decrypt the device, then run a sync on the device.

Then it recieve the endpoint policy with my 256 bits encryption.

 

Deploying HP Elitebook with Windows 10 22H2.

Copper Contributor

I thought it may be helpful to confirm I have gotten to the right escalation points within Microsoft, who have confirmed this is an issue that a number of customers has reported and is being treated as a problem.

 

It took quite a bit of back and forth to explain that this is not a configuration issue. I will update again if I get any more information for those interested.

 

In the meantime it looks like I may have to use a remediation script to detect improperly encrypted devices, and to initiate a decryption. Then after an Intune sync the devices should pull down the correct policy.

Copper Contributor

Same issue as Patrik and Ashley above.

InTune policy is set to 256 (and also reviewed by MS and is accurate)

New machine into InTune, w/o BitLocker at all, will get the policy once enrolled in InTune, but encrypt to 128, not 256

Only fix is to decrypt and then let the policy re-apply.

Have not tried a remediation script yet but that's the best route....for now.  Appears you can run this if 128 is detected, decrypt and then let the policy re-apply.

Version history
Last update:
‎Dec 19 2023 01:20 PM
Updated by: