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.

[Glitch66]

@DarkLordTyler  Today we use Conditional Access Policies to integrate Duo with Entra AD SSO.  We also use Entra AD's Self Service Password Reset (SSPR) which required users to enroll authentication methods that are then used to verify their identity when they go to use SSPR.  Entra AD has since merged Password Reset and MFA authentication methods, especially if you want to use EAM, so users are prompted to pick an insecure option that should be reserved for Password Reset (which requires 2 methods not just 1 like MFA) and only if you click "Let me do something else" do you see Duo as an option.

So we need to be able to do Duo EAM as the default/only MFA option while still supporting the other methods like SMS/Voice and Email OTP for password reset only.

Interesting you bring this up, because we're currently in the "Migration in Progress" part of the Authentication Methods migration.  I have the "new" authentication methods policy set to only Duo is allowed for authentication and the rest is for password reset only, but because "Migration in Progress" respects legacy policies I expect that's why I have SMS and others as an authentication method.  I wonder if I switched to "Migration Complete" would I then use Duo by default?  I assumed not because of the note in that MS KB about EAM but you're saying that's not true if it's the only MFA option?  Migration settings for Authentication Methods is all or nothing, I can't test it ahead of time so I've been reluctant to push for it.

[nlev]

@Glitch66 Microsoft says system preferred will be added "in the near future" https://youtu.be/kl1YWCEnGcM?t=1270

[Glitch66]

@DarkLordTylerI tried shutting off the legacy authentication methods so only the new methods would apply, but it broke guest access.  Duo was also still not the default option, but at least nothing else was either.

New Authentication Method Policy doesn't appear to let me target Guest accounts that would allow me to give them authentication methods like Microsoft Authenticator that I don't want to allow for employees who use Duo.

@nlevYes I'm aware of that, it's in the KB I linked.  I asked a Microsoft Security Specialist they said "expect to be available in the coming months".

I'm not seeing how EAM is possibly ready for prime time yet, but that's all on Microsoft.

[DarkLordTyler]

@Glitch66 submit a request to Duo about getting Self Service Password Reset as a specific application that can have a unique policy applied. I took a look at SSPR yesterday, and if you are requiring two options, I don't see how you could get around not having one of them Entra ID managed unless you use EAM and Security Questions. This was why I followed up on your answer because we made a similar request for a unique application policy for Intune Enrollment. To my Knowledge Duo doesn't have a way to require 2 authentication methods as part of an authentication request or policy. Perhaps there could be a way for Duo to flag anything coming from the SSPR application as Risky and require the elevated methods, but I don't work for Duo.

Your guest user issue is tied to your CA policies and Authentication method policies. Since EAM is now an authentication method, it's not the issue; the configuration and assignment of those policies are. If use of Duo is not bound to a specific user group that may be harder to manage all the policy setting requirements. 

Here's an example of a configuration that is currently working fine for us with EAM for internal and Entra ID methods for guests. Good luck!

Duo EAM Authenticator settings:

MS Authenticator Settings

[DuoKristina]

> submit a request to Duo about getting Self Service Password Reset as a specific application that can have a unique policy applied.

This seems like something you can already do yourselves if SSPR supports EAM external methods, just by creating a second EAM application in Duo for SSPR and then in Entra adding that via CA as the EAM method for SSPR? I am assuming you can add external methods to SSPR but didn't actually check. If you still can't add external methods to SSPR application in Entra, that would be on Microsoft.

ETA: I did just look in Password Reset > Authentication methods and MS hasn't added EAM there as an option yet?

[nlev]

I don't think Microsoft offers SSPR with EAM yet, but hopefully soon https://www.youtube.com/watch?v=kl1YWCEnGcM&t=1733s 

[Adminnnn]

Stumbled upon this thread attempting to roll out Duo's EAM to my tenant and running into some issues. 1. My user continues to be prompted to setup Microsoft Authenticator + SMS after following the Duo KB on this. I configure Microsoft Authenticator by scanning a QR code, then setting my SMS, I then close the browser, log back in and I am again asked to setup both methods as if I never have. This happens every time. Never do I get redirected to Duo. I ran through all the settings in the KB, even did the same with support. Not sure how this works with the Enterprise App that is created, or any logs I could look into to find out what is going on. 2. I was thinking SSPR was going to be a problem, sounds like it might be based off of some of the discussions on this thread. I would want to use 2 authentication methods as well, Duo Push + Security Questions or Alternative email.

[landyn]

