Background

I’ve recently been deploying a new enterprise setup for my company. Part of this process involves configuring device registration with an Azure Hybrid Active Directory. We also decided to use Active Directory Federation Services (AD FS) with Multi Factor Authentication (MFA).

While setting up one of the machines I ran into the above screen while trying to setup Windows Hello for Business, AKA a pin for the user I was logging in as. The proves to be a problem as most businesses will restrict what resources you’re allowed to access when a pin isn’t configured.

The issue turned out to be the initial setup for Windows Hello was being blocked by our MFA. As it turns out, Windows Hello first does a certificate exchange which doesn’t work with MFA. AD FS has a default access control policy titled “Permit everyone and require MFA, allow automatic device registration”. As it turns out, this policy is only sufficient for on premises device registration. This policy is not sufficient for Azure device registration.

Solution

To solve this issue, I created a new policy based off of the “Permit everyone and require MFA, allow automatic device registration” policy. To figure out what was needed, I looked at the Event Viewer on our AD FS machine for the specific claims that were generated when Windows Hello was enabled. A commonality to these requests is that the Client Application claim equals “Windows-AzureAD-Authentication-Provider/1.0”. Below is the new claim with the Azure Client Application claim added.

After creating this policy, remember to change the Access Control Policy that AD FS uses for Office365 to use the new policy you’ve created. Apply the policy, and Windows Hello for Business registration should work!

While the above text once worked, my solution is now to choose the policy “Permit everyone and require MFA from extranet access”. You should investigate your enterprise layout to determine which solution works for you.