Now in Public Preview: Duo's Microsoft Entra ID EAM Integration

[kyleleighavery]

Now in public preview: Duo integration with Microsoft Entra ID External Authentication Methods (EAM)

• Duo integrates with Microsoft Entra ID as an external authentication method to add two-factor authentication to Entra ID logons, offering inline user enrollment, self-service device management, and support for a variety of authentication methods — such as passkeys and security keys, Duo Push, or Verified Duo Push — in the Universal Prompt.
• See step-by-step instructions for administrators in Duo’s Two-Factor Authentication for Microsoft Entra ID EAM documentation.
• This new Entra ID External Authentication Methods integration will eventually replace the Duo Two-Factor Authentication for Microsoft Entra ID integration, but both options are available for the time being.
• Learn more about Duo partnering with Microsoft in Duo’s recent blog post.

[kkraft]

Curious if anyone has gotten this to work. I've followed the documentation and can make it work for new users, but if I'm migrating an existing user from the prior CA policy to the new EAM policy, it's not working and fails on the MFA.

I reached out to my Microsoft consultants who don't believe it's related to the config on the Entra side, so I'm wondering if anyone got this working what they had to do to move existing users to the EAM policy?

[nlev]

It's working but we did have some timing issues when migrating someone over to the new policy. It seems the new EAM option didn't show up right away and they might have to try logging in several times before it shows up. Seems a bit glitchy, but it does work eventually.

[DuoKristina]

I remember a similar experience as @nlev  when I tested this (before release) with an existing user that previously I had assigned a policy requiring the Duo CA custom control instead.. I thought I made a mistake with the policy config, because the user was still getting sent to the CA control after I applied all changes. I got busy with other things, and then tried it again later and the new EAM method for Duo showed up instead of the custom control flow.

[nlev]

Good to know I'm not alone. There were reports of similar issues on the microsoft blog post comments as well here Public preview: External authentication methods in Microsoft Entra ID - Microsoft Community Hub

We tried to switch everyone over to EAM but had to panic revert the change because too many people were encountering that issue. Maybe if we wait a bit longer next time and have people retry they will eventually get through the login. Not a great user experience, but hopefully we can get through it and eliminate the old custom control.

[landyn]

Hi @kkraft! As @nlev mentioned, it could be propagation time for the configuration change, but it's hard to know for sure based on your description of the problem of "fails on the MFA". I would make sure to give the change 5-10 minutes to apply and then test again.

It's worth mentioning, as this could possibly be your issue, that EAM is different from the prior integration to allow the MFA claim to be established in Azure / Entra. Microsoft requires a valid authentication method to be used in order to establish MFA. For this reason, any type of policy that is applied that would bypass MFA will not work with the EAM integration. This includes the new user policy, authentication policy, user location, and authorized networks policy. If any of these policies are configured to bypass users, EAM will not work and the authentication will fail as Duo has no valid authentication method to send to Microsoft that would establish an MFA claim.

If the issue is not resolved after reviewing this, please take a screenshot of the error encountered, noting the URL the browser is navigated to at the time of the error. We'll also want the integration key / client ID for your EAM application, as well as usernames and timestamps. With this information in hand, I would recommend contacting support so they can assist you further with this! Thanks for reaching out!

[DarkLordTyler]

We have deployed this for around 5 customer environments (Around 200 users) without any significant issues.

The main things to triple-check would be:

• MFA Registration Policy is set to exclude your group tied to the CA policy in Entra ID
• Duo EAM is the only Enabled application for the group tied to the CA policy and the group is excluded for every other method.
  • In our environments, Guest Users would still be allowed to use MS Authenticator for Guest Access.
• Removing your user group tied to the Duo Application and CA in Entra ID for the previous Auth Method once the new EAM Policy and Application is turned on.
• Android seems to be a bit buggy with EAM, and we have had to delete a few authenticators tied to android devices and allowed the users to enrolle.
• Deleting any MFA methods registered to the users account in Entra ID
• Having the User remove MS Authenticator from their devices if previously used.
• Set your previous CA policy to Disabled in Entra ID, remove your Group(s) from the Application in Duo and/or delete the non EAM application all together.

[nlev]

Thanks for the tips. Can you clarify a couple things?

What's "MFA Registration policy"? I see "Registration Campaign" in Entra and I have this set to disabled. Is that correct or is there some other setting I should be looking for?

Do these settings look right? Passkey is only enabled for the admins group as a backup if EAM fails. Email OTP has all users excluded except external is set to "Default". All other options are disabled.

We're going to try the deployment again this weekend. Hopefully we don't run into the issue again where users aren't presented with any authentication methods and are unable to log in.

[DarkLordTyler]

