The 0x80072F9A We Start From

This blog is a follow-up to the Windows Enrollment Attestation series. I’ll dive into why the AllowRecovery CSP is a game-changer and how it helped me tackle the infamous 0x80072F9A error. Yep, another one that is tied to an Intune MDM certificate issue.

1. Introduction

Some time ago, a K12 school approached me and asked me if I could help them out with a nasty sync issue. The Sync Could not be initiated (0x80072f9a)

This issue 0x80072f9a was causing many devices to suddenly stop syncing with Intune, which is terrible, to say the least. I started talking with him and asking for more details about the certificate issue. In the past, I stumbled upon many different kinds of certificate issues.

Until now, each issue has been pretty straightforward and can be solved quickly. Sometimes, it was just the Intune certificate that was expired, it was about the Private key missing, and sometimes, there was a different certificate with the same GUID(issued to). Those issues could be solved pretty fast just by running this PowerShell script

Intune Sync Debug PowerShell Tool to fix Intune Sync Issues (call4cloud.nl)

Or just manually by firing off some PowerShell script.

SslClientCertReference | Private Key Missing | Intune (call4cloud.nl)

Each error code has its own solution, but somehow, the k12 school was getting an error that looked familiar at first, but later on, things changed a bit.

2. The 0x80072F9A

As always, I started with the basics.

• Is the Intune Certificate valid?
• Does it have its private key attached?
• Isn’t there a duplicate certificate with the same guid?
• Is the entdmid configured?
• Is the sslclientcertreference configured?
• Does the device contain a valid device token (dsregcmd /status)

The response to every question I asked was yes. So from there on I asked him if he could deliver a trace from the moment he tried to sync the device.

As shown above, after the OmaDmSession was initiated it showed us the error 0x80072f9a. From there on I started taking a closer look at the OmaDmClient Trace itself.

By the looks of it, every step in the process to initiate the Omadm session seems to go perfectly until the last step, when the data needs to be sent to the server (sendatatoserver). With this trace, it was obvious that the previous steps in the process were all successful, and the only error we got was the same as we noticed before: 0x80072f9a

At first, the error 0x80072f9a looked familiar. I thought I was looking at the same error in which the private key was missing in action.

Intune Sync Error 0x80072f99 | Private Key Missing (call4cloud.nl)

As shown above, we will get the error 0x80072f99 when the private key is missing. It almost looks the same, but this time, the error code ended with an A instead.

When we convert those error codes to something more understandable, this is what we get

The 0x80072f9a error was pointing us to the fact that the device had no access to the private key. (ERROR_WINHTTP_CLIENT_CERT_NO_ACCESS_PRIVATE_KEY)

I guess it was time to ask for some more information about the Certificate, but before I do, I need to give you a small summary of what has changed in the past couple of years.

Before Microsoft started the MDM hardening process, the Certificate’s private key was stored in the Microsoft Software Storage provider. This isn’t that secure, but we could fix the missing private key with a simple PowerShell command.

When Microsoft started the MDM hardening process, the Certificate was protected from the TPM using the Microsoft Platform Crypto Provider. To ensure this protection, Microsoft implemented the UseTpmForEnrollmentkey Function.

So, I asked the k12 school if they could show me the output of certutil -store my and especially the Intune MDM CA. As shown below the output of the certutil -store my

The Certificate was getting protection from the TPM (Microsoft Platform Crypto Provider), and with it, the private key should be safe. But what’s that? “Missing Stored Keyset“? That’s not good? How are we going to fix the Missing Stored Keyset and that stupid 0x80072f9a error when we try to sync our device.

3.The First Fix

If everything is lost, we could try to ditch the Intune Certificate and reenroll the device using the magical device enroller. To do so, we only need to delete the Intune Certificate and start the Intunesyncdebugtool

Intune Sync Debug PowerShell Tool to fix Intune Sync Issues (call4cloud.nl)

Once the certificate is removed and the intunesyncdebugtool has done its job, the device will be reenrolled into Intune. So, I asked if he could try to do the same on 1 device.

After 15 minutes, I got a reply back that, indeed, the device was successfully reenrolled and could initiate an Intune sync without any issue. The sync error 0x80072f9a was gone! But to reenroll all the problem devices just sounds too awful! There must be a better solution, right?

Let’s find out how AllowRecovery handles itself in a nice production environment. Is it capable of fixing this issue?

4. The Way Better Solution

If you have read my previous blog about the AllowRecovery, you should probably know the power of this CSP. With a simple CSP, we can ensure this policy is delivered to the device.

please note: The moment Windows Enrollment Attestation went to GA, IsRecoveryAllowed=1 was sent out to all devices

./Device/Vendor/MSFT/DMClient/Provider/MS%20DM%20SERVER/Recovery/AllowRecovery

But if the device stops syncing, we no longer have this option available, so I asked him if it was possible to manually create that key on a single device that also had the error to determine the impact. So, he did, as shown below, he created the IsRecoveryAllowed DWORD on his own.

Once the IsRecoveryAllowed dword was created, he deleted the Intune MDM certificate and initialized the Intune sync. After waiting a few minutes, the AllowRecovery CSP did his job!

We could fix the issue with this simple registry fix that we configured manually, but how will we fix this on all other devices? If you have an additional RMM tool, it’s straightforward to use! Just create a new Powershell script and deploy it to your devices!

Write-Host "Searching for enrollment ID"
$Tasks = Get-ScheduledTask | Where-Object { $psitem.TaskPath -like "\Microsoft\Windows\EnterpriseMgmt\*" }
$EnrollId = $Tasks[0].TaskPath.Split('\\')[-2]
if ($EnrollID -match '\w{8}-\w{4}-\w{4}-\w{4}-\w{12}') {
	Write-Host "Found EnrollID - $EnrollID" -ForegroundColor Green
} else {
	Write-Host "Error parsing EnrollID. Stopping" -ForegroundColor Red
	Break
}


$EnrollmentReg = Test-Path -Path HKLM:\SOFTWARE\Microsoft\Enrollments\$EnrollID
if ($EnrollmentReg) {
	New-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Enrollments\$EnrollID -Name 'IsRecoveryAllowed' -Value 1 -PropertyType DWord  
}

This PowerShell script will find the proper enrollment registry node (if you don’t have a device that is enrolled with MMP-C, aka EPM installed, AKA enrolled into the Declared Configuration Service). If you don’t have an additional RMM tool but you have the pleasure of having a nice license with MDE in it (e5), you could use Defender Live Response to deploy this script to your devices! The same way I did with the old fix, we can do the same thing with the new fix!

Fix Missing Intune Certificate with Defender for Endpoint (call4cloud.nl)

Isn’t that just nice? Now comes the good thing… I wrote this blog before the whole Windows Enrollment Attestation feature was rolled out to all tenants worldwide. This AllowRecovery setting is now enabled by default for all tenants to make sure the Intune MDM certificate its private keys can be uplifted to the TPM!

Conclusion

Hopefully, this separate blog post has shown you how the AllowRecovery CSP could fix sync issues like the error 0x80072f9a in which the device can’t access the private key. Besides fixing certificate issues, this CSP has an even more important job! Curious? Keep an eye out for the next MDM hardening blog posts