Last month, Microsoft introduced a new setting in Azure AD to protect against by-passing of Azure MFA for organizations who have federated between Azure AD and their on-premises environment.

In most cases, organizations who have federated one or more DNS domains with Microsoft 365 (and thus Azure AD) use AD FS to host the ‘Microsoft Office 365 Identity Platform’ relying party trust. So, I’ll stick with this setup to explain what the new setting does, how it coexists with an existing setting that promised to do the same, and how to configure it.

About Federation with Azure AD

Microsoft offers three ways to provide single sign-on for end-users between Active Directory and Azure AD:

• Password Hash Synchronization (PHS) with either Seamless Single Sign-on or (Hybrid) Azure AD-joined devices
• Pass-through Authentication (PTA) with either Seamless Single Sign-on or (Hybrid) Azure AD-joined devices
• Federation

When federating, end-users who access Microsoft 365 services, Azure AD-integrated apps, services, and systems and Azure AD itself, are redirected by Azure AD to authenticate with a federation solution that is hosted, owned, and operated by the organization.

Azure AD Connect, Microsoft’s free tool to setup these configurations, supports AD FS and PingFederate as federation solutions.

Dangers when federating

All three models have their pros and cons. Federation solutions typically have the following cons, that can be translated into identity protection dangers:

• The federation solution is typically hosted, owned and operated by the organization. Monitoring, continuity, security, governance and reporting processes are dictated by the size and maturity of the organization. Not all organizations have the maturity to managed federation solutions well.
• Federation solutions typically require specialist knowledge and experience to implement, maintain, migrate and decommission. When this knowledge and/or experience is absent, the federation solution may provide an attack vector to attackers to gain access to the on-premises environment(s) and/or the cloud environment(s).
• When using federation (without PHS as additional measure) Azure AD Identity Protection cannot detect password leaks in breaches where the organization’s end-users’ credentials are leaked.
• When using federation, the organization is in full control of the end-user’s authentication. When the federation solution offers multi-factor authentication and passes the corresponding claims in the claims token for the end-user, Azure AD trusts that multi-factor authentication was performed. The claims may be forged. That’s why multi-factor authentication claims that originate on-premises are not trusted for all purposes (e.g. Azure AD B2B).

In short: When an attacker achieves persistence within the on-premises environment(s), the federation solution offers a way to compromize the cloud environment(s), too.

About the new federatedIdpMfaBehavior setting

With this danger in mind, Microsoft introduced a new security protection that prevents bypassing of the cloud-based Azure AD Multi-Factor Authentication, when federated with Azure AD.

When this new federatedIdpMfaBehavior setting is enabled for a federated DNS domain name in the Azure AD tenant, it ensures that a compromised federated account can't bypass Azure AD Multi-Factor Authentication by imitating that a multi-factor authentication has already been performed by the federation solution.

Microsoft highly recommends enabling this new protection when using Azure AD Multi-Factor Authentication as the multi factor authentication solution for your federated users. However, it may lead to confusing for admins who manage federation solutions with multi-factor authentication capabilities.

About the SupportsMFA setting

Previously, admins in federated setups could use the SupportsMFA setting to determine the way their AD FS MFA Adapter was used (or not) towards Azure AD. When the SupportsMFA setting is set, it indicates to Azure AD that the federation solution supports multi-factor authentication. In other words: it tells Azure AD that the AD FS farm is configured with an MFA adapter.

The two settings interact in the following way:

Configuring the federatedIdpMfaBehavior setting

Whether you should configure the new federatedIdpMfaBehavior setting depends on the organization’s approach:

Security-driven approach

When the organization does not have an MFA Adapter configured within AD FS, configure the federatedIdpMfaBehavior setting as rejectMfaByFederatedIdP. In the future, this setting prevents Azure AD from attackers when they send multi-factor authentication claims from accepting these claims.

Policy-driven approach

When your organization’s policy is to rely completely on the MFA Adapter in AD FS, configure the federatedIdpMfaBehavior setting as enforceMfaByFederatedIdP.

