The new Azure AD sign-in and “Keep me signed in” experiences rolling out now!

[EricStarker]

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.

[#2]

Bernd,

We are seeing this issue as well when we try to map a users onedrive.  Have you found a fix yet?

Jason

[#3]

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. 

[#4]

Hi Jason,

are you still seeing issues, if you are, can you please DM me your email address and I'll contact you to get more information to troubleshoot the problem.

[#5]

Hi Paul,

This new KMSI experience is completely rolled out now for a few weeks. We added some logic to hide the prompt if we detect that the login session is risky, if it's a shared machine or if SSO is set up. Can you please try logging in on an in-private/incognito browser and see if the prompt shows?

[#6]

Hi Kelvin,

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.

[#7]

May I know why you want to see the prompt even when SSO happens? By definition, when SSO'ed your user should just always automatically sign in without any interactive prompts. So, asking the user if they want to remain signed in doesn't really mean anything when SSO happens.

[#8]

@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...

[#9]

Kelvin,

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.

[#10]

@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?

[#11]

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.

Problem statement:

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.

Questions:

 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?

https://blogs.technet.microsoft.com/sposupport/2017/09/16/cookie-persistence-in-sharepoint-online/   

[#12]

Hi Srikanth, I'll reach out to you via DM to get more information so we can look into this.

[#13]

Hi Unnie, thanks for the breakdown.

What are you trying to achieve with persistent cookies? If you have seamless SSO set up, every time your user goes to the Sharepoint site they will SSO automatically, which makes the need for a persistent cookie unnecessary.

[#14]

Hey Vasil, the shared machine logic essentially stops showing the KMSI prompt if a different account has been used on the same browser. That logic will reset (and KMSI will show again) if you clear browser cookies, or if you continue to only sign in with that one account for a few days.

For the other user that's getting the prompt, are you using the same browser?

[#15]

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.

[#16]

It's the performance . Our home page for IE is SPO based intranet and it loads slowly because of the authentication hops from the site --> Microsoft login --> on-prem ADFS and then the journey back. The user can see the urls changing and it takes a good 8-10 secs every time the browser is opened.

[#17]

Thanks for verifying. We also take into account a risk score provided by our Identity mechanisms. We've had isolated reports that it is kicking in a tad bit too aggressively, but we don't have confirmation yet.

Can you please DM me the following:
1. UPN of the account you used where KMSI doesn't show and also the one where KMSI does show.
2. Co-relation id of the request when logging in on the account where KMSI doesn't show. You can get this by clicking on the three dots at the bottom right corner of the page when you're on the password screen.

[#18]

Thanks for the details. We're going to take a look into this early next year once the team gets back into the office after the holidays.

[#19]

Hi, MS admin for years, new here. Just saw this, perhaps it can help us. Our call to Microsoft (before this change) had no immediate fix. Our 8k+ users to o365/SPO need access to SP sites. We would like to use this ..."Keep me singed in" for most users. Others with Generic IDs which would only prompt for a password to get to secure content on SPO sites. Is this possible to do both? Details would be golden!!! Thanks, Joe

[#20]

We are experiencing the same as @VasilMichev, 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.

[#21]

Hi Teemu,

would you mind private messaging me your email address? I'll need some additional info (eg. traces) to investigate this.

Thanks,
Kelvin