Windows AutoPilot and mainboard replacements – Or “how random computer show up in your tenant”

If you ever had a computer that you wanted to setup and suddenly presented you with a screen trying to enroll you into a company that you never heard of, or someone calling you and telling you that they have your authentication screen on their computers, then this is a post for you. If not, but you have any computers registered for Windows AutoPilot, call yourself lucky, but please keep reading.

This whole problem is being caused by refurbished mainboards, which can cause serious problems with Autopilot registered devices. Interestingly, no matter if you are actually using Autopilot or not. In this post I’m going over some details on what and why this his happening. And how to at least mitigate the security risk associated with this.

The problem

Maybe you have run already into a situation, where one of your machines had some issues, and as part of the manufacturer service, it got a new mainboard. To save resources (and money), manufacturers often tend to use refurbished mainboards for this. Which at first glance shouldn’t be that big of an issue. They update the serial number and/or other identifying information to match the information from the mainboard that was replaced and it should still identify as “your” machine, right?

First off, if you try to go through Windows Autopilot enrollment after this, one of three things is very likely to happen:

1. The computer will go through the standard Windows Setup experience, as the device is no longer identified as registered for the Autopilot process.
2. The computer will start the Autopilot enrollment process, enrolling you into your tenant.
3. The computer will start the Autopilot enrollment process, trying to enroll you into the tenant of a company, that you have no association with.

Windows Setup, the Windows Autopilot registration process and the “Hardware Hash”

To understand this better, we need to look at what happens at the beginning of the Windows Setup process. Simplified, when the Windows Setup process starts, it will reach out to the global Microsoft Windows Autopilot service and submit the “Hardware Hash” of the current computer. Microsoft then uses the information from the Hardware Hash to look up the computer in the database of all Autopilot registered devices for all their customers. And if matched to a registration, return information about the correct tenant to the computer. The computer will then reach out to the specified tenant to request the assigned policies and do whatever has been configured for this device. You can find a lot more detailed information about this process at What happens when a Windows Autopilot-registered device starts up?

The exact process and information used to match the information from the supplied hardware hash to the registration is not publicly available. To stay with Michael Niehaus, “it’s a fairly opaque process”.

Some of this information is listed in the Windows Autopilot device guidelines that need to be written to the BIOS. The documentation for the oa3tool, which can be used to decode the hardware hash, lists several critical fields like serialnumber, uuid, as well. The Windows Autopilot motherboard replacement guide from Microsoft lists the following information to be populated to the new mainboard at a minimum:

• DiskSerialNumber
• SmbiosSystemSerialNumber
• SmbiosSystemManufacturer
• SmbiosSystemProductName
• SmbiosUuid
• TPM EKPub
• MacAddress
• ProductKeyID
• OSType

Based on this, it’s fair to assume, that they typically use a combination of multiple values to match a device to the registration data. Which perfectly explains the first two cases that I mentioned earlier. If the new mainboard has been updated properly with all this critical information, and all other critical hardware components like hard drive, nics etc are also still the same. This computer should still be considered “the same”. Hence is identified as a registered device and can enroll into your tenant. Also if some of these values differ, it can no longer be matched and falls back to the standard Windows Setup experience.

It’s important to highlight, that the Windows Autopilot motherboard replacement guide explicitly states, that every time you are replacing any key hardware components, which is explicitly not only the mainboard, you have to deregister the device and then later reregister it with the new Hardware Hash to avoid any of these problems. And they go through a whole lot of scenarios with different variations of hardware changes, what is supported, what isn’t etc. And that’s the ideal case, that every manufacturer, repair facility, IT support, etc should follow.

If they don’t, you can end up with the 3rd situation that I described, where your computer now suddenly tries to enroll into the tenant of a different company. Or someone from a different company might be asked to enroll in yours.

This is not only annoying and time consuming to fix, it could also pose a security risk. At first glance you might think that you still need to supply user credentials to actually start the process. White-Glove/Pre-Provsioning and Self-Deploying modes though don’t need a user to authenticate. Microsoft kind of addressed this problem in Updates to the Windows Autopilot sign-in and deployment experience, where you can no longer go through this process, if there is still an existing Intune record. But if the Intune record does not exist anymore or the computer had never initially enrolled, you are in for a treat and the enrollment will just continue. And then you are only one Shift+F10 away from at least temporary system level access on a device that is enrolling into the “wrong” tenant.

“Unique” identifiers

The initial question that I had when experiencing this problem was, why would a refurbished mainboard, that got basically all its critical key identifiers updated and that is put into a computer with different hardware (hard drive etc), still match it’s “original” registration? Based on all the information supplied, even small changes in the hardware should render the registration data invalid.

So at least in some cases, there must be a property that has a higher relevance than others, ignoring that other key identifiers have changed.

Let’s use the oa3tool and decrypt a hardware hash into the actual hardware inventory

