Microsoft Entra Suite Tech Accelerator
Aug 14 2024, 07:00 AM - 09:30 AM (PDT)
Microsoft Tech Community

AADSTS75011 by which the user authenticated with the service doesn't match requested authentication

Copper Contributor

We're experiencing problems with a certain application that we've registred in Azure.

Sorry, but we're having trouble signing you in.  We received a bad request.

AADSTS75011 by which the user authenticated with the service doesn't match requested authentication method 'Password Protected transport'



  • user logs in (Citrix-environment)
  • IE11 is auto-started. Default startpage = our intranet on SharePoint Online
    (at this moment SSO kicks in and the user will be logged in automatically in / SharePoint Online)
  • User starts new tab in IE11, navigates to the application's login-url (external SaaS application) and poof; the error shows up
  • When user starts Chrome at this moment and navigates to the application's login-url again, he WILL be logged in automatically.

The software-developer says it has something to do with our Azure settings or Windows environment, but we have a lot more applications registred the same way where this error never occurs.

Does anyone have a clue on how to fix this?
It looks like the SaaS application does not accept Windows Integrated authentication?

9 Replies

Hello Josse,


The error message that you are getting is because the authentication request sent by the application is not accepted by azure AD.


Note :- "PasswordProtectedTransport" is a parameter which is included when the authentication request is sent to the IDP using SAML.


Below mentioned is an example of sample saml auth request, 









Check it from the rfc of saml -


The purpose of this parameter is prompt user to enter credentials even if sso is enabled in the enterprise.


Now I am not really sure what is happening with this request, if you look closely there is a ","

between password and protected transport.


Also below mentioned is a sample saml request that should be sent to azure ad - 


Version="2.0" IssueInstant="2013-03-18T03:28:54.1839884Z"
<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion"></Issuer>


Also please refer to the article mentioned above :- 



The RequestedAuthnContext element specifies the desired authentication methods. It is optional in AuthnRequest elements sent to Azure AD. Azure AD supports only one AuthnContextClassRef value: urn:oasis:names:tc:SAML:2.0:ac:classes:Password



In order to get this fixed, I think you can ask your developer to change the authentication request for this application.





Hi Rishabh,
thanks for your reply!

I am not a developer at all, but basically what you are saying is:

classes:PasswordProtectedTransport --> most probably this causes the problem
classes:Password --> this will work?

Is this correct? I will ask the developer to look futher into this.


Yes, it will work and you can also share this article with him.


If still it doesn't work, let me know.





This is the code that is being used and is causing the error.
Note that some values have been anonymized.
Can you see anything wrong?

Regards Josse


var express = require('express');
var path = require('path');
var favicon = require('serve-favicon');
var logger = require('morgan');
var cookieParser = require('cookie-parser');
var bodyParser = require('body-parser');
var passport = require('passport');
var session = require('express-session');
var fs = require('fs');
var SamlStrategy = require('passport-saml').Strategy;

var kSSODomain = "";

passport.serializeUser(function (user, done) {
  done(null, user);
passport.deserializeUser(function (user, done) {
  done(null, user);
passport.use(new SamlStrategy(
    callbackUrl: '',
    entryPoint: '',
    issuer: '8888888-8888-8888-8888-8888888888888',
    cert: fs.readFileSync('sso-prd.cer', 'utf-8'),
    signatureAlgorithm: 'sha256'
  function(profile, done) {
    return done(null,
      id: profile['nameID'],
//      email: profile[''],
      email: profile[''],
      displayName: profile[''],
      firstName: profile[''],
      lastName: profile['']

var index = require('./routes/index');
var users = require('./routes/users');

function findByEmail(email, fn) {
    vwapi.userFind(email, function(error, body) {
//        console.log(body.result);
        if (!error && body.result.substring(0,2) == "OK") {
            return fn(error,;
        return fn(error, null);

var app = express();

// view engine setup
app.set('views', path.join(__dirname, 'views'));
app.set('view engine', 'ejs');

app.use(bodyParser.urlencoded({ extended: false }));
    resave: true,
    saveUninitialized: true,
    secret: 'removedthis'
app.use(express.static(path.join(__dirname, 'public')));

app.use('/saml2/', index);
//app.use('/saml2/users', users);

app.get('/saml2/login', (req, res) => {

    passport.authenticate('saml', {
        successRedirect: '/account/home',
        failureRedirect: '/login'
  passport.authenticate('saml', {
    failureRedirect: '/account/login',
    failureFlash: true }),
  function(req, res) {
    var profile = req.session.passport.user;
    validatedUser(req, res, profile);

function validatedUser(req, res, profile) {

// catch 404 and forward to error handler
app.use(function(req, res, next) {
  var err = new Error('Not Found');
  err.status = 404;

// error handler
app.use(function(err, req, res, next) {
  // set locals, only providing error in development
  res.locals.message = err.message;
  res.locals.error ='env') === 'development' ? err : {};

  // render the error page
  res.status(err.status || 500);

module.exports = app;

@Josse Huizen Did you ever resolve this? Seeing the exact same behavior with a third party provider/app.

@GlenE yes we had our 3rd party provider use a different SAML library and that did the job. There wasn't anything wrong with our Azure (configuration); it was something that was misconfigured/not working at the 3rd party's sP settings.

@Josse Huizen thanks for the response! We're using Genesys PureCloud which is a fairly well established app so I'm kind of surprised we're seeing this but possibly just a configuration setting on their end. It's kind of difficult to say that it's an Azure AD Premium config issue as SSO works as expected on the second attempt. I think we'll get a ticket open with the provider and see what they have to say.


Thanks again!


We have a similar issue here.  We're using AAD for Boomi (as in Dell Boomi) and get the same error in IE and Chrome (but Firefox works), but only from one office site.  If we log into workstations in our other offices (New York, Boston, London, Shanghai), we can use IE and Chrome with no issues.  Here is where it gets interesting, if we log into a W10 vm that is in our servers OU, we can use IE and do not get that error.

I've worked with our firewall team and they excluded me from the encryption policy on the FWs and everything with no luck.  The fact that it works from a machine in an OU outside of our user/computer GPOs has me looking down that path...but i'm not sure where to start.

@Josse Huizen this error is related to the application sending this:
if the application has an option to select the authentication method, change it to 
To Allow Azure to select the authentication method
Right now is attempting to use WIA but being forced to use Username and Password