Forum Discussion
Community ManagerThe new Azure AD sign-in and “Keep me signed in” experiences rolling out now!
Microsoft
Kelvin Xia two minor issues still remain:
1) When using federated account, I have to press the Next button in order to be taken to the AD FS login page. In the previous experience this was automatic, simply pressing Tab for example did the trick.
2) Why am I being prompted for the KMSI experience when using Private sessions? Maybe you should implement a check for this?
We are also experiencing this issue where the KMSI dialog is being displayed for all of our internal ADFS sign ins when previously it was automatic. For now, we have disabled the feature.
If there is a fix for this, please let me know. Thank you.
- Kelvin XiaHey Vasil,
Thanks for the feedback.
For #1: This is by design in the new experience. We had a lot of strong feedback about the old design where we initiated the redirect when focus was lost on the username field. Most users thought that it was unexpected and jarring and did not give them the opportunity to go back and correct typos. We decided to wait to redirect only after the user clicks the Next button. This experience is consistent with almost all other identity systems.
#2: Can you help me understand your scenario where you don't want KMSI to show up in private sessions and why?Three remarks on the new experience:
1. Spelling mistake (in Dutch translation, a period in the middle of a sentence)
2. The checkbox in the KMSI dialog is confusing (don't show this again). Does it make me stay logged in even longer when I select Yes and thick the checbox?
3. When I choose "Yes" in my regular browser session, open a private session, enter a different account in the private session. I get logged in with the account of the regular session anyway, no matter the account I filled in. Is this by design?
Thanks!
Bart
What browser are using Bart? What you are describing in scenario 3 shouldn't be happening, unless maybe in federated environment with WIA autologin. Kelvin can correct me here.
Kelvin, correct me if I'm wrong, but most of the complaint about the auto-redirect with just filling in the UPN were because it didn't allow users to select the KSMI checkbox. Now that that's a separate step, this issue no longer applies?
On the Private session thingy, does KMSI even work with Private sessions? It writes a cookie, no? Which is *not* saved if/when I'm using a Private session. So displaying the KMSI step is pointless?
And one other thing comes to mind after seeing the comments made by other folks here - are you guys respecting the "LoginOptions" parameter for federated logins/smart links? The idea being that it automatically ticked the KMSI checkbox in the old experience...
- Kelvin XiaIt's actually more than the KMSI checkbox - doing a full page redirect when a user doesn't expect it causes usability issues. It's also not a standard interaction model anywhere on the web, causing user confusion and frustration.
You are correct, showing KMSI in private sessions doesn't really do very much. However, there's no deterministic way for us to determine that we're in a private browser session.
Regarding LoginOptions, I believe we have discussed this before. We don't officially support the use of LoginOptions - it's an internal parameter used to pass information across our pages. We did not change how it is used with the new experiences, though we cannot guarantee that it won't happen in a future change. :)
