Closed c016smith closed 6 years ago
Actually, how you described it is how it works - see step 10:
"Additionally, you can also provide credentials on behalf of the user by selecting the rows of the users and clicking on Update Credentials and entering the username and password on behalf of the users. Otherwise, users be prompted to enter the credentials themselves upon launch."
Basically, you have 2 options - 1) manage the password as the admin so users don't know about it 2) let your users manage passwords for themselves. In both instances, the password is stored securely in Azure AD. Does this clarify for you? Feel free to send me a note at asteen@microsoft.com if you have more questions.
I responded above - is there a way to close this request?
Thanks for the response Ajames - yes I saw step 10, I just hadn't found that. So far it is still pretty clunky, but I'm curious if the website I'm trying to hit as a use-case is the problem. I finally found out where to collect and store the shared credentials in AAD, as well as how to set credentials specifically for a user in AAD for that app. However, in execution it doesn't really work for the website when my test user goes to logon. The webpage fills in the username but throws an error like, you need to sign-in again so we know it's really you. Perhaps it's trying to block password keepers like this?
Also, is this functionality (for shared passwords) 100% tied to the new browser extension "My Apps Secure Sign-In" or will it work with a native browser configured with SSO/S+SSO as well?
Hey C016smith - the password vaulting requires the browser extension you mentioned - that is the only way to get SSO to these applications (you can also use the managed browser on mobile devices). It sounds like you may have misconfigured the application you mentioned, or perhaps the application is using an unsupported sign on page type .
You can use these documents to troubleshoot further:
Please send me a note at asteen@microsoft.com and we can help you further there :).
@c016smith We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.
I am reading that the goal of this feature is to allow Administrator of the app to manage the password, so user never knows the password. As it is setup right now, it looks like the user still has to know the password to sign-in on their own the first time. Shouldn't this password be securely stored in the Azure AD app blade, where the administrator creates and manages this password-enabled App, not on the client side?
I would think adding the shared username/password for an app would fall under the heading above: Configure the application for password single sign-on <>.
Am I missing the point or a step somewhere?
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.