As you can see, it contains a lot of information. And we see all the identifiers listed, that were mentioned before. Serialnumber, UUID, disk serial number etc.

TPM for the win

Though there is one value, that really caught my eye. It’s called “OfflineDeviceId”. The “OfflineDeviceIdType” says “TPM_EK”. EK stands for Endorsement Key, which plays a crucial part in the TPM attestation process. The idea behind this is to have something on a device, that gives a strong guarantee, that this is “this” device, and no other device can use this information. Unlike things like serial number etc, that can be re-written with specific tools from the mainboard manufacturer, the EK is a unique, asymmetric, cryptographic key, that is burned into the TPM chip by the manufacturer. Michael Niehaus has a very interesting blog post about TPM Attestation: What can possibly go wrong, that goes through some of the details about the attestation process. The EK can be considered “unique” and extremely difficult to temper with. Perfect to match a device. It just has one major drawback. As it’s kind of “burned” onto the TPM, it “travels” with the mainboard.

Rudy Ooms has a great and extremely detailed post about Breaking the TPM when replacing the System Board, where he shows which impact the replacement of a mainboard has on things like AzureAD account etc.

The hardware inventory also lists “TPM EkPub”, which is the public key part of the EK. With this, the TPM chip can proof that is has the corresponding private key to this public key. And as the public key is part of the registration data, Autopilot seems to favor this value over any others. Which kind of makes sense, as it’s basically the only real “unique” value, if available.

Collecting some data

The screenshot above was from a device with a refurbished mainboard. I happened to have a full export of all our hardware hashes from roughly a year ago. Now knowing what to look for, I wrote a small script that went through all exported hardware hashes, used the oa3tool to decrypt each hardware hash and wrote the full hardware inventory of each into a table. Which then allowed me to find the hardware hash of the device, which this refurbished mainboard had been taken from. And it confirmed my assumption. Almost all identifiers like serial number, uuid, disk serial number etc, were different. Only one of the MAC addresses, the one from the built-in NIC, was the same. But the OfflineDeviceIdType was TPM_EK, the TPM EkPub was identical, as expected. And the OfflineDeviceId was identical as well. So I’m assuming the OfflineDeviceId is a hash or some derived value of whatever criteria is used to identify the computer.

Based on the assumption, that the OfflineDeviceId plays a crucial part in the registration process, I had a deeper look into the data that I just had created from a year ago. I also exported all current hardware hashes, ran through the same process and then mapped them based on the serial number, which is a “unique-enough” property in my environment. About 82% of all devices use the TPM_EK as OfflineDeviceIdType. And sure enough, about 1% of these devices had the mainboard swapped. Interestingly, some of these refurbished mainboards showed up in different computers later, which gave me a great detailed view into the before and after of the exact same mainboard.

Based on this information, I ran a bunch of tests with different hardware, changing hardware components and settings, each time verifying, if they would still be “detected” as the registered device by the Windows AutoPilot service. And one commonality in all my tests so far was, that the computers got properly detected as a registered device, when the OfflineDeviceId within the hardware hash was still the same. Once the OfflineDeviceId changed the computer was no longer detected as registered, and the old registration needed to be removed, and registered again with the new hardware hash. So based on this I’m slightly confident, that the OfflineDeviceId is actually a pretty good indicator to check for changes that might impact the Autopilot registration data.

Conclusion

You have to take this with a pretty large grain of salt though. “Correlation is not causation”, and my assumptions are based on a limited dataset of ~150K hardware hashes. Also there might be additional factors playing into this, especially for other OfflineDeviceIdTypes, which I probably have to dig deeper into in a future post.

Considering all the above, my key take-aways from this for now are:

• Ensure to work with your hardware vendor/support company to keep track on mainboard changes.
• Make sure you strictly follow the Windows Autopilot motherboard replacement guide
• Regularly collect the hardware hashes from all your devices and keep track on some key information in the hardware inventory, especially the OfflineDeviceId.
• Implement a notification method if the OfflineDeviceId (or any other important property) of a device changes, as some cleanup might be necessary if someone did not properly follow before-mentioned process. You have to use a property inside of the hash, as the hardware hash itself will change every time it’s being collected, as it contains a timestamp of when the data was collected. Shannon Fritz has an interesting blog post going into why you see Different Autopilot Hardware Hashes from the Same Device.
• If possible, match the instance of the hardware hash that was used to register the device to the registration data. The Autopilot registration data that is available from Microsoft Graph does only contain the serial number as identifying information. Almost useless for this scenario. Without this match, you simply don’t know exactly what data was used to register, so most must be treated as outdated if a change is detected. If the OfflineDeviceId proofs to be a helpful indicator, you can use this as key value to match.
• If possible, keep the older hardware hashes for reference purposes. As seen, you never know when this pretty detailed information might come in handy, while most of the previous data has likely been purged already from your system that collects the hardware inventory.

I’ll publish another post soon with a custom solution that I’m currently working on, that could be used to keep track on this.