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

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

This blog will be about an Autopilot White Gloved device that ended up in Intune but without an Azure Ad Join even while it showed us a nice green screen before sealing it! This blog is 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
  8. A fun fact

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.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

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 what the exact issue was, 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? Did my Azure Ad Login screen went fishing?

relaxing jon glaser GIF by truTV

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

Afbeelding met tekst  Automatisch gegenereerde beschrijving

Okay… The device isn’t Azure Ad joined even while Azure and Intune think differently. And no, trying to enrol 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. 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 corrosponds 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 this is 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.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

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 preprovisioning the Azure Ad Device Certificate will come back and stays there during the first User Login and dsregcmd will show you, 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

Afbeelding met tekst  Automatisch gegenereerde beschrijving

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

We were only noticing one error… and nothing more… Try to google the error “AAd Cloud AP plugin call GenericCallPkg returned error” and 0xc0048512. You will notice there is no information about what the error means.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

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 enrol 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.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

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.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

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.

8. A fun fact!

While getting to know the White Glove flow, I was also experimenting with the Device Certificate itself. Did you ever try to delete it to see what happens? Before I deleted it, I exported it to a .cer file (without the private key… as its not exportable of course)

This was a screenshot before I deleted the certificate

And this screenshot was just 1 second after I deleted the certificate

As the Device Certificate is responsible for a working Azure Ad Join, it broke immediately. Also rebooting the device ended up in the same issue I showed you earlier.

But what happens when we import the Device certificate back into the store?

As shown above, the device was immediately Azure Ad joined again. But did you notice the DeviceAuthStatus: Failed. Device is either disabled or deleted. Luckily you could restore the connection with the dsregcmd /forcerecovery option.

Please note: When preventing personal devices to be enrolled with the enrollment restrictions, this isn’t going to work

Let’s take a look at dsregcmd and the certificate

As shown above… the problem with the private key missing is fixed and everything is working again. I also tried to copy that cert to another device already enrolled into another tenant… That was also quite fun 🙂

Conclusion

I still don’t know what happened, I guess that’s the conclusion and nothing more…

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

I’m done…….(for now)

And Im Done GIFs - Get the best GIF on GIPHY

Leave a Reply

Your email address will not be published. Required fields are marked *

11  +    =  15