Nov 15 2017
01:23 PM
- last edited on
Jan 14 2022
05:28 PM
by
TechCommunityAP
Nov 15 2017
01:23 PM
- last edited on
Jan 14 2022
05:28 PM
by
TechCommunityAP
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.
Feb 05 2018 01:48 PM
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?
Feb 06 2018 02:47 PM
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.
Feb 07 2018 05:03 AM
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:
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 ...
Feb 08 2018 07:56 AM
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.
Feb 17 2018 10:32 AM
@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
Feb 18 2018 12:42 AM - edited Feb 18 2018 12:43 AM
@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.
Feb 21 2018 07:03 AM
Feb 21 2018 07:24 AM
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.
Feb 21 2018 10:01 AM
We are experiencing this issue as well. Has there been any resolution identified?
Feb 21 2018 02:51 PM
@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.
Feb 21 2018 03:27 PM
Feb 22 2018 12:47 AM
@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.
Feb 23 2018 06:34 AM
Feb 23 2018 03:51 PM
Feb 23 2018 04:05 PM
Feb 26 2018 07:19 AM - edited Feb 26 2018 07:41 AM
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.
Feb 26 2018 09:38 AM
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
Feb 26 2018 11:21 AM
@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
Feb 26 2018 12:15 PM
@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.
Feb 26 2018 02:05 PM
This new rule has worked for us so far! Thanks.