This 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 Enterprise and Pro
- Azure Active Directory joined devices
- Microsoft Intune
- Enabled Enrollment Status Page (ESP)
- 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 and the Enrollment Status Page (ESP) must be enabled in the tenant. 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:
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:
See the Update section below for a new UI setting available in Intune 1901 release.
The two policies must be assigned to a AAD device group to test the new policies. Use a AAD device group and the ESP to make sure the policy is applied early enough. To force the user type to a standard user after enrollment we need an Autopilot profile and assign it to our device.
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:
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:
The result is displayed like this:
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:
Without an ISO it will successfully starts the encryption and key backup to Azure AD. A success event is shown below:
The BitLocker state can be verified with the PowerShell command on the client:
Get-BitLockerVolume | fl
In the Intune portal we can see the recovery key appended to the AAD device object:
see also my guide how to enable the startup PIN with BitLocker and Intune here:
How to enable Pre-Boot BitLocker startup PIN on Windows with Intune
Since Intune January 21th 2019 Release (aka 1901) we are able to configure the BitLocker Allow Standard User setting via UI element:
What’s new in Windows 10, version 1809 for IT Pros
Device Guard and Credential Guard hardware readiness tool
Hardware Security Testability Specification
Setting 256-bit encryption for BitLocker during Autopilot with the Windows 10 October 2018 Update
Setting the BitLocker encryption algorithm for Autopilot devices
Go ahead and start encrypting all your Windows 10 devices to strengthen your security level 👍
Great detailed blog once again sir Kieselbach. Questions i have. 1) did i read it correct we now also can use bitlocker csp for Windows 10 Pro ? 2) Silly question what about old devices without tpm ? PS is hsti like instantgo on surfaces ?
thank you sir :-).
– Yes starting in Windows 10, version 1809, it is also supported in Windows 10 Pro.
– BitLocker can be implemented without TPM for example with startup password but this is not supported with Intune. This must be scripted.
– Yes HSTI is a bit like InstantGo. An InstantGo device should work.
What i cannot find for bitlocker on Windows 10 pro is, can/do we also use the endpoint protection or use oma-uri? Thanks.
The endpoint protection profile does utilize the BitLocker CSP in the end. As long as you are using a Windows 10 version 1809 which has the latest BitLocker CSP you can use endpoint protection profile. But the endpoint protection profile also includes defender exploit guard which is a Windows 10 Enterprise feature (https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/windows-defender-exploit-guard) this can’t be managed on Pro then. So try it out and configure only the parts available for Pro editions. As fallback you can take the OMA-URIs of the BitLocker CSP directly and configure all the settings.
Wow thanks for the detailed and swift answer Oliver 🙂
Great blog post, thanks. Any idea when this new option might be available in the Portal alongside all the other Bitlocker settings?
Unfortunately I don’t know. I hope it will appear there anytime soon, but as long as it is not there we have to go for the OMA-URI.
Hi oliver , is the /Vendor/MSFT/BitLocker/AllowStandardUserEncryption still necessary when using ‘Warning for other disk encryption’ option with win10 1809 ? On this blogpost only enabling the ‘Warning’ option enforces bitlocker when using a non administrative account (https://www.vroege.biz/?p=3998)
yes it is needed, the blog from Vroege is based on information of 1803 Insider Preview. It is needed with the final builds. The new setting was introduced with 1809 and you can see the info on the BitLocker CSP site: https://docs.microsoft.com/en-us/windows/client-management/mdm/bitlocker-csp
In addition you can easily test it out, skip the setting and you will see encryption will not start, with the setting the encryption will start in a standard user scenario. It is expected that this setting will also soon appear in the Intune UI as well.
Thanks Oliver 🙂 Its sometimes a wild west in Intune 😀
Another great post. I do have a question, I can see the “Allow Standard User to enable encryption….: in the Intune UI but will that only work with 1809 devices? I’m spinning my wheels trying to get this to work with 1803 but the device never encrypts. I’ve tried both the CSP and the settings in the UI. Unless this just won’t work with 1803.
Yes it is only available with 1809, it is written here in this paragraph
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 official documentation is tricky but you can see it in the diagram in the beginning here:
AllowStandardUserEncryption was added with 1809… https://docs.microsoft.com/en-us/windows/client-management/mdm/bitlocker-csp
Really useful post!
I have one question about whether or not the Bitlocker policies can be targeted at users or if they need to be targeted to a device group.
According to this blog post from MS, it needs to be targeted to a device group:
Any experience you can share on this would be appreciated.
back from vacation. I’m glad that the post helps. If you want to prevent possible encryption not using your defined encryption strength then you should target to Autopilot devices with at least Windows 10 October 2018 Update. In addition you have to use the Enrollment Status Page (ESP) to accomplish your goal. These requirements guarantee that the encryption strength is used as specified. Since October Update the OOBE process will recognize the changed setting when deployed to your Autopilot “device group” and the usage of ESP. Before that October 2018 Update the Instant Go devices would start encryption during AADJ and therefor you wouldn’t have the chance to change it at all. Now with the Update the start of encryption is changed a bit and settings that are specified as described are recognized and used for the encryption process.
Hope you had a great vacation and thanks for the reply! 🙂
I’ve now tested targeting the Bitlocker policy against a DEVICE group with ESP enabled and that does indeed seem to do the trick. For the dynamic AAD device group I am using this query to include all AutoPilot devices: (device.devicePhysicalIDs -any _ -contains “[ZTDId]”)
As we onboard more use cases (and run into exceptions etc.) I may have to slightly adjust that query and get creative with Include/Exclude targeting, but for now this seems to be ok.
Again, thanks for confirming this.
Do this only apply to AADJ as I have since moved our organization to Hybrid Domain Joined and notice that bitlocker is behaving much differently with the same endpoint configuration policy set. For instance when a device is fully HDJ the bitlocker keys are not uploaded to AAD. Even when the setting is set to store them in AAD.
Yes my scenario is only for AADJ devices as the official MS documentation for this tells us. But I have reports from people using this with Hybrid Domain Joined devices. The workaround they found was to assign the device an owner. When a device owner (with AzureAD PS module) was assigned the recovery key was successfully saved to AAD. So you might give it a try, but I’m not sure if it is a MS supported scenario as the documentation does not mention this. You might want to clarify this with MS directly.
Hi Oliver, will this encrypt drive silently without end user action?
Yes it will. Shortly after enrolling you will see the lock symbol on the hard drive icon in explorer. User will not get any notification.
Thanks Oliver for confirming.
Hi Oliver, great post.
I cant get silent encryption to work in my environment.
The devices are windows 10 1809 running either Pro or Enterprise (i tried to upgrade the license but it didnt work anyway).
I keep getting events 846, 778 and 85.
Tested on a Lenovo Laptopt (no hsti) and on a hyper-v vm with tpm enabled.
Manually enabling or via the csp with the user being an admin both work. as soon as i try the silent encryption it keeps failing.
The keys are being saved to Azure AD (and every time the policy runs it creates a new key).
Any idea what that could be??
there was a known issue which is beeing worked on in regards to this problem. As long as the problem exists try to disable the setting which you propably have set: “Store recovery information in Azure Active Directory before enabling BitLocker”.
No luck, even disabling the policy to require backup prior encryption didn’t do it.
Is there any official MS page we can follow to get updates regarding this problem?
Okay, to my knowledge this problems effects only 1809 devices. For now you have to wait for the fix or open a support case for it to get offical answers. There is no official MS page explaining this problem right now.
I have an open case with MS about the “Store recovery information in Azure Active Directory before enabling BitLocker” in 1809. This is a weird one and the thing is that we only see the problem when using recent 1809 media. Using the 1809 media from back in September for example means we don’t see the problem.
I pinged some folks MS internally . As soon as I have some news to share I will let everyone know here.
any updates?? Thanks
latest update was fix is pending, I’ll asked for an update on this.
Great info Jan
I’ll try to downloas a win 10 1809 without updates and test. And if it works i’ll deploy another and wait before the updates are done to deploy bitlocker profile.
“Mysteriously” after installing April Cumulative update (KB4493509) fixed the problem even though is not mentioned anywhere.
Both the VM and Phisical started encryption after installation.
Did you hear any further info from MS on the issue around the setting “Store recovery information in Azure Active Directory before enabling BitLocker”? We had issues where bitlocker encryption policy started failing and after we have toggled this setting to Not configured, encryption started working again. We have opened a support case but we are currently working through analysis with support.
latest update was fix is still pending but I asked again.
The last we heard from MS was that this ‘will be fixed by the Windows Quality Update available by end of May’.
Is there a bug number that can be referenced or a short description of the underlying root cause. Id like to direct our support ticket to any existing evidence rather than having to “prove” in our environments that an issue exists?
Many thanks, Damien
You can try to reference the following case number and see if that’s related to your issue: 13245777
HI Jan, any idea if by the quality update mentioned would be the one made available this patch Tuesday (kb4494441)??
Because that didnt fix the encryption after applied.
the problem is still not fixed with the current monthly update, MS released also a KB article about it in the meantime. It seems to get fixed with the next upcoming Windows 10 1809 update.
Be careful with Version 3.6 of the dgreadiness_v3.6 Tool. My computer crashed after the neccessary restart and i had to restore it with a recovery point.
Did you used the parameters to check upfront before you enabled something… never seen something like this if you run the script just for verification…