Last Updated on March 22, 2023 by rudyooms
This blog will be about me wrecking a Windows device during Autopilot Pre-Provisioning to see what is happening underneath. While doing so I stumbled upon some funny details.
I will divide this blog into multiple parts
Today I was playing around with Windows 10 and trying to perform an Autopilot pre-provisioning. Okay no problem here, right? Guess again, because I was trying to get a closer look at how Windows 10 HOME handles the Autopilot pre-provisioning…
As shown above, the device “somehow” (long live attestation… even for Windows 10 home devices) managed to get enrolled into Azure Ad but it failed at the “registering your device for mobile management” step. It’s quite fun to see a Windows 10 Home device succeeding in joining the organization / becoming Azure Ad Joined. That’s for sure! I decided to let it time out and just continue the process and reboot the device.
The device was still Azure Ad joined but I was missing the option to log in with a Microsoft 365 account (duhhhh…. Windows HOME) so I logged in with the normal user account I created before rebooting the device.
When taking a closer look at the Azure Ad account that is mentioned in the “Access work or school” settings I noticed this funny Autopilot account: Autopilot@domainname.com
At first, you could get the idea that it is using a sort of DEM (device enrollment manager) account to enroll your device with Autopilot but that’s not true! It’s just a fake account and nothing more!.
I will try to explain the reason behind it in this blog! Of course, I already wrote a blog about the Autopilot White Glove flow some time ago.
Autopilot White Glove Pre-Provisioned Deployment Flow (call4cloud.nl)
But looking back now at that blog, I have the feeling I missed out on some important parts about the Autopilot@ user, so I guess this is version 2 of that Willys White Glove Wonderland blog? I decided to take another deep dive into Autopilot pre-provisioning to determine why it needed the Autopilot@ fake enrollment account.
2. The Flow
Let’s start by taking a look at a chronicle overview of what happens when starting Autopilot deployment for pre-provisioned deployments. I divided the overview into main tasks and the corresponding subtasks.
3. Explaining the Flow
Now we have seen the chronicle flow, let me talk you through each step. So looking at the chronicle flow, we will notice that the device will start the Attestation and after the TPM attestation it will complete the “Securing your Hardware” step
I already wrote a lot about TPM Attestation and why it could haunt you. So I will advise you to first read some of these blogs to get a better understanding of what is happening during this step
Attestation and Compliance Series – Call4Cloud
If you have read some of the blogs, you may continue this blog…
After it finished the important TPM Attestation part, it will start the AADDiscovery by sending the email@example.com email address to the discovery service.
To do so it will make use of the following API DsrGetJoinInfoEx in the dsreg.dll file and will reach out to the discovery service
Please note: FOO will normally be used when a programmer can’t think of a better name. But as the domain name is very important it needs an email address(more on this later on), so I guess that’s why they came up with the MakeFakeUserEmail Function and the “fooUser”
After sending the firstname.lastname@example.org to the discovery service It will receive the information it needs to start the Azure Ad Join.
The Azure Ad Domain join request is initialized again using a “fake” email address. This time, NO “fooUser” for us but a nice email@example.com pcszuseremail address.
In this process, it will create its transport key with the tenant domain name in it and it will retrieve the AIK certificate.
This AikCertificate and the AttestationData will be sent out to the https://enterpriseregistration.windows.net/EnrollmentServer to request the MS-Organization Certificate
Besides requesting the Aik Certificate it will pre-create the device object. (which I also showed in the white glove blog)
After receiving the MS-Organization-Access Device Certificate it will add 2 SIDS (“Global Administrator Role” and the “Device Administrator Role”) to the Local Administrators group
After those SIDs are added to the local administrator group, it will install the MS-Organization-Access device certificate to the LocalMachine Certificate store.
Feel free to read another blog of mine! That blog will show you which certificate will end up in which certificate store, depending on the Enrollment
When taking a closer look at the exact moment, we will also notice that the device will become Azure Ad Joined.
But before the “Joining your Organization’s Network” phase will be completed it still will need to make sure the certificate is the right one by checking the OID values
Funny right, OID values. It’s a good thing I also wrote a blog about that one so you will know everything there is to know about it. Sounds almost like a coincidence right? Or maybe not?
If we “pause” the Autopilot Enrollment at this moment, we could also notice some fun behavior. As mentioned before, the device will initiate the join request by a fake pczuseremail address: “Autopilot@domainname.com“
When opening the “Access work or School” settings, we will notice that the device is connected to An Azure Ad by firstname.lastname@example.org
This information is also stored in the JoinInfo part of the CloudDomainJoin information in the registry
If you would run Procmon at that point in time, you will notice that this key will be set by the Svchost.exe process (I was expecting another process.. but hey, I am not complaining)
After the device is Azure Ad Joined, it will launch the ESTS Ticket (enrollment security token service ticket) phase.
During this phase, It will request an access token to authenticate against the enrollment services.
When looking at the windows.management.service.dll and the AcquireESTSTicketForMDM, we will spot the same behavior
This leads us to the MSADeviceTicket Function
We will notice that it will receive and caches the requested token/ticket for the enrollment.manage.microsoft.com and the enterpriseregistration.windows.net resources. When taking a look back at Procmon at that same time, we will notice that it also stored the 2 corresponding tbres files on the device in the system local appdata tokenbroker\cache folder
When decrypting those files from the system tokenbroker cache with this wonderful tool. this is what we get
As shown above, those 2 tbres files contain a lot of information such as the WTres_token (With the base64 encoded JWT token) and some other information like the MDM enrollment URLs, etc.
When you want to read more about those nice TBRES files.. please pay a visit to Adam Chester (@_xpn_) / Twitter and his blog about decrypting those files WAM BAM – Recovering Web Tokens From Office – XPN InfoSec Blog (xpnsec.com)
Before it could use these enrollment tokens, it will again start a discovery process with the “fake” email address email@example.com we also noticed this earlier
This time I will explain, why the email address is so important during the discovery even when the username is fake. When taking a closer look at the MDE2 (Mobile Device Enrollment) flow, we will notice that the domain suffix from the email address is used to resolve the address to the Directory Service (DS)
With the fake email address in the discovery request, it will retrieve it will get a DiscoverResponse with the Enrollment URLs
When it received the enrollment URLs it can start the Intune MDM enrollment by reaching out to the Enrollment ServiceUrl
When taking a closer look at the header below, we will notice that it will send the JWT Security token it got earlier (TBRES files) with the enrollment request
In that same request, after the token is validated the device will receive back the Intune Device Certificate as shown below. Yes…. you can click on the picture to get a closer look… do you remember my latest blog mentioning Certificate Stores?? Stores=My;System
After the Intune device certificate is created and imported into the Local Machine Certificate store it will also create the corresponding Enrollments registry key
Enrollment Created: HKLM\SOFTWARE\Microsoft\Enrollments\45BEE944-44B4-447F-AFFB-55331EC39F9A\UPN set: fooUser@wvdcloud.nl
At the same time, it will also create the corresponding Intune schedules to start the real Intune enrollment
After the device got enrolled into MDM/Intune, we still have a device that is Azure Ad Joined with the fake firstname.lastname@example.org account and that can’t be good right?
First off we need to ask ourselves why the device needed to become Azure Ad Joined in the first place because the device will also be Azure Ad UNJoined after it is enrolled into Intune. I guess that’s pretty simple because the Intune Enrollment relies on the Azure Ad Join to fetch the enrollment URLS!
Let’s proceed to the Unjoin to make sure the device could be Azure Ad joined with a valid user when the user turns on the device for the first time after the Pre-previsioning succeeded! To do so, it will start an Azure Ad Unjoin just some milliseconds after the MDM Enrollment,
Luckily Microsoft is describing this in their documentation
Ow, wait… guess not… Alrighty then!
To start the Azure Ad Unjoin process, the only thing it needs to do is find the right Certificate and trash it. I guess we know how this is done, right? Again by using the OID value, it will try to find the right device cert it needs to delete by searching for that specific OID value 1.2.840.1135126.96.36.1994.7 and will make a note of the thumbprint.
If the device finds the MS-Organization-Certificate with that specific thumbprint, it will delete the corresponding certificate and runs another OID check to make sure the certificate is deleted. When there is no device cert left, it will finish the device_Unjoin step and the device is no longer Azure Ad Joined!
4. FooUser and Autopilot@ user
As mentioned earlier in this blog, the discovery will be based on the domain name of the email address and NOT on the email address itself.
But you can never be 100% sure right? So I decided to create a Foouser and Autopilot user in my own tenant
I made sure it didn’t get a license and where NOT included in the MDM scope
After the settings were set to prove it doesn’t use those accounts for real, I started the Autopilot PreProvisioning
As shown below, it finished successfully with an existing unlicensed fooUser and Autopilot user which weren’t in the MDM scope
The elapsed time (36 minutes!!! way too long) is a different issue…
Rudy Ooms | MVP 🇳🇱 on Twitter: “Guess what I am going to do today? Wondering why suddenly the Apps Identifying just hangs there for 30 minutes during #windowsautopilot? I guess I know why….. @IntuneSuppTeam do you 🙂 ? #mem #msintune #intune #mempowered https://t.co/lcUIojEqbK” / Twitter
And with this flow explained, I will finish this blog because, in my opinion, it explained why it needed the Azure Ad Certificate to enroll into MDM and the need to delete the certificate, and by doing so the Azure Ad Join!
If you even spot the fooUser@ or the Autopilot@ user, you know why!