Yes, the Identity Protection - "Multifactor authentication registration policy"

Make sure that you exclude your Duo Users group. I would keep this on for all users as it applies to MFA for guest accounts, e.g., Sharing through SharepointOnline or Teams. unless guest accounts are also authenticated through Duo, which is not the case in our environments.

Under Authentication Methods, you can enable whatever you need, just be sure to only enable for a set group or exclude the Duo User's group from the policy. In most tenants, we have many methods tied to facilitating various B2B customers requirements and have not had issues.

Under Authentication Methods -> Settings -> System-preferred multifactor authentication, leave this enabled but exclude the Duo users group.

For any problem users (ideally ALL users) make sure any MFA method registered in Entra ID is removed, other than Windows Hello, if that is enabled for device sign-on via an Intune or other policy. We found that even if you exclude users from the System-Preferred policy, if a Native Entra ID MFA method is registered there may still be a system preferred method under "default sign-in method" set on their account until the method is removed. This was not consistent behavior for all accounts, but cleaning up the information on the accounts has seemed to work well, and also just a good best practice. If you have Windows Hello enabled it is likely that users were forced to register an MS Authenticator to manage at some point. EAM cleans this process up.

You should be able to test this with a handful of users before going all-in. Good luck!

Example Authentication Methods from working user account in Entra ID:

[nlev]

Thanks for the clarification. The "Multifactor authentication registration policy" is set to "Policy enforcement" "Disabled" in our environment, so hopefully that works.

For "System-preferred multifactor authentication" I have this disabled so hopefully that's the same as excluding the group. I don't want to use a group and instead apply DUO to all users.

We did test for a subset of users and everything was fine. It was only when we enabled for all users that the problems began. If any users have problems after we enable it again, I'll check the authentication methods on their account. Hopefully we can get through the problems without having to fully revert again.

Here's one of the problem users and sure enough they did enroll in microsoft authenticator at some point but it shows disabled now. I see it defaults to SMS which is also disabled but it doesn't allow me to change to no-default. I fear this user will have problems again if we enable DUO EAM.

[DarkLordTyler]

For the "no-default" to be set, you have to delete the methods set on the account. This includes deleting any methods that show as disabled. If they are already using the legacy Duo integration, that shouldn't be an issue, but obviously, proceed with caution. 

Once you delete those, the primary field on their account should be updated; at least, it has for us.

I don't know of a way to purge all these from accounts in bulk, but I guess that this is the issue you are facing if all the other settings are correct and some users are not having issues.

Hopefully,, as the service moves out of preview, Duo will be able to communicate back to Entra ID that a user is successfully enrolled, and that method will show up on their account under Authentication methods.

[kkraft]

This is all great information, thank you!

I did go back and remove the default method from my test user as @DarkLordTyler recommended above. I had to switch to the 'old' view and remove the phone number from the account. When I switched back to the 'new' view, it was set to 'no-default'.  I also exempted my EAM group from our existing SMS and Phone Call method policies (we use these for contractor accounts) and the CA policy setup to use the legacy DUO config.

Some combination of all of these seems to have worked and my test user is now getting the correct prompt.

I'm now testing on another user (my Help Desk guy, sorry m8) and if that's successful, I'll do a broader implementation.

Thanks for all the information this thread has been very helpful!

[msmorris]

Good day. Is there any idea on when EAM for DUO will be available in GCCH tenants. I did see the option to add external method is in preview within Microsoft Entra in my GCCH tenant, however following the DUO instructions does not provide an option to specify the cloud instance while creating the DUO Entra ID application. Any information would be appreciated.

[landyn]

Hi @msmorris ! We do not yet have an expected timeline for EAM in GCCH, but it is on our radar for sure. Please feel free to send me a message with your organization name and email address so I can hold onto your contact information and include you in a preview when it comes available.

[Glitch66]

For all of those asking -- Currently Microsoft does not support making an EAM, like Duo, as the default (system-preferred) MFA option.  It's only supported today as a backup option for users.  It says on the KB that they're "actively working" on it, but I'd love to know if that means weeks or months away.  https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-external-method-manage#user-experience

This alone is a show stopper for us, and I expect for most Duo customers looking to migrate to EAM.

[DarkLordTyler]

@Glitch66 I am Interested to hear why this is a deal breaker for you and if you have scenarios where users are potentially using Entra ID registered authenticators for particular CA policies, apps, or workflows, such as device registration. The system default method should only cause issues if the user can or has already registered other methods. While I agree that being able to set the system default will improve the overall migration and user experience, our use of EAM so far suggests that if users have authenticators registered in Entra ID, you are likely to find issues with EAM as well as the legacy Duo integration, regardless of the system default setting.