@Adminnnn - a number of things could be happening here. If you want to force Duo, you'll want to ensure the EAM is the only method allowed for the user group you are using in authentication methods in your Azure portal. For Duo, there is no registration required with Microsoft to be able to start using the method. As soon as the method is enabled and scoped to the user and they encounter a conditional access policy with the "Require Multifactor authentication" requirement enabled, the user should see the Duo EAM as one of their options during authentication. If you aren't able to sort this out, please reach out to our support team so they can assist you further!

[Adminnnn]

Trust me as much as I didn't want to, I tried your support. Unfortunately, outside of the KB article no one has a clue of how to actually troubleshoot this. If it doesn't work (which is my case) they say I need to call Microsoft. Try calling Microsoft and tell them you have an issue with a 3rd party application. Try 10x and let me know the answer you get from each person; I am willing to bet anything I could predict the outcome I know where the break is, for whatever reason Microsoft is not seeing Duo EAM as a valid option and continues to kick me into this loop of setting up some sort of authentication which is Microsoft. Not knowing the details of how EAM works with Duo makes this impossible for me to fix. Was hoping your support had a clue, as expected they didn't. I am going to stay away from this because if this broke my test tenant, I could only imagine what it does to a tenant in production, no thanks!

[DarkLordTyler]

@Adminnnn If you have read through the previous responses to this thread, I think the setup and known issues are pretty straightforward.

The forced registration is likely tied to either the incorrect configuration of MFA Registration and Authenticator policies alongside the EAM policy requirements or the enablement of SSPR. Because EAM is not allowed as an SSPR method, if you need SSPR and still want to use Duo EAM for primary authentication, you must run it with the MS authentication methods alongside EAM  or wait until EAM is an approved SSPR method to migrate your tenant over to EAM.

The legacy Duo integration method was also not SSPR approved, so it's really about tweaking your Authenticator policies to accommodate both EAM and the use of SSPR and understanding that with a registered MS Authenticator for SSPR purposes, that authenticator will take precedence over EAM because MS also doesn't allow EAM to be set as the default or priority authentication method.

Good Luck!

[George D]

Interested to see if Microsoft provides a way to make a specific EAM a default option on the second sign in page so there is no need for a second click

[Timmck]

Same issue here with SSPR, if I remove myself from SSPR group and remove my other Authenticator and SMS methods, I am presented only with EAM as a default option. As soon as I re-enable SSPR, it prompts me to re-enroll Authenticator and SMS methods and back to where I was where Authenticator is the default option. 

According to Microsoft, "We're actively working to support system-preferred MFA with EAMs." 

https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-external-method-manage

We're just going to have to postpone MFA enforcement until March 15, 2025, continue using CA method and hope EAM is ready for system-preferred because we're not going to disable SSPR. 

[JMLBO]

Can I clarify that the behaviour we're seeing in our testing is the current behaviour of an EAM in EntraID.

We have Duo added as an EAM in EntraID. We have a CA policy that requires Multifactor Authentication. When I sign in, I see the Duo EAM option but I have to explicitly click the Duo EAM in order to go through MFA via this method. With the existing configuration during sign in, EntraID hands off to Duo which automatically generates the push for approval, this is the behaviour we want to keep and I'm unsure if I've missed something somewhere or if the Microsoft "We're actively working to support system-preferred MFA with EAMs." statement means it is supposed to be coming at some point.

Hopefully the above makes sense. 

[landyn]

@JMLBO this behavior is unfortunately expected. Microsoft's justification is that they want the user to explicitly choose it. I agree with this if the user has multiple options within Entra ID login, but have asked Microsoft for an adjustment to this behavior when the Duo EAM is the only option available for the end-user. It would make sense to just automatically redirect in that case. We have not received a commitment on any changes here, so please direct your feedback on this current behavior to Microsoft.

[gvarga]

Thanks for that information @landyn ,we will have to continue to use the custom controls configuration until MS can deliver:

1. System-preferred EAM to select Duo EAM first, even if the user has MS Authenticator enrolled. Currently, if a user has MS Authenticator enrolled on their account, it will automatically choose that. Since we do not officially tell users to use MS Authenticator this will just cause too much confusion.

2. We can probably live with the prompt to select the Duo EAM, but obviously automatically redirecting would be ideal. 

I suggest if you aren't already, enrolling in the Microsoft Entra Advisors Community to make your voices heard.

https://forms.office.com/Pages/ResponsePage.aspx?id=v4j5cvGGr0GRqy180BHbR5n91RGSMY5MoMjm9pNflCtUQzg0TURST0NaTlhWTkxZQ1ZEV1MzQkJCMiQlQCN0PWcu