I have a few clients (not many) who have external federation for Entra ID (previously Azure Active Directory) and over the last year or so have been looking into these and integrating them with Entra ID Conditional Access. This has become more of an issue recently with Microsoft’s recently creation of “Microsoft Managed” Conditional Access rules that will require an Multi-Factor Authentication (MFA) based login.
Examples of external federation in place include Duo Federation, Okta and AD FS. The first two of these includes their own MFA solution that can be easily turned on, for example in Okta you can create an “org-level” or “app-level” (on the M365 App) MFA policy. Active Directory Federation Services (AD FS) does not come with a native MFA solution, but Duo or Entra ID can be added here by way of a software add-in.
And the above is all relatively easy, but if you start to drill down into the Entra ID sign-in logs you may see that Entra sees these logins showing “Single-factor authentication” for the Authentication requirement column in Entra ID even though the user has been routed through the external federation platform and performed an MFA prompt.
For each of the users in the above, they have all been routed through Duo and Duo has performed both the end user authentication and second factor of authentication and then returned a token to Entra ID. This token includes the claim that MFA was performed – but Entra ID is ignoring it and showing single-factor for authentication.
Note that this is NOT using third-party controls for Entra ID – that is not external federation and so third party controls will show single-factor and at this time cannot be “upgraded” to multi-factor authentication.
For some of these login session though, looking at the details of the login shows that the “MFA requirement satisfied by claim provided by external provider”:
Not every sign-in event on the tenant I was looking at for this blog post was showing “MFA requirement satisfied by claim provided by external provider” and this was due to the configuration in Duo – there was a requirement for MFA for Microsoft Teams but not for other applications.
To get your external federation provider to send the MFA claim back to Entra ID, the federation configuration in Entra ID needed to have the SupportsMFA setting set to True. This is found in MSOLService PowerShell (which is soon to be depreciated, so this will move to MSGraph PowerShell I suspect)
Get-MsolDomainFederationSettings -DomainName <yourDomainName>
You are looking for the SupportsMFA setting. If this is NOT set to True, then use the following to update the external federation settings, and repeat this per federated domain. There is no end user impact to this (assuming you have no conditional access rules that would be impacted by turning on MFA), but all future logins will show if MFA was done at the external federation provider.
Set-MsolDomainFederationSettings -DomainName <yourDomainName> -SupportsMfa $true
On doing this there will be no change in the Entra ID sign-in logs. But now you can start to require Multi-Factor Authentication or the “Multifactor authentication” authentication strength setting. You could use a custom authentication strength as long as it included the “Federated Multifactor” option.
Once you create a Conditional Access rule that applies to all cloud apps and requires MFA (as above, either the MFA or authentication strength options) then from the next login for the user, “Multifactor Authentication” will appear in the sign-in logs and the user will be passing your Conditional Access rule:
Its important to note here, that the user is passing the Conditional Access rule for MFA required, but is not being prompted for Azure MFA. They are doing and completing MFA in the external federation provider even though Entra ID requires MFA it is not requiring its own MFA. It is trusting the claim in the token provided by the external federation provider.
It is also worth pointing out that though Entra ID is trusting what the external federation provider says in their token, there is nothing to actually say that what is in the token in correct. For example in both Duo and Otka you can require MFA at the org or app level and then also bypass it based on device or IP address. In these cases, both Duo and Okta still include MFA in the token they send to Entra ID and Entra ID trusts it even though you might have a bypass MFA for corporate network policy in the federation platform!
Don’t do this – always have MFA and no exceptions – and move away from federation platforms that in effect do not pass on the correct state of affairs to Entra ID – claiming they have done MFA when they have actually bypassed it.
Finally two links to the documentation for both Okta and Duo. These both discuss the above, but miss out useful information:
- Duo Federation and SupportsMFA and Entra ID Conditional Access rules – this document says that you just need SupportsMFA=$true, but this is not true. The Sign-In logs will not show that you are using Multi-factor authentication until you have a Conditional Access rule that requires MFA.
- Okta and infinite loops for login – where Conditional Access requires MFA but SupportsMFA is false and Okta does not require MFA. Or you login to Okta and complete MFA, but later access Microsoft 365 via Okta. Okta sees that it did an org level MFA but does not pass the MFA claim on the second app level login.
Photo by BOOM 💥: https://www.pexels.com/photo/people-passing-a-baton-12585936/
Leave a Reply