Last Updated on May 5, 2024 by rudyooms
This blog will investigate what happens under the hood when our device is enrolled with Windows Autopilot during the “preparing your device for mobile device management” phase.
I will divide this blog into multiple parts.
1. Introduction
In this blog, I will discuss a well-known enrollment process that occurs when your device is enrolled with Windows Autopilot.
When we enroll our device into Windows Autopilot, it first joins Entra (Joining your Organization’s network). Once it’s enrolled in Entra, the requirement to enroll the device in Intune is fulfilled.
With the requirement fulfilled, the device would start registering and enrolling the device for mobile management (MDE), AKA getting onboarded the Intune.
We first need to examine the MS-MDE enrollment itself to understand what’s happening. When looking at the official MS-MDE flow, we will notice that it will take 5 steps to enroll our device into Intune.
- Resolve Discovery Service Address
- Discover
- Get Security Token
- GetPolicies
- RequestSecurityToken
Nothing more, and the enrollment should succeed in the end. That was simple, right? Well, shall I add Fiddler to this MDE flow to make it more understandable?
2. The Flow
Let’s take a look at the improved MDE enrollment flow I created to understand better how our device is enrolled into Intune and how it retrieves the Intune MDM Device Certificate.
3. The Explanation
With the adjusted MDE-Flow, it also makes sense to add some explanation. To do so, I added the numbers to the flow corresponding to the numbers and phases below.
1. Resolve Discovery Service
The first step in the mobile device enrollment shows us that entering our username during the Azure ad Join will resolve the service URI (enrollment.manage.microsoft.com). This service uri is needed to discover the actual enrollment URIs the device needs to kick off the enrollment
2. Discover
In the second step of the MDE, the device will reach out to the discovery service by using the email address (as it only needs the domain prefix). We will spot some similar behavior when we preprovision our device with autopilot. If you want to read more about how this happens during Preprovisioning and which fake username it uses, you must read this blog.
Autopilot Pre-Provisioning | Technical Flow V2 | Intune (call4cloud.nl)
The discover response we got back contains the real enrollment uri we need to perform the enrollment
3. Security Token
Before we can start the real enrollment, we need to have a security token to authenticate ourselves to the authenticationservice url.
To do so, we need a security token from a Security Token Service (STS). Luckily, we already got that token earlier on in the autopilot flow. `If you want to know more about how the STS works, I advise you to also read this blog.
Fetch the Autopilot Profile with PowerShell and a token (call4cloud.nl)
A fun fact…. This security token /cookie will also be cached locally on the device with a tbres extension. With some excellent tools, we can even decode that TBRES file. When looking at the decoded tbres file, we will spot another base64 encoded wtres token in it. Which we could also decode again
When decoding it again, we will spot a Json web token in it with some additional information, such as
Deviceid, Tenantid,IP address, Zero touch device id (ztdid)
4. GetPolicies
The fourth step in the MDE flow is the GetPolicies step. The device would reach out to the enrollment service with the access token we got before (binary)
In the policy response, we will find the blueprint/template for creating a certain X509 certificate. Let’s proceed to the last step to find out which X509 certificate I am referring to.
5. RequestSecurityToken
With the blueprint in our pocket, the device starts requesting a specific security token (again with the access token in the request)
In the request security token response, we will notice again a binary security token.
We could decrypt the token and search for the sentence: encoded certificate.
We could fetch the base64 and export it to a certificate ourselves if we want.
$certBase64 = 'BinarySecurityTokenHere' $cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]([System.Convert]::FromBase64String($certBase64)) $cert | Format-List * $Base64Cert = @( '-----BEGIN CERTIFICATE-----' [System.Convert]::ToBase64String($Cert.RawData, "InsertLineBreaks") '-----END CERTIFICATE-----' ) $Base64Cert | Out-File -FilePath c:\install\mdmcert.cer -Encoding ascii -Verbose:$VerbosePreference
When we open it, we notice that this encoded certificate is nothing more than the Intune device Certificate. This certificate secures the communication between the device and the service.
The response will also contain the location where the certificate needs to be stored, in addition to the certificate itself.
The Intune device certificate is stored on our device and in the TPM, and the enrollment is complete.
Conclusion
Knowing how the Intune enrollment kicks off during Autopilot could be helpful when you find yourself in a situation where you need to investigate some issues with it it. Hopefully, this blog shows you a bit more info
