Last Updated on July 21, 2022 by rudyooms

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!!!!

I will divide this blog into multiple parts

1. Introduction
2. The Issue
3. TRYING to solve it!
4. Azure Ad and Intune Device certificate
5. The Device Certificate and White Glove
6. Back to the Issue
7. Fixing it Manually for now

1. Introduction

When a customer orders a new device, we are making sure we wipe it first and reinstall it with the latest Windows 10 build. While doing so we are also checking if everything is good to go before we start the white glove. As an 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 you want to perform a white glove. Also beware, when you have a tiger lake chipset, you will need to use 21h2. But none of the normal issues that could occur during the white glove was 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 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 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 still even after an Autopilot reset, the device still ended up with only the local admin on the login screen!!. Let’s dig a little bit deeper.

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

But still, it 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 would be DSREGCMD /status. So we did!

Okay… The device isn’t Azure Ad joined even while 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 are performing a White glove deployment (Autopilot for pre-provisioned deployments). I want to show you the normal device registration flow first.

So before our device gets MDM enrolled and would receive 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 2 things:

1. Granted to : a bunche of numbers –-> Your DeviceID which corresponds with the Azure Device ID in Azure

2. Granted by: MS-Organization-Access –> Azure AD –> So this is your Azure AD Device Certificate

2. Intune MDM certificate

As shown below the Intune MDM Device certificate. As expected on a working Intune device, this certificate is valid and available. This Certificate will arrive at the device after the Device certificate.

Again you will notice 2 things:

1. Granted to: a bunche of numbers –> Your Intune Device ad which corrosponds 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 we know when the Azure and Intune device certificates will be delivered to our devices, we need to take a look at 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 for 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 like 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 Azure Ad joined 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 which 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.

Did you ever try to remove an autopilot device in Azure? You will be prompted with a notification you can’t delete a windows autopilot device here.

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

But this time we noticed another exact same device but with a normal icon? Maybe it was because we tried the AADInternal solution first? I am not sure but we choose to remove the device to see what happened.

After the device was removed in the Azure Portal and only the Autopilot device was present we tried to perform a manually 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 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)