Recently we’ve been working through the process of getting our internal data security team to sign off on our plans to use Intune to manage devices. One sticking point has been allowing the OEM to register devices in our tenant. This has particularly troubled them and they want to know what else can the OEM do with our tenant?
When we explained that we were going to have the OEM register newly purchased devices with our tenant so that we could leverage Autopilot, the security team started asking some questions:
- What account are they using to access our tenant?
- Is it MFA enabled?
- What else can they access (and modify)?
The simple answer is that they A) are not accessing our tenant and B) cannot see or modify anything.
The issue stems from how it is presented, “The OEM will register devices with the customer’s tenant.” The exact wording may vary, but the underlying implication is the same, the OEM is going to be accessing the customer’s tenant and writing information there.
This is not the case though and a more appropriate statement would be something more like, “The OEM will, on behalf of the customer, register devices with Microsoft’s Autopilot Service.”
You see, there are three parties involved in the process:
- The OEM
- Microsoft
- You (the customer)
The message used though generally implies that there is direct interaction between numbers 1 and 3, but that is not how it works. Everything goes through Microsoft’s Autopilot Service and the OEMs are not touching individual tenants.
So far, this is not spelled out and explained well in any official Microsoft documentation. (That has been our problem, our security folks want official documentation.) What I have here stems from stitching together bits and pieces of the documentation, some logic, community involvement, and some good old detective deduction.
| Before I begin, I want to thank Rudy Ooms as he was able to shed light on the pieces hiding in the shadows. You can find him here: Rudy Ooms | MVP 🇳🇱 (@Mister_MDM) / Twitter |
Microsoft’s Autopilot Service
At the heart of the process is the Autopilot Service. In its simplest form, this is a central database that associates all of the hardware hashes with their respective tenants.
Exhibit 1: The Endpoint Point of View
Let’s start with the endpoint. Picture if you will a user gets a new device, powers it up, connects it to their home WiFi and is ready to begin Autopilot. For the sake of argument, let’s forgo any central database of registered devices and imagine that devices are directly registered in each individual tenant.
When our sample device steps out onto the Internet and yells into the darkness, “Here is my hardware ID! Does anyone know where I belong?”, without a central database of some kind it has to wait for a Yea/Nay from how many thousands of tenants around the globe? Every enterprise tenant, developer tenant, free trial, demo, lab, etc., they would all have to respond before the device could begin the Autopilot process proper.
And what if it was associated with multiple tenants? Would the first to respond “win”?
I’m glad you ask…
Exhibit 2: The Intune Point of View
Again, let’s forgo any central database of registered devices. A device cannot be associated with multiple tenants, the “system” will not permit it. If you have access to two or more tenants you can try this. Simply take a device that is already associated with one tenant (or associate it yourself) and then try to associate it with a second tenant.
It will fail and you will get the following error message:
In this case I took a device already associated with our pre-production tenant and attempted to associate it with my own tenant. Without a central database, how did my tenant know that this device was already associated with another tenant? For that to happen it would require all of the tenants around the globe cross-checking with each other to ensure that hardware ID isn’t claimed already. All of the tenants would have to be doing this for every single device registration. Imagine the chatter that would be involved.
I imagine that this would collapse under its own weight.
Back to Microsoft’s Autopilot Service
The Autopilot Service handles all of this. It is the “traffic cop” of the process. In the Configuration Manager world think of it this way; when you PXE boot a client the Management Point will work out what boot image should be offered up based on what task sequences are deployed and when. Same concept, except when our sample device steps out onto the Internet and yells, “Here is my hardware ID! Where do I belong?” the Autopilot Service will take that hardware ID, look for it in its database and then (if found) point the device to the associated tenant.
On the other side, when you try to associate a hardware ID already claimed by another tenant, it is the Autopilot Service that catches the mistake. It looks up that hardware ID and if found kicks back the failure. If it is NOT found, it then associates it with your tenant by adding the entry into the database.
References
Something Went Wrong when fetching the Autopilot Profile (call4cloud.nl)
