This is the fourth and, for now, last blog post in the Windows Enrollment Attestation series. In it, I will explain how the three previous blogs led me to the beautiful new MDM hardening feature in Intune.
This new feature is the final step in the MDM hardening process. If we want to MDM enroll our device, all your devices must have successfully performed TPM attestation. If the device cannot perform attestation, it will be blocked!
1. Introduction
Let’s start with a small summary of the three previous blogs.
Intune Certificate Recovery | AllowRecovery | DmClient CSP (call4cloud.nl)
The first blog was about how I stumbled upon something called “AllowRecovery” and how this new DMClient functionality could bring your Intune MDM Certificate back to life when there are issues (Private key missing or just totally missing in action). Which is pretty cool!!!
From there on, I started diving deeper and deeper into MDM hardening. In the second blog post in the MDM hardening series, I noticed that Microsoft Implemented something called UseTPMForEnrollmentkey. This function in the mdmregistration.dll will ensure that all new Intune enrollments with an up-to-date Windows build will have their Intune MDM certificate private key protected by the TPM. Back in the day, the private key was NOT protected by the TPM (Microsoft Crypto provider) but it was stored using the Microsoft Software Key Storage provider.
MDM Hardening | UseTPMForEnrollmentkey | Intune Certificate (call4cloud.nl)
Now, you could ask yourself, what about existing enrollments? In the same Recovery CSP, we also have the power to initiate the recovery on our turf. When we enrolled our Windows 10 device back in the day, the Intune MDM certificate and its private key was NOT stored in the TPM. Guess what happens if we initiate a recovery? Yep… the Intune MDM certificate will be whacked and renewed. This time, the TPM will protect the Intune MDM Certificate and its private key.(Microsoft Platform Crypto Provider)
InitiateRecovery | Windows Enrollment Attestation | Intune (call4cloud.nl)
In that same MDM hardening blog, I again stumbled upon the AIK certificate and learned how the recovery triggers TPM attestation. It almost sounds like Microsoft added the possibility of performing Intune/MDM Certificate Attestation, right? Ow wait
Looking back a year ago, we will notice that on 16 September 2022!! Something was added to the “what’s new in MDM for Windows 11 22h2”. A nice new node: MDMClientCertAttestation!
2. MDMClientCertAttestation
If we take a closer look at MDMClientCertAttestation in Microsoft’s documentation, we will learn that it shows us that this blob contains the MDM Certificate Attestation Information.
One thing is for sure: if the MDM Certificate wasn’t protected by the Microsoft Crypto Provider (TPM), how could we even perform attestation against it? Microsoft needed to make sure the Certificate it’s private key was protected by the TPM.
As with the Initiaterecovery CSP, I changed the MDM enrollment type to 14 and fired off the command.
As shown above, the “blob” containing the same attestation information we also noticed when I was playing around with the “AllowRecovery” and the “InitiateRecovery” CSPs with the localmdm tool. That can’t be a coincidence!
Would it be cool if we could somehow perform the Recovery and Attestation remotely? Again, oww, wait….
As shown above, look at what was added to the remote device actions in the graph in October 2022! Using the Graph, we can now perform a remote key recovery on our device.
3. InitiateMobileDeviceManagementKeyRecoveryAction
At almost the same time, Microsoft introduced the UseTPMenrollmentkey functionality, added MDMClientCertAttestation, and allowed remote MDM Key Recovery.
With this option, we can now send a remote command to the device to initiate the recovery of the MDM certificate. While doing so, it will also perform TPM attestation! Let me get a drum roll, please!
Look at what was added to the Official Microsoft roadmap in January!: Windows Enrollment Attestation!
Microsoft allows us to generate TPM Device Attestation reports on the fly by clicking a simple button! As shown below, we can click on “Attest” to start initializing the device management recovery key action.
Besides that nice button, we will also get an excellent overview of the current Attestation status in it
Guess which device was a physical device with a real TPM and which one was a virtual machine. The Virtual machine has the missing AIK Certificate.
If the device didn’t perform attestation before, we could easily trigger the TPM attestation. We can do so by selecting the device and clicking on “Attest”
The moment we click the “attest” button, the remote command to initiate the MDM key recovery will be sent to the device. I
As shown above, the SyncML tool allows us to spot it on the fly! When this remote command is sent to the device, the server initiates the recovery and triggers the “recovery” of the Intune MDM Certificate.
As we have learned by now, the recovery and MDM client certificate attestation will also be executed. The nodecache contains the same AIK information we retrieved earlier with the CSP.
But wait… I am not done yet. We now have a device with the Intune MDM private key protected by the TPM, and attestation has been performed successfully! What’s left?
4. The Total Flow
To make the above story a bit more clear a nice Picture to show you how it works in a couple of steps
- The It admin presses attest in the Intune Portal.
- This will execute a graph call to the device: InititiateMobileDeviceManagementKeyRecovery.
- The Device would receive the “InitiateRecovery” command
- The device will recover the Intune Cert to the TPM if needed
- The Device will perform attestation with Intune
- The IT admin can check the device’s attestation status.
5. IsTPMAttested
With the MDM Certificate hardened and attested, how can we ensure the device enrollment is also hardened? I want to block all devices that didn’t perform a successful attestation! Let’s start by creating a new Windows device platform restriction policy.
As shown above, I am going to block MDM! With this policy, no single device is allowed to perform an MDM enrollment. That’s not exactly something we want, do we?
Luckily, Microsoft created something beautiful! Microsoft gave us the possibility to create an additional filter we could use
(device.IsTpmAttested -eq “False”)
If we have created the filter, we can assign the new device restriction policy to all users and add the filter.
With this filter, we can block MDM enrollments for devices that did not successfully attest their TPM, hardening the MDM enrollment even further!
If this enrollment restriction is active and we are trying to enroll a new Virtual machine with Autopilot, we will immediately receive the message that something went wrong.
This error screen gives us the error 80180032 and notifies us that our device cannot be enrolled right now! NICEEEE! That’s certainly something I love! Hopefully, we won’t have the same attestation issues when we have AMD devices…
I guess Juanita (PM Autopilot) needs to update her Autopilot flow a bit with this MDM / Windows Attestation added.
Conclusion
This was the final blog post in the MDM Hardening/Windows Enrollment Attestation series. Microsoft seems to have started working on MDM hardening in early 2022.
The first step in the MDM hardening process was making sure that the Intune Device Certificate on newly enrolled devices was protected by the TPM (UsetTPMForenrollmentkey and using the Microsoft Platform Crypto Provider)
The Second step in the MDM hardening process was the “AllowRecovery CSP.” With this CSP, you can initiate “Recovery” on an existing device. This recovery would ensure that the certificate is stored in the TPM and kick off the MDM Attestation.
Once the TPM protects the MDM certificate, we can perform TPM attestation. From there, we could prevent non-TPM-attested devices from getting MDM enrolled by setting a nice enrollment restriction with a nice new filter!