One might encounter the following error:
AADSTS750: Authentication method “WindowsIntegrated, MultiFactor” by which the user authenticated with the service doesn’t match requested authentication method “Password, ProtectedTransport”
Our Azure SSO Integration Guide (under FAQ) has an in-depth technical description of why this occurs. Understanding the underlying mechanics of this, so that we could come up with an adequate explanation, took some reading into the SAML 2.0 Protocol Core Specification as well as the Azure SAML Protocol documentation. However, I must confess, when I went back to read what I had helped write way back then, it actually took me a few read-throughs to understand the underlying meaning.
So, this time around, I thought I’d have a bit of fun coming up with a more illustrative description of how it all happens. For the layperson, it may help to imagine the following brief dialogue that transpires, which leads to the error message:
User: “I want to sign in. Take me to my identity provider (IDP).”
PD (to user): “Okay, take this note (authentication request) to your IDP, which is over this way.”
PD (note to IDP reads): “This person wants to sign in to me. Their authentication method must EXACTLY match the minimum one that I typically require - and this exactness is as you have demanded that I require of users. The minimum that I ask is that the identity provider make their users provide a password (one authentication factor) per what I say here in my
User’s web browser: “Here’s an authentication request. I have
WindowsIntegrated and want to use that to authenticate.”
AD: (reads note) “Okay user, you say want to sign in using
WindowsIntegrated? TOO BAD, THAT METHOD IS NOT ALLOWED! IT MUST BE A PASSWORD AND ONLY A PASSWORD.”
PD (aside): But wait a minute AD, you yourself don’t even support
WindowsIntegrated when specifying a
RequestedAuthnContext element per your documentation*! The only way I could get around this is by the footgun of not requesting a minimum of authentication requirements, thus permitting disastrously insecure SAML configurations wherein no authentication method is required by the identity provider!
* Per the FAQ:
- PagerDuty includes the
RequestedAuthnContextelement to request that the identity provider use, at the bare minimum, password authentication to identify users.
- Azure expects the service provider require an exact match between the authentication type provided with the one requested, whenever
- Azure only supports requesting
Passwordtype authentication when specifying
Users can get around this issue by using a different web browser that does not attempt to authenticate with the identity provider via the
WindowsIntegratedauthentication method, and using password authentication to access their identity.