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.

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.

Yes, that might have been caused by Chrome SSO. Everything we do in the new sign in experience and stay signed in experience are cookie-based, and cookies are not shared across regular and in-private sessions.Regarding the other two issues you reported:1. Translation issue - thanks for reporting this. I'll work with our localization team to get that fixed.2. Checkbox - the checkbox is essentially a no-op when you say Yes since saying Yes means that you won't have to interactively sign in again in the future. It only applies when you say No so we don't nag you.

@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 :)

Hi, 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? Thanks Bernd

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 :-) VasilMichev 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...CheersBernd

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

121 Replies

Daniel1582
Copper Contributor
Jun 19, 2020

I get this after clicking Yes to the KMSI:
Whoops!
Something went wrong
We cannot sign you in to E-WorkBook Cloud. Wait a moment
and try again. If the problem persists you will need to contact
your system administrator.
Event log shows this:
Status
Interrupted
Sign-in error code
50140
Failure reason
This occurred due to 'Keep me signed in' interrupt when the user was signing in.

I opened a support case. Just wanted to share my experience.
Marc Debold
Copper Contributor
Feb 07, 2018
Just spent about a day figuring out the same "keep me signed in" issue, as discussed here. The problem seems to be related to ADFS and WIA. I can provide some details on my customers setup and how to reproduce the problem (got a workaround, too):

We have a federated O365 domain, ADFS on prem for authentication and WIA / IE trusted zones setup internally, so that no logon prompt used to display when accessing O365 resources (tested access to OneDrive in browser).

Internal behavior: With the new login experience, user name needs to be provided, redirect to ADFS and automatic logon succeed, then you are returned to your desired destination in your browser --> No prompt for "keep me signed in".

External behavior: User name needs to be provided, redirect to ADFS shows ADFS login page. Password must be entered there, redirect to MS happens (eventually MFA thereafter), then "keep me signed in" appears, can be set and works correctly.

What I already did:

Removed the corresponding WIA agents from ADFS config to have the ADFS login page experience from internal clients. KMSI dialog from MS is not displayed.

Enabled KMSI in ADFS properties and added claim rules to pass through PSSO claim. Now on the ADFS website, there is a keep me signed in checkbox, which does place a permanent cookie, so that subsequent logins (after closing and reopening the browser) are not required. The KMSI dialog from MS is not displayed. This is my current workaround, but not the desired state.

I think, the problem is the combination of ADFS and WIA-enabled authentication from inside the coorp network. The exactly same setup works as expected from external locations, but not from internal ones. This used to work in the "old style".

I would gladly help getting this thing done, if you need more input. Just get in touch with me. Already checked this issue with a second setup, same behavior there ...
- Jeroen Lammens
  Copper Contributor
  Feb 21, 2018
  Marc Debold
  
  We are facing the same problem. External users get the KMSI dialog, internal users do not (both after authentication against ADFS). As a result SharePoint Online WebDAV is not working anymore. Have you found a solution to this?
  - Marc Debold
    Copper Contributor
    Feb 28, 2018
    Jeroen Lammens wrote:
    Marc Debold
    
    We are facing the same problem. External users get the KMSI dialog, internal users do not (both after authentication against ADFS). As a result SharePoint Online WebDAV is not working anymore. Have you found a solution to this?
    
    Right, and I found a solution (together with MS support). Use the claim rule provided in this answer, that worked for me very well. Still I cannot say, if that helps with your WebDAV problem. But would be worth a try, as it doesn't break anything.
escupham
Steel Contributor
Feb 05, 2018
Trying to understand exact implications of hiding the KMSI option. This link states, "Some features of SharePoint Online and Office 2010 depend on users being able to choose to remain signed in. If you set this option to No, your users may see additional and unexpected prompts to sign-in."

Is there a list of the features/functionality that may be impacted when hiding this option?
Brenda Carpen
Copper Contributor
Jan 23, 2018
I have Office 365 MFA enabled. When the "Keep me signed in" experience rolled out in December I saw it. I clicked on Keep me signed in did not require authentication when I logged into Office 365 from any browser.

At some point in early January, I believe this changed. Now when I log in I get taken straight to my organization's login page, enter my credentials and I'm in. I have to log into Office 365 from my browser every day. The experience is the same across all my devices. I have not seen the "Keep me signed in" feature since.

Help please?!
- Brenda Carpen
  Copper Contributor
  Feb 08, 2018
  o my team and I sat down in a room to compare our different experiences. We found that each browser has settings that delete cookies In Chrome I had this setting "Keep local data only until you quit your browser" turned on. When I turned this off I was presented with the "Stay Signed In" option and was able to stay logged in once I had authenticated and verified with MFA. I have not had to reauthenticate. This is a per browser setting. Each browser has different settings of course. We think Macs have a privacy setting Website Tracking Prevent cross-site-tracking and if this is checked this will prevent the Stay Signed in feature to work. I haven't confirmed yet but will update this post once we do.
- Kelvin Xia
  Former Employee
  Jan 23, 2018
  Try clearing browser cookies and signing in again. Let me know if you see the "Keep me signed in" prompt then.
  - Brenda Carpen
    Copper Contributor
    Jan 23, 2018
    Hi Kelvin,
    
    This did not work. I get taken to my organizations SSO page, get prompted for MFA accept prompt and then go straight to Office 365.
Greg Brown
Copper Contributor
Jan 10, 2018
We utilise WebDAV to map SharePoint Online drives for all of our 365 clients, and the new sign in has a critical flaw. After the initial sign in using IE the option to stay signed in is not presented, meaning that the mapped WebDAV drives do not reconnect. Returning to the old sign in and ticking the "Keep me signed in" still works fine however. If we log in to an inprivate browser the stay signed in option returns, however this is no good to us as it will not map a drive this way. Resetting IE also returns the

stay signed in prompt, however again this disappears after the initial sign in.
Joe Johannes
Copper Contributor
Dec 28, 2017
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
- Kelvin Xia
  Former Employee
  Jan 02, 2018
  Hi Joe,
  
  can you please clarify what you're trying to achieve? Is this an issue that has occurred with the new sign-in experience or is this just new functionality you want enabled?
Unnie
Iron Contributor
Dec 20, 2017
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/
- Kelvin Xia
  Former Employee
  Dec 20, 2017
  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.
  - Unnie
    Iron Contributor
    Dec 20, 2017
    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.
Srikanth Komirishetty
Copper Contributor
Dec 02, 2017
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 https://cloudblogs.microsoft.com/enterprisemobility/2017/09/19/fewer-login-prompts-the-new-keep-me-signed-in-experience-for-azure-ad-is-in-preview/ )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?
- Kelvin Xia
  Former Employee
  Dec 03, 2017
  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.
Ed Sparks
Iron Contributor
Nov 28, 2017

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?
- Kelvin Xia
  Former Employee
  Dec 03, 2017
  Sorry about that. We pushed out a fix for that mid-last week. It should work now.
  - Srikanth Komirishetty
    Copper Contributor
    Dec 03, 2017
    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?
Bernd Verhofstadt
Iron Contributor
Nov 21, 2017
Hi,

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?

Thanks

Bernd
- VasilMichev
  MVP
  Nov 21, 2017
  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.
- Kelvin Xia
  Former Employee
  Nov 21, 2017
  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
    Iron Contributor
    Nov 21, 2017
    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 :-)
    
    VasilMichev 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...
    Cheers
    Bernd

Forum Discussion

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

121 Replies

Resources