Nov 15 2017
- last edited on
Jul 24 2020
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 end of the week. Users who go to our sign-in page will start to see the new experiences by default, but a link allowing users to go back to the old experiences will be available until early December to give you some extra time to make the transition.
We'd like to take this opportunity to acknowledge the delays we have had with these features and thank you all for your patience. When we released these experiences in preview, we received a lot of great feedback from you and it was pretty clear we needed to take a little extra time to ensure the new experiences worked well with all the scenarios Azure AD sign-in is used for.
Read about it in the Enterprise Mobility & Security blog.
Nov 15 2017 01:38 PM
@Eric Starker Do you have any information on the ADFS web theme to allow on-premises ADFS look and feel to match the new sign in experience? We saw some information during the original preview announcement that this would be coming but are unable to find any info. We have our TAM also checking for information but thought I'd check here as well.
Nov 15 2017 02:55 PM
Nov 15 2017 11:05 PM
@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?
Nov 16 2017 12:18 AM
Hi, we are using a Federated domain With local ADFS. Before this change, single signon worked without any questions when we are logged into the local domain.
Now, after this New "experience", Our users must click on a Choice on the keep me logged in or not page. This is an anucence for Our users. We use Azure AD for authentication to Our intranet in the cloud.
Is there a setting on an Application or Azure AD Directory, or a URL parameter or similar that can be used to disable this?
Nov 16 2017 03:20 AM
Microsoft support answered it for me. Turn it off in Company branding:
Nov 16 2017 09:30 AM
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.
Nov 16 2017 09:51 AM
Nov 16 2017 12:09 PM
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...
Nov 16 2017 01:51 PM
Nov 16 2017 11:47 PM
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?
Nov 16 2017 11:56 PM
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.
Nov 17 2017 12:17 AM
@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.
Nov 17 2017 06:56 AM
@Vasil Michev 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.
Nov 17 2017 09:37 AM
Nov 17 2017 09:52 AM
Nov 17 2017 10:02 AM
Okay, but what if that is entirely undesirable behavior in half of your use cases? When my users are on their personal computers, this is a good thing. When they are using one of our many shared workstations, the last thing I want is for them to be encouraged to "Stay signed in".
How do I prevent it from being offered on office computers without preventing it on their personal devices? Most, though not all, of our offices are AD joined, so if there's a GPO I can push out please indicate that in some way.
If the classic login screen can be permanently forced per-domain (per tenant may not work for our parent company), that would also be acceptable.
Because as it stands, this is a horrible idea. I'm going to have realtors reading each other's emails after we told them we were setting them up with MFA to keep anyone else from getting into their email.
Nov 17 2017 10:16 AM
We are using Power BI with a Web app and this web app is embedded reports in Salesforce. As soon as this was implemented, we started getting these dialog boxes, so the reports would not come through. HOw can we turn these off so they have a smoother experience. Currently Salesforce won't allow that dialog at all, so they get blank pages as a result of this. If they go through the web app directly in a url, and answer the dialog, the dashboard reports render fine. But this dialog caused our field to lose a week's worth of work so far. I finally found this so I am hoping someone can tell me how to turn it off...for good? We have a critical case open with MSFT right now as a result.
Nov 17 2017 10:47 AM