This blog will be the second one in the Windows Enrollment Attestation Series!! And let me promise you one thing!!! The words rabbit hole will get a new meaning!! I will show you how a “simple” CSP, which is part of the Windows Enrollment Attestation feature, gives us the power to bring our Intune Certificate back to life when it’s broken.
1. Introduction
Having issues with your Intune Device Certificate can be really frustrating, especially when the attached private key is missing. I’ve written several blogs on how to handle and manually fix these problems in the past.
In the blog above, I shared a PowerShell script to detect and fix an Intune certificate that is missing its private key. While testing it, I found something interesting. After removing the private key by exporting, deleting, and importing the certificate back without it, I hit the sync button in the work or school account settings.
Within a minute of pressing the sync button, the Intune Certificate came back to life, but somehow, it got a different renewal date. The renewal date changed from 11/10 to 11/11. I was like….
What happened? Let’s find out!
2. What happened?
To determine what happened with the Intune Certificate, I opened the event log and started checking the device management event log. During the syncing time frame, I noticed many messages telling me it was trying to start the MDM enrollment process. From there on, this message popped up.
Uhhh okay? I didn’t do anything weird; I just pressed sync, and the Intune Certificate was somehow renewed (even when it was not up for renewal!). When our Certificate gets renewed, we will notice that the Intune Audit logs also mention the activity type: “Create ClientCertificate”
How did it get renewed, as it wasn’t there? Holy cow. What did I step into? Did I do a rudy thing again? I decided to start looking at the other event logs that also occurred, but besides the other MDM enroll messages, I did not notice anything new. I guess it was time to get my WPR trace in place.
After starting the trace, I again trashed the certificate and pressed sync, hoping the Certificate would come back to life again! After the certificate was indeed back again, I opened the trace in the WPR tool. After reviewing all the tracing providers, I started by looking at the OMADMClient.
As shown above, BINGO!!! It mentioned: ClientCertificateMissing. Yep… the certificate was missing indeed, no question about that. If you scroll down a bit, you will notice that the OmaDmRecoveryFlow was triggered and started recovering the Intune Device Certificate.
With some magic, it indeed recovered the Intune Device Certificate. I wondered if the device contacted the service to request a new one.
3. The Fiddler Trace
Again, I trashed the Intune device certificate, started the WPR trace, and put Fiddler in place.
As shown above, when the device started syncing, it contacted enrollment.manage.microsoft.com to start the MDM discovery process.
From then on, it again reached out to fetch the corresponding certificate blueprint and, of course, the corresponding payload containing the Intune Certificate.
After spending time looking at different kinds of enrollments, I knew where to start. Please look at the picture below and tell me what you noticed!
RequestType: 200512/Recovery
TokenType: DeviceEnrollmentToken
The Requesttype corresponds to this part of the MDE-2 documentation
“For the certificate recovery process”, MDE2 modifies the RequestSecurityToken message as follows:
It indeed did! From there on, I started looking at the DMClient CSP documentation and searching for recovery. This is what it got me!
This node determines whether or not the client will automatically initiate an MDM Recovery operation when it detects issues with the MDM Certificate. I guess we have a new CSP in town! The Recovery CSP
4. AllowRecovery
” initiate an MDM Recovery operation when it detects issues with the MDM Certificate.” This looks exactly like what was happening, but again, I didn’t do anything! I need to check the registry node it was using. I did so by trashing the Intune MDM device Certificate and watching procmon.
Within a minute, the omadmclient.exe started searching for the IsRecoveryAllowed registry key in the enrollments registry node.
In this enrollment key, I noticed that my test device (also after reinstalling and removing all the configured policies in Intune) was getting the IsRecoveryAllowed set to 1.
This is odd because the default value is zero! I checked multiple devices from multiple tenants and couldn’t find that crucial being set. If we take another look at the documentation, we will notice that it’s not enabled by default.
I decided to check the NodeCache on my device to be sure that Intune created this key and not something else I did in the past. As shown below, yep… expectedvalue is set to 1.
Okay, so we can be pretty sure Intune created that key—no “rudy thing.” Now, I am starting to doubt if his key was indeed the AllowRecovery Registry key that triggered the Certificate recovery. It’s time to find out! Testing/Production—it is all the same, right?
So, I decided to manually deploy this CSP in a production tenant and assign it to my device.
./Device/Vendor/MSFT/DMClient/Provider/MS%20DM%20SERVER/Recovery/AllowRecovery
After the setting was deployed to my device, I exactly performed the same steps by removing the Intune MDM certificate and syncing the device to perform a syncml session. Within a minute, the Intune certificate came back to life! It’s like the chron o john that went back in time to restore the certificate!
Damn…. I am amazed… Let’s dive a bit deeper, shall we?
5. The Certificate Recovery
If we look closely at what happens, we will notice that the OMADMCLIENT will try to find the referenced cert and determine if the device has a valid Intune Certificate.
If that one fails, it will error out with the same error as we have spotted above and will throw the ClientCertificateMissing error.
Suppose the Client Certificate is indeed missing in action. In that case, the OMADMClient will try to determine if Recovery is Allowed by calling upon this external getisrecoveryallowed function (dmenrollengine.dll) through the WinMain function of the deviceenroller.exe.
That function will check if the IsRecoveryAllowed registry key has been configured
If you don’t believe me:
If that registry value has been configured, we can perform some certificate recovery. From there on, it will try to detect if the device has a valid device token
After it figured out the device status and the device token, it will set the recovery time stamp (SetRecoveryStateAndErrorCode)
With the recovery time stamp set, it will trigger the OmaDmRecoveryFlow
This omadmrecovery flow will start the enrollment (OR_MDMRECOVERY). This enrollment is the same as with a new MDM enrollment
At the exact moment, the recovery begins, it will also update the RecoveryStatus to 1
If we take a closer look at the recoverystatus CSP could give you these messages:
Recovery has failed to start because Microsoft Entra ID Keys aren’t protected by the TPM
Recovery has failed to start because the MDM keys are already protected by the TPM
When reading the above sentences for maybe the 10th time, it becomes obvious that the device also needs the Entra ID / Device ID token to fix the MDM keys. This Entra ID Key needs to be protected by the TPM.
6. Certificate Recovery
After spending some more time reading the MDE2 Documentation, I noticed the Certificate Recovery flow from Microsoft.
I adjusted it a bit and added my information to it. Hopefully, you like it 🙂
Conclusion
I am amazed how the AllowRecovery CSP could bring the Intune certificate back to life! Why isn’t this enabled by default? It needs to be enabled to prevent issues with the Intune MDM Certificate.
If you want to read part 3 of this MDM hardening series, you can find it here.
https://call4cloud.nl/2024/07/the-killing-of-a-not-hardened-mdm-enrollment