Bug: Microsoft EAM Sign-Ins Fail with PUSH and Symbol2Accept Methods

Follow
    Applies to:
  • SecureAuth Identity Platform
Deployment model:
  • Cloud
  • Hybrid
  • On Premises
  • Version Affected: 22.12 and later
    Bug Number: Not provided in source
    Bug Status: Closed - Fixed
    Fixed in Version(s): 24.04 RU3+

     

    Overview

    When SecureAuth Identity Platform is configured as a Microsoft Entra External Authentication Method (EAM), sign-ins using the Push or Symbol2Accept MFA methods fail with the following error from Entra ID:

    AADSTS5001256: Failed to complete authentication with external provider due to invalid id_token. Failure details: missing required 'acr' claim.

     

    Cause

    Debug logs show one of the following messages:

    Message="[TokenService].[AttachAmrAcr] Current registration Method is.PUSHACCEPT"

    or

    Message="[TokenService].[AttachAmrAcr] Current registration Method is.SYMBOL2ACCEPT"
    Message="[TokenService].[AttachAmrAcr] Registration method: pushaccept doesn't map to a supported amr value password, sms, call, email, help_desk, push, push_accept, push_accept_symbol, push_accept_biometric, oath, yubikey, sms_link, email_link,

    The registration methods PUSHACCEPT and SYMBOL2ACCEPT did not map to a supported Authentication Methods Reference (AMR) value — specifically not to push_accept or push_accept_symbol — so these methods never got populated in the token's AMR claim, and Entra ID rejected the token for missing the required acr claim.

     

    Resolution / Workaround

    Upgrade to 24.04 RU3 or later. This release adds swk (software key) as a supported AMR value and maps both PUSHACCEPT and SYMBOL2ACCEPT to it, so the token's AMR claim is populated correctly and Entra ID accepts it.

    Sample token when the PUSHACCEPT or SYMBOL2ACCEPT method is used: Id_token

     

    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.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.