Signing in with FIDO2 fails

[ns3c]

Hey team,

I've gotten the application to a point where I can enroll a FIDO2 device during the login flow, and enrollment succeeds (it says successful, will forward me to relying party, and my AD attributes are populated, as expected).

When trying to login again with MFA and use this FIDO2 device though, I get this error in the ADFS event log, after touching the device to complete FIDO2 login:

Encountered error during federation passive request. 

Additional Data 

Protocol Name: 
Saml 

Relying Party: 
https://fakewebsite.com/saml/metadata 

Exception details: 
Microsoft.IdentityServer.AuthenticationFailedException: None of the available strong authentication method(s) MultiFactorAuthenticationProvider can fulfill the current request. Try again and choose different authentication method during primary authentication.
   at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.EvaluatePolicy(Boolean& isLastStage, AuthenticationStage& currentStage, Boolean& strongAuthRequried)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthMethodsFromAuthPolicyRules(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthenticationMethods(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

ADFS front-end shows a similar error, stating "None of the available strong authentication method(s) MultiFactorAuthenticationProvider can fulfill the current request. Try again and choose different authentication method during primary authentication."

For awareness, I have not enrolled a mobile authenticator, and don't plan to use this functionality. I'm able to sign in using the authenticator though, if I configure it, which tells me there is no SAML issue or issue with the relying party.

[redhook62]

Hi, @ns3c

According to your logs, you have configured adfsmfa as primary authentication. You must therefore, imperatively disable adfsmfa from secondary authentication providers. To manage options use the Set-MFAPrimaryAuthenticationStatus cmdlet

regards

[ns3c]

Indeed; this did allow me to sign-in with the FIDO2 key, after disabling the plugin as an additional authentication factor, as well as setting the policy to one that didn't require MFA.

Out of curiosity, how does this work alongside enrollment, which requires these options to be turned on?

Feel free to close the issue, and I appreciate all of the help, you have been awesome @redhook62

[redhook62]

@ns3c

Thank you, External providers (mails, extrnal and azure) considered unreliable are excluded from the available options, but can be reactivated, it will be your responsibility.

The possibility of managing its options for a user is also deactivated, it would still offer hackers incredible facilities, but you can also reactivate these functions (absolutely not recommended).

In principle, online registration works, however during this phase no proof of identity will be provided except the user's UPN.

This feature of ADFS 2019 is poorly thought out (the code is rotten and closed ...), or well oriented to encourage you to switch to AAD ... hope that in the next version of ADFS things will be reviewed by Microsoft.

One configuration I can tell you, if you have an AAD tenant, is to enable "device registration" and sync writeback with ADConnect. you can then do without passwords: registerd devices in primary and MFA in secondary

Our next project will certainly be a device registration system, compatible with ADFS 2016 and more....

regards