How To: Add the authnmethodsreferences Claim in WS-Fed/SAML to Avoid Double MFA with Microsoft 365

Version Affected: All

 

Overview

This article explains how to work around double Multi-Factor Authentication (MFA) prompts for Microsoft 365 (M365) users, by adding an authnmethodsreferences (AMR) claim to a WS-Fed or SAML realm. Microsoft requires all administrators to use MFA when signing in to key management portals, including the Microsoft Azure portal, the Microsoft Entra admin center, and the Microsoft Intune admin center. The AMR claim is not supported by SecureAuth Identity Platform (SAIDP) in WS-Fed or SAML realms — only in OIDC realms — and since M365 integration is done via WS-Fed, this can lead to double MFA prompts when SAIDP is also configured to prompt for MFA.

Add the AMR Claim in a WS-Fed or SAML Realm

1. Configure SAIDP to always require MFA.
2. Configure the authnmethodsreferences claim on the realm's Post Authentication tab, as Attribute 3: Name set to authnmethodsreferences, Friendly Name set to Authentication Method References, Namespace (1.1) set to http://schemas.microsoft.com/claims/authnmethodsreferences, Format set to URI, Value set to Global Aux ID 2, and Group Filter Expression set to .*.
3. On the Data tab, set Global Aux ID 2 to http://schemas.microsoft.com/claims/multipleauthn.

With this configuration, the resulting claim in the SAML token looks like this:

<saml:Attribute AttributeName="authnmethodsreferences"
   AttributeNamespace="http://schemas.microsoft.com/claims">
   <saml:AttributeValue>http://schemas.microsoft.com/claims/multipleauthn</saml:AttributeValue>
</saml:Attribute>

By reading this claim, Microsoft Entra ID recognizes that the user has already completed MFA, and does not prompt them to complete MFA again.

SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.