Forum Discussion
The new Azure AD sign-in and “Keep me signed in” experiences rolling out now!
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 LammensFeb 21, 2018Brass ContributorMarc 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 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, 2018Iron ContributorHi 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.
- 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.