Forum Discussion
The new Azure AD sign-in and “Keep me signed in” experiences rolling out now!
We're excited to announce that the general availability rollout of the new Azure AD sign-in and “Keep me signed in” experiences has started! These experiences should reach all users globally by the e...
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?
Kelvin Xia
Microsoft
MicrosoftHey 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?
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
We want this turned off, anyone know how?
- Kelvin XiaHi Michael, you can turn this off by setting "Show option to remain signed in" in Company Branding to "No". Here's the help article for that: https://docs.microsoft.com/en-us/azure/active-directory/customize-branding
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.
VasilMichev I tried Chrome, we are federated and are using WIA indeed.
We have now removed SSO for Chrome in our ADFS. It is probably not related to the new sign-in, Chrome was added as SSO browser to our ADFS a few days ago.
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. :)@Kelvin, I'm not a programmer so I will trust you on the Private session thingy, although I've seen some JS samples that supposedly to just that. In all fairness, the previous experience wasn't detecting private sessions either. It's just that the KMSI is a separate step now, thus more visible, and can be a bit irritating :)
And on a related topic, can you folks please publish an official statement on what's supported in terms of smartlinks now? Just the other day you published an article mentioning 46% of all auths are AD FS, and I'm certain many of these do take advantage of smart links. Yet, there is zero documentation on them from Microsoft.
