[ad_1]
It’s been a week of randomness, but at least some of that randomness is interesting. Let’s look at a few goings-on in the world of Windows Autopilot.
Yes, you can generate hashes in Windows PE, but…
A blog post by Johannes Bedrech described a process that could be used to generate hardware hashes in Windows PE. I was initially skeptical of this approach, since I knew that Microsoft always recommended against this (to OEMs and to customers) because some of the information included in the hash (as I described here) would not be captured while in Windows PE, most importantly the TPM information that is the most important part; without that, things like self-deploying mode and pre-provisioning don’t work. But using a process described over a year again by Michael Meier (and which references a very long German government white paper that talks about the general requirements) that I had completely missed, adding one DLL that isn’t included in Windows PE by default (PCPks.dll) and registering it using RUNDLL32.EXE, you can then use the OA3Tool.exe (included in the ADK) to capture the hash for you.
But how complete is that hash? I captured the hash using this process in Windows PE, and then compared it with a hash from the same device captured in the full OS, both using OA3Tool.exe (which leverages the same library logic that the Get-WindowsAutopilotInfo* scripts and underlying WMI class leverage). It’s close, but not quite exact. There are some expected differences (OS version, date/time) that are inconsequential, but in addition to that there are a few others:
So it’s also missing the hard drive serial number, the display information, and the GPU information. Since this was a VM, it didn’t have any Wi-fi adapters, but that information would also be missing in Windows PE, since Windows PE doesn’t support Wi-fi.
What’s the consequence of that? In my blog that describes how the device uses the hardware hash to obtain a unique ID, I mentioned that only a few pieces of the hardware hash are sent to the cloud: MAC addresses, manufacturer, model, UEFI firmware version, device serial number, disk serial number, UUD, and TPM information. We’re mostly covered, but there are some gaps: the Windows PE hash doesn’t have all the MAC addresses and doesn’t have the disk serial number.
But will it work? Most likely, yes, but only because of the (undocumented and subject to change) process that is used to take that information and come up with a unique hardware ID number for the device: the TPM information wins out over all else, since it’s the most significant piece of information that is unique and difficult to tamper. But what if there is no TPM or if it has been disabled in the firmware (something that isn’t supported with Windows 11, but still happens)? In that case, it will fall back to other properties, some of which might be missing. So there is some risk involved.
In addition to that, Microsoft will likely never support the process of generating a hardware hash while in Windows PE, so use at your own risk.
Yes, Autopilot for existing devices bypasses personal device enrollment restrictions
A blog post by John Marcum pointed out something that I was always aware of, but had never actually seen documented: Windows Autopilot for existing devices bypasses enrollment restrictions on “personnally owned devices” if you have that blocked.
All devices that are deployed using Windows Autopilot for existing devices, done by dropping an AutopilotConfigurationFile.json into the right place on the disk (a process I describe here), are considered company devices, even if they weren’t pre-registered (or otherwise enrolled using a mechanism that makes the company devices, e.g. a DEM account).
OK, but what’s the risk here? That’s the subject of a few Twitter threads, like this one:
And if you follow through that, there are discussions around wiping personal devices, having access to company resources through deployed certs or VPN profiles, etc. But this all has one basic assumption: that anyone trying to do this still at least has an Azure AD user ID and password, ideally protected via MFA to keep the bad guys away. But apparently its possible to bypass MFA? (That’s a topic for a completely different conversation…)
You can at least identify the devices that were defined using Autopilot for existing devices. The ZtdCorrelationId value in the AutopilotConfigurationFile.json is passed along to Intune and AAD, and is stored in the Azure AD device object’s “enrollmentProfileName” property, prefixed with “OfflineAutoPilotProfile”:
So in theory you could at least build a dynamic group to select these devices to see which were deployed using this method.
Since most people generate the AutopilotConfigurationFile.json using the WindowsAutopilotInfo PowerShell module, you might wonder what it sets that ZtdCorrelationId value to by default. Since I didn’t have anything better to set it to (a random value didn’t seem very useful), I instead set it to the GUID of Intune’s Autopilot profile object:
If you allow enrollment of personal devices, there’s nothing to worry about, but if you don’t, well, maybe you want to read up on this to see what you might want to do (or maybe ask Microsoft to do).
Yes, Autopilot v2 is coming soon
It’s not been a very well-kept secret that Microsoft has been working on some changes to the Autopilot experience that have at least unofficially been called “Autopilot v2.” Rudy Ooms dug into the not-yet-complete implementation of this back in November in his blog. So we at least know that the look-and-feel of the enrollment status page (ESP) is going to change. (We never liked the original one — it had too little information for IT pros, and too much useless information for end users. The “too little” part was supposed to be addressed with the Autopilot diagnostics page, while the “too much” part needed a new UI design that never made it up the priority list due to other important things, like Autopilot for HoloLens and Windows 10x.)
But when are we going to see this? Well, it was announced in the Insider Preview blog yesterday for the latest Release Preview build that “[t]his update turns on the Autopilot 2.0 feature.” So that implies that it will be sooner rather than later, since the Release Preview bits will eventually target Windows 11 22H2 and 23H2.
But wait, you don’t see that text in the blog post? Well, Microsoft tried to erase it, but the Wayback Machine captured what it used to say:
So I guess they “unannounced” it? Oops. But regardless, I hope we’ll see it yet this year.
[ad_2]
Source link
