Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community

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.

 

Slide1.PNG

 

Read about it in the Enterprise Mobility & Security blog.

121 Replies

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?

Hello,

 

I have one user who is having an issue of "looping."  They sign into SharePoint via the SSO and then the page refreshes and says "you are already signed in" and just keeps spinning like it is trying to load the page.  However, it never moves past the log in page.  The only way we can move past is to log in again as another user. 

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:

  1. 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.
  2. 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 ...

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 wrote:
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.

There is one case where it would be really useful to have KMSI available when using SSO and that is when Azure MFA is enabled, to allow to remain signed in without getting prompted for the MFA code each time the browser is launched. When outside the LAN the KMSI appears (since then SSO is not active), so no reason not to show KMSI when on the LAN.

 

Is there any thought to allow this? Thanks

 


@Kelvin Xia wrote:
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.

That's almost right, but: For SSO to work, you need to provide the username / email address / UPN (which may be saved, but has to be confirmed by clicking it) before SSO kicks in. This is the issue in our case.

 

Imagine the following (real-world) scenario: Customer is using a SharePoint Online document library to store attachments for his Navision users. So when clicking on a link in Navision to open such an attachment (mostly PDF documents), you would expect your PDF viewer to open. In the current situation, your browser opens asking for your login (which perhaps was saved before), you confirm it, SSO happens and the PDF opens. After doing whatever with the document, the user closes the PDF and the browser window. After that, he clicks the next link in Navision and the same happens ... browser, confirm username, SSO, PDF. Only by leaving open the browser (as a workaround), the annoying clicking and waiting can be bypassed.

 

This behavior most likely applies to any SharePoint related content storage ...

 

By using the persistent session token, a true SSO experience (as seen in the old version) could be setup again.

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

Our organization is experiencing the same problems. We use ADFS for authentication. KMSI dialog is shown externally, but not internally. SPO WebDAV doesn't work anymore and users have to choose their UPN every time they launch the browser.

We are experiencing this issue as well.  Has there been any resolution identified?


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

We have opened a MS call and we are currently working on it. Until now, we have made no progress as MS (or at least the technician dealing with the ticket) claims this to be the way it is intended to work.

I'll report back as soon as I got news.

Hi everyone,

our recommendation to bypass the additional "Pick an account" prompt and redirect automatically to on-prem IdPs (eg. ADFS) for auth is to enable SharePoint auto-acceleration: https://support.office.com/en-us/article/enable-or-disable-auto-acceleration-for-your-sharepoint-onl...

Please take note of the call out on how this might not work if you have users that are external to your organization (guest users) access your SharePoint site.

If SharePoint auto-acceleration does not work for your environment, you can consider setting up ADFS to return the Persistent SSO claim with every sign in. That will cause Azure AD to drop a persistent token which will bypass the "Pick an account" screen.

@Kelvin Xia I think the last few complaints are about the WebDAV/mapped drives experience. Previously, we were able to make this persistent by making sure the "LoginOptions" parameter is passed via the smart links used. In the new experience, this seems to no longer be the case, thus the session expire more often and break the user experience.

Indeed, the KMSI screen does not show up after authentication against ADFS for our internal users. As a result, WebDAV/mapped drives are just not working anymore.

While I can understand this is legacy tech, it should still be supported until a replacement solution is delivered. I'm thinking along the lines of the OneDrive files-on-demand with the possibility to keep the synced files only in the cloud and not have them synced locally whenever one is opened (we don't have the storage for this / don't want to support this scenario).
To support SharePoint mapped drives with ADFS, we recommend setting up PSSO which will result in the same logic as a user manually checking the old KMSI checkbox.
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/ad-fs-single-sign-on-setti...
Hi Marc,

Is the screen where your user has to click on a username the "Pick an account" screen?

I believe that what you're seeing is caused by a different change in our code. Can you please send me a Fiddler trace of a user running through the scenario you mentioned and seeing the "Pick an account" prompt? Please DM me the trace so we can look into it.

Thanks,
Kelvin

Hi @Daniel Billington - we have exactly this issue since we enabled Azure MFA. Did you find any solution yet?

 

@Kelvin Xia this is really a big annoyance for anyone using Seamless SSO and MFA. The KMSI dialogue does not show up if Seamless SSO ist enabled, which results in repeated MFA requests every time the browser is restarted. Once we disable Seamless SSO on the client side (Browser Intranet Zone), users see the KMSI and are able to stay signed in... no unnecessary MFA requests anymore. We still want to use both: Seamless SSO and MFA, but at the current state this is not possible. Whats the best practice if we want to combine both methods?

 

EDIT: we are not using AD FS, instead we are relying on Azure AD Connect.

Hi Kelvin,

 

What is the recommendation where SPO acceleration is not an option e.g. due to large numbers of heavily utilised externally shared sites. In this scenario internal users will still get the "username" prompt (required to support the external users authentication flow to their IDP). Presumably as there is a "flag" set on the site to say it is externally shared and therefore should not support honour the accelerated redirect to ADFS.

 

And in addition where persistent SSO is not an option due to the security risks e.g. Persistent cookie coupled with insidecorporatenetwork claims result in users being issued a persistent cookie that can then be used when they travel off the corporate network.

 

Ideally it would seem better and easier if the accelerated feature differentiated between the corporate users (based on UPN suffix??)  and redirected the authentication to ADFS but allowed the redirection to the login.microsoftonline.com for the external users.

 

Any pointers on a supported solution or indication on when a fix for externally shared sites might become available?

 

Thanks


@Kelvin Xia wrote:
Hi Marc,

Is the screen where your user has to click on a username the "Pick an account" screen?

I believe that what you're seeing is caused by a different change in our code. Can you please send me a Fiddler trace of a user running through the scenario you mentioned and seeing the "Pick an account" prompt? Please DM me the trace so we can look into it.

Thanks,
Kelvin

Hi Kelvin,

yes, it is the "Pick an account" screen, that is displayed. I'll send the trace asap.

 

Marc


@Kelvin Xia wrote:
To support SharePoint mapped drives with ADFS, we recommend setting up PSSO which will result in the same logic as a user manually checking the old KMSI checkbox.
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/ad-fs-single-sign-on-setti...

That claim did not work for me and my customers (tried it with two different setups), but MS support supplied the following claim rule, that works just perfectly:

 

c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork"]
 => issue(Type = "http://schemas.microsoft.com/2014/03/psso", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

Using this rule gets rid of the username prompt "Pick an account". For my customer that is the solution to the problem.

 

@Kelvin Xia: I'd be pleased to keep on working on the "Pick an account" prompt to get it working as designed.

This new rule has worked for us so far! Thanks.