Forum Discussion
EricStarker
Nov 15, 2017Former Employee
The new Azure AD sign-in and “Keep me signed in” experiences rolling out now!
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 e...
Marc Debold
Feb 07, 2018Copper Contributor
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
Feb 21, 2018Brass Contributor
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 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 DeboldFeb 28, 2018Copper Contributor
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.
- Jeroen LammensMar 02, 2018Brass ContributorHi Marc, We're trying it out. Many thanks!
- Marc DeboldFeb 21, 2018Copper Contributor
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.
- Kelvin XiaFeb 21, 2018
Microsoft
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-online-tenancy-74985ebf-39e1-4c59-a74a-dcdfd678ef83
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.- Andy StephensFeb 26, 2018Copper Contributor
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
- Caleb_ElsingerFeb 21, 2018Copper Contributor
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.