AD FS Authentication Methods supported during Autopilot

If your organization is using AD FS, you may start running into errors when you try testing Autopilot. Reason being – not every AD FS authentication method works during the out-of-box-experience. Let’s take a look at the Authentication Methods from this Docs page:

The troublemakers

Windows Authentication (sometimes referred to as Windows Integrated Authentication) can’t work during Autopilot because the device is not yet joined to your domain, so the defaultuser0 account that Windows uses during the out-of-box-experience (OOBE) will not be able to authenticate properly. No Windows credentials prompt will pop up, you’ll simply hit an error on the AD FS page.

Certificate Authentication also can’t work during Autopilot, because your device doesn’t have any certificates deployed to it yet. And OOBE doesn’t support PIV/CAC/smart cards for authenticating so no certificates from those either. Just like with Windows Authentication, you’ll hit an error on the AD FS page. Smartcard/certificate authentication is explicitly not supported during OOBE in the Autopilot network requirements.

Device Authentication is in reference to Azure AD join/register to provide an SSO experience. During OOBE the Windows 10 device is not yet joined to Azure AD, so this method will also error out right away.

Microsoft Passport Authentication, now known as Windows Hello for Business, requires the device to register with the identity provider before a credential is provisioned. And you guessed it – since the device hasn’t joined AAD yet, because it is still in the OOBE, this method will also error out right away.

Check out a newer blog post wrote, about how to get around OOBE with Autopilot Pre-provisioning to allow smart cards!

How to use Autopilot with Smart Cards

Which AD FS Authentication Method does work?

Currently, only Forms Authentication (also referred to as username/password) works properly during Autopilot/OOBE for environments using AD FS. I’ve only verified this through testing as it doesn’t seem to be documented anywhere. But the experience for the end user is simple – they’ll be redirected to a username/password log in page, provide their credentials, and move onto the next step of the Autopilot process (generally Enrollment Status Page).

The process is functionally similar to the Azure AD Join for Federated Diagrams diagram on the Hello for Business Docs:

In the diagram above, you can see that the Cloud Experience Host app (effectively the OOBE app) collects the username and password, and sends them to AD FS. Unfortunately that’s the closest documentation I’ve found to specifying the supported OOBE authentication methods.

What if I don’t want to use passwords in my environment?

So there is one additional primary authentication method left – Azure MFA/3rd party MFA. At time of writing, when I tested this it also resulted in an error in OOBE. But theoretically MFA could work – we know Azure MFA for managed AAD environments is supported in OOBE and works as expected:

So then it seems that either AD FS or Windows 10 haven’t been configured to work with MFA in federated environments. This means – if we don’t want to use Forms based authentication, unfortunately, deploying devices with Autopilot in an AD FS environment just isn’t possible currently.

Hopefully this provides you the information you need to get Autopilot working in your environment. Happy deploying! 🏍