Note:
Make sure the organization has mature monitoring, continuity, security, governance and reporting processes in place. A good indicator is when the federation service’s certificates are hardware-backed.

User Experience-driven approach

When your organization’s desire is to provide all end-users with the same multi-factor experience, make sure to configure the federatedIdpMfaBehavior setting as either enforceMfaByFederatedIdP or rejectMfaByFederatedIdP.

If you have configured the SupportsMFA setting, make sure to choose  enforceMfaByFederatedIdP as the organization probably already secured other federated applications, services and/or systems with the MFA Adapter in AD FS.

Breach-driven approach

When your organization’s policy is to rely on the MFA Adapter in AD FS, but the on-premises environment is breached, you can (temporarily) configure the federatedIdpMfaBehavior setting as rejectMfaByFederatedIdP.

Watch out!
The Nobelium cybercrime group and other attackers have demonstrated that they already exploit AD FS for issuing claim tokens that signal that multi-factor authentication has been successfully performed.

How to configure federatedIdpMfaBehavior

To configure the federatedIdpMfaBehavior setting, perform these steps:

Get the latest version of the Microsoft graph SDK

If you haven’t done so already, install the Microsoft Graph SDK in an elevated PowerShell window:

Install-Module Microsoft.Graph

Type Y twice.

If you’ve worked with the Microsoft Graph SDK before and want to update it to the latest version, issue the following line of PowerShell in an elevated PowerShell window:

Update-Module Microsoft.Graph

Import the Microsoft Graph SDK with the right permissions

On a system with the Microsoft Graph SDK installed, run the following lines of PowerShell:

Import-Module Microsoft.Graph

Connect-MgGraph -scopes Domain.ReadWrite.All

Sign in with an account in Azure AD that has the Global administrator, Hybrid Identity administrator, Domain Name administrator or Partner Tier2 Support built-in role assigned.

Perform multi-factor authentication when prompted.

If the Enterprise Application for Microsoft Graph PowerShell wasn’t created earlier or wasn’t created earlier with Domain.ReadWrite.All permissions, the Permissions requested screen is shown:

Click Accept to continue.

Get the current federatedIdpMfaBehavior setting

Get the current federatedIdpMfaBehavior setting for a federated DNS domain by running the following line of PowerShell:

Get-MgDomainFederationConfiguration -DomainID domain.tld

Replace domain.tld with the DNS domain name of a DNS domain that is verified and federated with Azure AD.

Set the federatedIdpMfaBehavior setting

Set the value for the federatedIdpMfaBehavior setting, depending on the scenario:

acceptIfMfaDoneByFederatedIdP

To set the acceptIfMfaDoneByFederatedIdP value for the federatedIdpMfaBehavior setting for a federated DNS domain by running the following line of PowerShell:

Update-MgDomainFederationConfiguration -DomainID domain.tld -FederatedIdpMfaBehavior acceptIfMfaDoneByFederatedIdp

Replace domain.tld with the DNS domain name of a DNS domain that is verified and federated with Azure AD.

enforceMfaByFederatedIdp

To set the enforceMfaByFederatedIdp value for the federatedIdpMfaBehavior setting for a federated DNS domain by running the following line of PowerShell:

Update-MgDomainFederationConfiguration -DomainID domain.tld -FederatedIdpMfaBehavior enforceMfaByFederatedIdp

Replace domain.tld with the DNS domain name of a DNS domain that is verified and federated with Azure AD.

rejectMfaByFederatedIdp

To set the rejectMfaByFederatedIdp value for the federatedIdpMfaBehavior setting for a federated DNS domain by running the following line of PowerShell:

Update-MgDomainFederationConfiguration -DomainID domain.tld -FederatedIdpMfaBehavior rejectMfaByFederatedIdp

Replace domain.tld with the DNS domain name of a DNS domain that is verified and federated with Azure AD.

Concluding

The federatedIdpMfaBehavior setting is an evolved version of the SupportsMfa property for federated DNS domain names in Azure AD. Use it to your advantage.