SAML error: Authentication method 'X509, MultiFactor, X509Device' by which the user authenticated with the service doesn't match requested authentication method 'Password'

Products

• Automic Automation

Issue/Introduction

When setting up SAML for Azure, the following error is present when trying to log in:

'Authentication method 'X509, MultiFactor, X509Device' by which the user authenticated with the service doesn't match requested authentication method 'Password' '

Environment

Automation Engine 24.X and superior 

Cause

Configuration:

This error (AADSTS75011) never reaches the Automation Engine - it's Azure AD itself refusing to complete sign-in, before any SAML Response is even generated. There is a mismatch between the authentication method AE requested and the one the user actually used.

What's happening:

Authentication method 'X509, MultiFactor, X509Device' by which the user authenticated with the service doesn't match requested authentication method 'Password'.

The Automation Engine's *CONFIG key sends a RequestedAuthnContext in the SAML AuthnRequest.

When this element isn't disabled and authnContextClassRef is left empty, Automation Engine defaults to requesting urn:oasis:names:tc:SAML:2.0:ac:classes:Password - i.e. it's telling Azure "the user must authenticate with a plain password."

But this user is authenticating via certificate-based auth / Windows Hello / device cert + MFA (X509, MultiFactor, X509Device) - almost certainly enforced by a Conditional Access policy on the tenant. Azure sees the actual method doesn't satisfy the requested one and blocks it outright.

Resolution

1. In UC_SAML_SETTINGS of Client 0, open the *CONFIG key (not *SP).

2. Check/set:

<disableRequestedAuthnContext>true</disableRequestedAuthnContext>

Default is false - if it's missing or still false, that is the root cause.

3. Save. No restart required.

4. Retry login - AE will no longer send a RequestedAuthnContext element at all, so Azure won't try to match the user's actual (stronger) auth method against anything, and MFA/cert-based sign-in will be accepted normally.

If this does not resolve the issue, set up a trace with TCP/IP=5, DB=4, collect logs and traces, and open a case with Broadcom Support.