Event banner
Event details
Joining an existing device to Entra/Intune through settings - accounts - access work or school works fine using a FIDO2 key such as a Yubikey.
However, after attempting to sign in to Windows 11 (24H2) using that same key - Windows skips the Enrollment Status Page and goes straight to desktop. This also causes Windows to skip automatic Windows Hello deployment.
ESP only works if you sign in with a password first and then subsequent FIDO2 key (enforced by Conditional Access).
OR... If you enroll via OOBE using a FIDO2 key. Strangely, this works great and ESP runs as expected.
Is this expected? A bug? Our use case of enrolling existing devices is the most frequent for us, as we're an MSP for small businesses.
(And yes, I asked this here a while ago, but I didn't see any change yet)
- Joe_Lurie
Microsoft
Dom_Cote I checked with the team that owns Autopilot and Enrollment Status Page (ESP). They said that seems like it might be a bug and suggested you open a ticket.
We already did a while ago - and the response was pretty much: "we've never seen this before" and don't know how to deal with it. 🤣 This, after it was already escalated.
To clarify: We don't use Autopilot. Our customers almost always have existing devices with existing user profiles that we don't touch. So wipe and load is not an option for us. (A great way to enable work and personal use on the same PC, btw)
To clarify some more: Both going through OoBE and Autopilot V1 and V2 work fine.
The issue is when folks join an EXISTING device to Entra/Intune and then sign in to the device with their new Entra account for the first time. ESP only runs when the very first sign-in to the new Entra account is done by password. If you sign in straight with a Yubikey, ESP is skipped. To me, it looks like Windows connects different endpoints and/or receives different tokens, depending on whether initial sign in is by FIDO2 or Password. But ONLY on existing devices.
Is ESP owned by the Autopilot team? Would they even be the folks to ask? Based on the different sign-in behavior, could this be somehow rooted in Windows itself and how it gets its tokens or signs in to Entra/Intune?
Bear in mind that during OoBE / Autopilot, we're signing in to Entra with FIDO2 via Web. But on the Windows lockscreen, we're not, we're signing in locally. It's only after the password sign in fails due to conditional access and Entra butts in to prompt an MFA challenge is when ESP starts working. These are very different authentication flows - with one working as expected (ESP was designed to work with web sign in during OoBE and AP), and the other local authentication flow not working.
Presumably, neither the Windows nor the ESP teams had this on their radar when they built their programs.
And I get it - since most of your large enterprise customer will ALWAYS wipe and load. So no one probably ever noticed this. But our main use case is onboarding existing devices.
Mind you, we currently cludge it by providing customers with an Entra password that they'll never use again after onboarding. But it's not elegant - as we'd like to be 100% passwordless. And I'm sure MSFT too. 😁
