Autopilot for pre-provisioned deployment and the lost Azure/Entra Ad Join

This blog will be about an Autopilot White Gloved device that ended up in Intune but without an Azure Ad Join, even though it showed us a nice green screen before sealing it! This blog is a work in progress so it will be updated daily!!!!

1. Introduction

When a customer orders a new device, we wipe it first and reinstall it with the latest Windows 10 build. While doing so, we also check if everything is good to go before we start the white glove process. For example, we need to determine if key attestation is possible.

Another possibility would be to run this command: tpmtool getdeviceinformation

As we all know, TPM attestation is required when performing a white glove test. Also, beware: when you have a Tiger Lake chipset, you will need to use 21h2. However, none of the normal issues that could occur during the white glove test were noticed.

2. The Issue

First, I need to show you the exact issue I was trying to solve. Take a look at this nice Windows Login Screen.

The only option we had was logging in with the local admin account that was created during the white glove. At first, I had the idea that my Azure Ad Login screen went fishing.

That’s odd because normally, you end up with a nice login screen to log in as a user from your company, but this time… not! So, there is no Azure Ad login possibility on the device for us.

3. Trying to solve it

First, let’s check out if the device ended up in the Azure Ad portal.

Okay…? Looking at the picture above, Azure and Intune are detecting the device as Azure Ad joined? As the device is not used, we can just send a remove command to perform an Autopilot reset. So we did…

If you want to know more about all the possible options you have to start wiping your device, please visit this blog.

But even after an Autopilot reset, the device still had only the local admin on the login screen!!. Let’s dig a little bit deeper.

Again, we opened the Intune portal to check the last time it contacted Intune. As shown below… the device last contacted Intune while we were trying to solve the issue.

But still, wasn’t Azure Ad joined? What happened? It’s a good thing we have an additional local admin with LAPS implemented. I guess the first thing you need to do when you need to start troubleshooting an Azure Ad join failure is DSREGCMD /status. So we did!

Okay… The device isn’t Azure Ad joined, even though Azure and Intune think differently. And no, trying to enroll the device with the /Join switch isn’t going to work!

4. Azure Ad and Intune Device Certificate

Before we continue, I need to show you what happens when you perform a white-glove deployment (Autopilot for pre-provisioned deployments). First, I want to show you the normal device registration flow.

So before our device gets MDM enrolled and receives the Microsoft Intune MDM device CA, it will receive the Azure Ad Device Certificate. Let’s take a look at the device hardware information in Intune first.

Also, open the Certificate Manager and take a look at the Azure Device Certificate first before we continue

1. Device Certificate

You will probably have noticed two things:

2. Intune MDM certificate

Below is the Intune MDM Device certificate. As expected on a working Intune device, this certificate is valid and available. It will arrive at the device after the Device certificate.

Again you will notice 2 things:

1. Granted to: a bunch of numbers –> Your Intune Device ad which corresponds with the Intune Device ID in Azure and Intune
2. Granted by: Microsoft Intune MDM Device CA –> Intune –> So this is your Intune Device Certificate

If you want to read about my experience with an invalid certificate please read my blog about it.

5. Device Certificate and White Glove

Now that we know when the Azure and Intune device certificates will be delivered to our devices, we need to examine how this process works with White Glove. First, the Microsoft flow, and then my part.

(I am telling you this because I didn’t know it at first 🙂 )

When pre-provisioning a new device with White Glove, please take a look at the Certificate Manager. When the device is performing the first step, “Device Preparation,” the TPM 2.0 will make sure the device is authenticated to your Azure Ad tenant. (Attestation)

While refreshing the Certificate Manager, you will notice the MS-Organization-Access device certificate arrives at the device in just a few seconds. After a few seconds, it disappears again! I was in the understanding it would stay there :). But I guess not.

Of course, the Device Object is pre-created successfully in Azure Ad itself!

So, let’s reboot the device and see what happens when the device arrives at the first login screen.

Okay? So no Azure Device Certificate and the device is still not Azure Ad Joined. So enter your Office 365 credentials and start logging in. When logging in, you will notice that within a few seconds, the Device certificate arrives, and the device will be Azure Ad Joined.

To resume: When using White Glove pre-provisioning the Azure Ad Device Certificate will come back and stays there during the first User Login, and dsregcmd will show you that your device is Azure Ad Joined

6. Back to the Issue

So the issue is totally Azure Ad related and nothing more. Intune was working as expected. Of course, we checked out the Settings page to determine if there was a school or work account attached. But I guess you already know the outcome. No account was configured

So the AAD event log should be your next step to investigate.

We were only noticing one error… and nothing more…. “AAD Cloud AP plugin call GenericCallPkg returned error” and 0xc0048512

When looking at this event, you are probably looking at an error while acquiring the Token for the local user and not the user you have issues with so you can skip this one…. (unfortunately for me)

Of course, when you are not blocking enrollment of personal devices and don’t have conditional access for requiring compliant devices configured you could do it manually but this time I wanted to know if I could do the same with the AAdinternals module. So I installed the module and tried to emulate the Azure Ad join.

(The device isn’t going to be joined by Azure Ad with this action! but I wanted to know if any other errors could popup)

No weird, red errors…

7. Fixing it manually (for now)

Okay, screw it… I can’t find any errors that could point me to the real problem, so let’s fix it.

We changed the possibility to enroll private-owned devices to Allow… because we normally restrict it…

Now, let’s join the device manually. Maybe a new nice error could pop up?

Duh… Of course, the device was already present in Azure Ad and we got the 8018000a error. This device is already Registered

So we removed the device in Azure… And now I need to repeat myself, we removed the device in azure.

Have you ever tried to remove an autopilot device in Azure? You will be prompted with a notification that you can’t delete a Windows autopilot device here.

Another funny fact normally, you only have one device in your Azure portal with a nice autopilot icon attached to it

But this time, we noticed the exact same device but with a normal icon. Maybe it was because we tried the AADInternal solution first? I am unsure, but we removed the device to see what happened.

After removing the device from the Azure Portal and only the Autopilot device was present, we tried to perform a manual Azure Ad join again. Within a few minutes, the device was Azure Ad Joined, and also dsregcmd /status finally showed us, it was AzureAdjoined

And pretty please with sugar on top… don’t forget to block the Intune enrollment of personal devices again.

Conclusion

I now know what happened—I only need to reproduce it! Let me explain what “could” have happened. After the device turned green, my colleagues sealed it, as you should do. But after it turned green, they turned it back on again only to perform some last-minute updates from the OOBE screen, which was still running in the defaultuser0 context. I guess rebooting from there really broke the Microsoft Sign-in page!

Again, I still need to reproduce it, but it very much looks like this was the issue!

But as a quick note: Users are identified based on their credentials, Devices are identified by certificates!

I’m done…….(for now)