Enterprise Apps: Password-based SSO apps are not passing credentials correctly and users can't change passwords.

Eric Miller 51

We are experiencing a couple of weird issues with MyApps page, with our password-based SSO in Enterprise Apps within Azure AD.

1st, it seems like the passwords are not being passed correctly. I have manually typed in the passwords in the admin side, and when people login, it says incorrect username and password. But when I retype the password on the webpage's login screen, it logs into the webpage. So it isn't the password. It has to be something with how the password is being passed to Edge.

2nd, it seems like there are some apps, where the user cannot change their password via the "Manage your application" from the 3 dots of the app. It should give the account and then a pencil to edit the password, but for some apps it is not showing the account at all. So I have to manually change and update their passwords via admin side, which is wrong and should not be. But then in some cases, we're running in the 1st issue. It is not all password-based SSO apps, but it is some.

I created a brand new app for one that wasn't working and have been testing on it.

I can't submit a support ticket because we don't have a paid Azure support account. We are using Azure AD via O365 and Azure AD P1 licenses. I don't understand why we can't put in a ticket for something we're licensed for that is broken.

Alfredo Revilla - Upwork Top Talent | IAM SWE SWA 27,456 Reputation points

2023-09-20T21:04:18.57+00:00

Hello @Eric Miller , please Collect a network trace in the browser and send us the exported HAR file to azcommunity@microsoft.com with Subject Attn: Alfredo Revilla.
Eric Miller 51 Reputation points

2023-09-25T16:37:53.3466667+00:00

@Alfredo Revilla - Upwork Top Talent | IAM SWE SWA The email has been sent. We seem to have found that the issue might be with the "My Apps Secure Sign-in Extension".

With the latest 2 versions (latest being 8.0.2428.146), the issue is there.

However, with version 8.0 and older, the issue is not there.

It doesn't matter if it's Chrome or Edge.
Eric Miller 51 Reputation points

2023-09-27T15:38:34.76+00:00

@Alfredo Revilla - Upwork Top Talent | IAM SWE SWA I haven’t heard anything from any one yet.

I’m curious if this issue has something to do with special characters in the password?

We have some passwords that pass just fine with the newer extension.

But this password has several special characters including:

=

greater than sign ">"

%

?

@

Is there a character type limitation in Azure or the extension that prevents it from passing correctly to the website?
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Alfredo Revilla - Upwork Top Talent | IAM SWE SWA 27,456 Reputation points

2023-09-28T04:14:43.71+00:00

Hello @Eric Miller , apologies for the delay. Please review your email.

Accepted answer

Olga Os - MSFT 5,921 Reputation points Microsoft Employee

2023-10-12T05:42:49.7933333+00:00

Hello Eric Miller,

Welcome to the MS Q&A forum.

I experienced a problem with special characters such as '<>&' being altered in version 8.0.2428.146, which was released on August 29, 2023. However, I found out that the issue was fixed in the subsequent release.

To confirm that the issue has been resolved, I recommend testing with version 8.0.02463.153 of the My Apps Secure Sign-in Extension from the Chrome Web Store. I have tested the new version and it appears to be working correctly.

If the issue persists, you may want to try reinstalling the browser extension in the Edge browser from the Edge store at https://microsoftedge.microsoft.com/addons/detail/my-apps-secure-signin-ex/gaaceiggkkiffbfdpmfapegoiohkiipl as a possible workaround.

After testing the above options, please let me know if you are still experiencing the issue.

Sincerely,

Olga Os.
Please sign in to rate this answer.

1 person found this answer helpful.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Graham C 26 Reputation points

2024-01-23T15:36:54.8566667+00:00

EDIT: One thing I found just now is if you change the URL and remap the HTML it does seem to bring back the user-managed credential option!! Soley remapping in the past has had no change, but obviously, this might only be applicable if a service changes their logon page URL. Hopefully this can be of use to someone desperate for a solution that does not want to kill the stored cred on a heavily used tile. .................................... There should be a better fix provided by Microsoft here than down versioning, seems the "new" my apps page has created this bug or at least happened very close to each other. Our org is on the latest version of the ext (Version8.1.1.161) which is forced through intune MDM. I have found that pw-sso apps that were created a long time ago back near the beginning (our tenant is about 8 years old) are consistently having the symptom of no user credential management ability (the option to edit/add an account in the app tile is gone) causing lockouts when incorrect (old) credential is replayed. The only workaround we've found is the inconvenient process of completely recreating the application objects which makes all users have to store a credential all over again. Local storage of creds in the browser is not an option and disabled in our org. This has been a great solution for services that don't have SSO while preventing pw sticky notes on desks.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Eric Miller 51 Reputation points

2024-02-27T21:23:27.6033333+00:00

Graham, your issue is a separate one that I ran across. Here is the solution: Somehow some of our Password SSO app's parameter "preferredSingleSignOnMode" got changed to "null", instead of "password".
From the Graph API you can find out if it is incorrectly set: using GET https://graph.microsoft.com/v1.0/servicePrincipals/{object-ID of app} then look for "preferredSingleSignOnMode". If it is null, then you need to change to PATCH and add the following to request body:
{ "preferredSingleSignOnMode": "password" } Then submit and then recheck it. This has fixed the issue for me.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

1 additional answer

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Share via

Enterprise Apps: Password-based SSO apps are not passing credentials correctly and users can't change passwords.

1 additional answer

Your answer