This time, a simple blog about a BitLocker escrow error (0x80072f8f )that started happening (all of a sudden) on multiple devices when you were trying to silently enable BitLocker. This blog is not 100% done but as a lot of people were experiencing this issue, I decided to post it before it was totally finished
1. The Issue
When you have configured some BitLocker policies in your tenant to silently enable Bitlocker and start to enroll some devices, you could run into an “escrow/backup” issue.
Somehow the device failed to back up the BitLocker Drive Encryption recovery information to your Azure AD. The event 846 will fail with the error code: 0x80072f8f AKA a security error occurred or 0x80072efe AKA WININET_E_CONNECTION_ABORTED
So no access was denied (0x80070005) or 0x801c0450 as I was mentioning in this blog below, but something to do with “security”
Configure BitLocker | Intune | Escrow error 0x801c0450 (call4cloud.nl)
When taking a closer look at that error and just looking it up on my own website, drew my attention to a certificate issue as it looks like an SSL/TLS issue for now.
2. The Solution
So, when taking a look at the issue and how to fix it, we have some possible solutions
- Upgrading the firmware of the TPM
- Disable the RSS PSS Signature Algorithm in the registry
Of course, it’s obvious that upgrading the TPM firmware is the best option you have to make sure BitLocker encryption is successful.
There’s no question about that, but what if somehow it was working on the device and now isn’t after a wipe and re-enrollment with Autopilot? So, if upgrading the TPM’s firmware isn’t an option, or maybe because Microsoft changed “something,” you could choose to delete the cipher suite if you need to fix it ASAP.
When you delete those three values from the cryptography\configuration\local\SSL\00010003 registry key the client will use a different cipher for signing after you rebooted the device. After removing the RSAE-PSS keys and restarting the device, it will start the encryption and send out the recovery key to Azure AD.
Luckily Richard Hicks dealt with a similar kind of issue in the past and created a PowerShell remediation for it!
https://github.com/richardhicks/endpointmanager/blob/main/Detect-RsaePssCiphers.ps1
Please note: removing the cipher suite that’s part of TLS1.3 isn’t the smartest decision. Please read further!
3. Microsoft
It seems Microsoft Support has finally awakened and has identified that there is an issue in which some Windows Clients with TPM 2.0 cannot handle some algorithms (RSA PSS) during client TLS communicating with enterpriseregistration.windows.net
So that explains the error I noticed and the first idea I had about what it could cause. It looks like Microsoft still needs a couple of days to fix it as the ETA for this fix is now set to 04-08-2023
Conclusion
0x80072f8f AKA Security Error could break your BitLocker enrollment because the TPM doesn’t and the service doesn’t go along with the RSA PSS cipher or maybe because of some weird issue on the service side
thank you very much for this article!
I just deployed the remedition scripts for a device to test.
For over two weeks this problem has been bothering me.
Strangely enough, in my IT environment it only occurs with HP Elitebook 850 G5.
I already suspected the TPM or the firmware. Finally, I thought that there might be a Microsoft problem.
My test device, which was already integrated in hundreds of customer tenant, has the problem since Friday.
A week before, it still worked without problems.
I am currently in a migration. Out of 20 HP devices (all HP 850 G5) it worked on 15 devices without problems.
On the other five, Bitlocker could not be activated silently.
As I said, my device has always encrypted without silent until Friday.
I hope the problem will be fixed soon. This is only an urgent solution.
Hello,
Thanks for the blog. It helped. Can you post the link to the Microsoft Bug report?
Hi Guys,
Do you know if Microsoft alredy solved this issue?
Regards,
It’s June 2024, and I am seeing this on a lot of my machines. We are migrating too Intune, and whilst the machines are bitlockers, they are not saving back into Azure / Entra. When I try and manually “back up your recovery key” I get an error in the event log, “Failed to backup bitlocker drive encryption recovery information for Volume C: to your azure AD” then there is a traceid, and then “Error: JSON value not found”
I was interested to see that you you suggested there was a date for a fix. Could you share that link so we can see where it is up to.