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.
Dec 04 2017 01:08 PM
We are seeing this issue as well when we try to map a users onedrive. Have you found a fix yet?
Dec 14 2017 07:15 AM
We don't use ADFS but we have AD Connect, is there any reason why we are not seeing the new KMSI experience? It is very hard to keep users informed IF we rely on the roll out dates suggested by Microsoft.
Dec 14 2017 10:53 AM
Dec 14 2017 10:54 AM
Dec 18 2017 07:48 AM
We have SSO set up and based on your statement, Microsoft has added logic not to show the prompt.
Is there a way we can show this prompt with SSO enabled? To your previous question, we have not set up ADFS to pass PSSO Claim for SharePoint.
Appreciate your help.
Dec 18 2017 10:14 AM
Dec 18 2017 10:15 AM
@Kelvin Xia what exactly does the "shared machine" logic cover? I stopped receiving the KMSI prompt on my personal PC, which is pretty much the most secure machine I use (even added as trusted IP), and since I'm not using any form of SSO for said account, that only leaves the "shared machine" scenario? On the same machine, another user from the same tenant is getting the KMSI prompt...
Dec 18 2017 02:58 PM - edited Dec 18 2017 02:59 PM
The reason I ask is, we get this window every single time when we close the browser. I need not enter my password but I have to click on my account (I have to pick every single time I close the browser). If I switch to old sign in experience, I can check the box to keep me signed in and it will never ask me to pick the account. As the old sign in page is going away, we need to provide our users a way to avoid picking account each and every time the re-open the browser. The only, I saw is with the prompt and that is why, I'm reaching you to see if we can enable that prompt on SSO.
Dec 19 2017 12:34 AM
@Srikanth Komirishetty do you happen to be using Smart links? Even with the old experience, without smart links configured you have to enter/select the UPN before federation happens. But you can construct "smart links" (basically an URL with added parameter for the domain) to bypass this process and have you log in automatically. Perhaps those are not working with the new experience?
Dec 20 2017 02:11 AM - edited Dec 20 2017 03:50 AM
Current set up
We have SharePoint Online site with auto acceleration enabled. Our Azure AD is federated with on-premise ADFS. We have seamless SSO working in IE where user does not need to type any username password.
By default, when the user logins in thru IE, only Session cookie is generated, so when the user closes the browser and reopens the user is authenticated again. Also, the new KMSI (Keep me signed In) screen is not displayed to the user during the login experience in IE, so there is no way for user to generate persistent cookie which works across multiple sessions. In chrome, user can see the KMSI screen and hence persistent cookies can be generated.
Is there a way by which global admin can configure such that all users by default gets persistent cookies instead of session cookie, so that they don’t even need to click “yes” in KMSI screen?
I saw below blog where it says to create custom claim rule in ADFS to issue Persistent SSO claim. But again, the last line of the blog says “As of right now, AAD does not support SAML based use of the Persistent Single Sign On Claim / SAML attribute.” So, is this blog relevant now?
Dec 20 2017 09:06 AM
Dec 20 2017 09:15 AM
Dec 20 2017 09:18 AM
Dec 20 2017 11:14 AM
Thanks Kelvin. I did clear cookies, but that doesn't seem to had any effect. And if it's cookie based, doesn't explain why I don't see the prompt in Private session or when using other browsers on the same machine? Is there perhaps any "server-side" component to it? Same machine, same browsers, same O365 tenant - one user gets the prompt in Private session, the other one does not.
Dec 20 2017 12:28 PM
Dec 22 2017 02:14 PM
Dec 22 2017 02:16 PM
Dec 28 2017 02:17 PM
Jan 02 2018 01:54 AM
We are experiencing the same as @Vasil Michev, no KMSI prompt after successful sign-in in IE11 or Chrome. And every time browser is started a sign-in prompt (password) is shown. Also sign-in prompt is shown every time I open locally installed Outlook client.
Jan 02 2018 12:22 PM