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

Community Manager

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.

121 Replies
Hi Matt, we have a best-effort algorithm that prevents the new "Stay signed in" dialog from showing if we detect that the login is happening on a shared machine.

It essentially looks to see if a different account than what is currently being used to login was used on the machine in the last 3 days. If so, we won't show the dialog. We also use our adaptive protection logic to hide the dialog if we detect that the login is risky. Note that this logic is subject to change as we iterate on the logic to increase confidence that we only show this dialog on personal devices.

That makes me feel better.


May I suggest stating that in more places?  Like the announcements, relevant blog posts, or other places that admins will see before they start to flip out?

@Kelvin I see your point, but if we had proper documentation on what's supported and not and how the different flow works, I'm sure that would decrease the number of escalations :)


Smart links are still required for true, seamless SSO experience in some cases, and there is definitely demand for such from the enterprise customers. If you can publish some guidelines and recommendations, I think it will benefit all sides.


Anyway, I'll stop with the offtopic :)


while I do see some benefit on the KMSI feature for regular users, I would prefer to have privileged admin accounts be prompted for MFA Login in their browser profiles every time.


How can I achieve this without turning the feature off for everyone?





Many of our users have set a site, library or folder as favorites in File Explorer which connects through webdav(?) to SharePoint. As we are using SSO, users don't get the option 'keep me signed in' anymore. This causes a permission denied when opening the folder or library in file explorer -> no cookie is saved. Is there a workaround to have the cookie or 'Keep me signed in' back? 




We had Microsoft turn ours off at the tenant level until a better plan could be put in place.  The problem with Company branding is: 1.) It's a global setting 2.) It can affect Sharepoint Online users and Office 2010 users (and we had just moved over 30K sharepoint sites to Sharepoint Online, so I didn't want to interrupt their experience for my experience with Power BI to work, 3.) Even as a global admin, we could not delete the company branding. The delete button would not highlight and we verified our permissions.  We could turn it on or off for KMSI, but we could not delete company branding 4.) We found the KMSI box "Don't ask me again doesn't work" either.  It only stays for the session, so to the user they think they should never have to see it again. 5.) We were told we could add a parameter to the Web app to turn this off in the code, so we are pursuing this now as our permanent solution, but for now our customers can function again with KMSI.

Hi Bernd,

how did "Keep me signed in" work for your users before? If you had SSO turned on they wouldn't have seen the login screen nor the "Keep me signed in" checkbox in the old experience.

@Bernd Verhofstadt Just curious, are you using smart links and passing the LoginOptions parameter?


@Kelvin, that's one of the use cases I warned you about - mapped drives rely on this functionality, and the LoginOptions parameter was a nice and easy way to handle this in federated setups.

The KMSI setting in Company Branding doesn't allow that. You might want to look up Conditional Access which might get you what you want.

Hi @Kelvin Xia,

I did some additional tests on the SSO experience. When I delete my cookies and open a mapped sharepoint webdav connection I cannot load it which is expected (cookie is removed). When I open the sharepoint tenant url I get logged in through SSO and most of the time the magical cookie is created. When the cookie is created I'm able to open the webdav connection. For other users (same permission etc) they get a sign in screen where they need to enter there username. then they are redirected to the homepage but they are not able to open the webdav connection.

@Eddy Verbeemen please correct me if I'm wrong :) 

@Vasil Michev few years ago we used the smartlinks to enforce the 'keep me signed in'. At a certain moment this was not longer working and we went back to the default login where we could choose to 'keep me signed in'.
It seems that there is a different between SSO where a prompt is shown for a username and no prompt is shown...

Am I the only one not seeing the KMSI at all now? Cloud account, no federation. I tried deleting cookies, private sessions and different browsers, I don't ever see KMSI now. I thought the changes are supposed to only effect federated scenarios?


We are seeing unexpected behavior when we choose "don't show me this again" and click No.


Every time we login again it gives the prompt again.

Shouldn't "don't show me..." respect a yes or no answer and go away?

Does anyone has issues with "Stay Signed-in" prompt that shows after successful authentication with ADFS? Our tenant is not presenting the prompt (as described here )as it did couple of weeks ago. The option to keep the user signed in has been enabled in our Company Branding settings. Any thoughts?
Sorry about that. We pushed out a fix for that mid-last week. It should work now.
Is your ADFS set up to send the PSSO claim, or do you have Windows SSO set up? If it is, we're automatically dropping the persistent auth cookie (which the "Stay signed-in" prompt does when the user selects "Yes"). We have a few bugs a few weeks ago when we did not do that, which could explain the difference in behavior you're seeing now vs then.
Hi Kelvin, thank you for quick response. Its still the issue for us. Should we perform any steps to speed up the change to our tenant?
Hi Bernd,

sorry for the delay in replying here. Can you please DM me so I can get more details from you? Thanks.
The fix is rolled out already. To clarify what I was saying, if your ADFS is set to pass the PSSO claim, we will not show the prompt.

Thanks for that detail Kelvin. But I need to request yet another documentation update here - the only place I've seen the PSSO claim detailed so far is the claims rules added by AAD Connect. As some organizations might not be using AAD Connect (or at least not managing the AD FS farm with it), can you please post a detailed article on how the claim should look like and so on?