Forum Discussion
Community ManagerThe 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 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.
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
- Kelvin Xia
Microsoft
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.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
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.
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.
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 ...
- 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.
Hi, we are using a Federated domain With local ADFS. Before this change, single signon worked without any questions when we are logged into the local domain.
Now, after this New "experience", Our users must click on a Choice on the keep me logged in or not page. This is an anucence for Our users. We use Azure AD for authentication to Our intranet in the cloud.
Is there a setting on an Application or Azure AD Directory, or a URL parameter or similar that can be used to disable this?
Microsoft support answered it for me. Turn it off in Company branding:
Hi,
while I do see some benefit on the KMSI feature for regular users, I would prefer to have privileged admin accounts be prompted for MFA Login in their browser profiles every time.
How can I achieve this without turning the feature off for everyone?
Regards,
Karsten
- Kelvin XiaThe KMSI setting in Company Branding doesn't allow that. You might want to look up Conditional Access which might get you what you want.
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 XiaHi 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.- 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.
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?!
- Kelvin XiaTry clearing browser cookies and signing in again. Let me know if you see the "Keep me signed in" prompt then.
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.
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.
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?
EricStarker Do you have any information on the ADFS web theme to allow on-premises ADFS look and feel to match the new sign in experience? We saw some information during the original preview announcement that this would be coming but are unable to find any info. We have our TAM also checking for information but thought I'd check here as well.
- Kelvin XiaHey Jeremy, the web theme can be found here: https://github.com/Microsoft/adfsWebCustomization/tree/master/centeredUi
Kelvin Xia two minor issues still remain:
1) When using federated account, I have to press the Next button in order to be taken to the AD FS login page. In the previous experience this was automatic, simply pressing Tab for example did the trick.
2) Why am I being prompted for the KMSI experience when using Private sessions? Maybe you should implement a check for this?
Okay, but what if that is entirely undesirable behavior in half of your use cases? When my users are on their personal computers, this is a good thing. When they are using one of our many shared workstations, the last thing I want is for them to be encouraged to "Stay signed in".
How do I prevent it from being offered on office computers without preventing it on their personal devices? Most, though not all, of our offices are AD joined, so if there's a GPO I can push out please indicate that in some way.
If the classic login screen can be permanently forced per-domain (per tenant may not work for our parent company), that would also be acceptable.
Because as it stands, this is a horrible idea. I'm going to have realtors reading each other's emails after we told them we were setting them up with MFA to keep anyone else from getting into their email.
- Kelvin XiaHi Matt, we have a best-effort algorithm that prevents the new "Stay signed in" dialog from showing if we detect that the login is happening on a shared machine.
It essentially looks to see if a different account than what is currently being used to login was used on the machine in the last 3 days. If so, we won't show the dialog. We also use our adaptive protection logic to hide the dialog if we detect that the login is risky. Note that this logic is subject to change as we iterate on the logic to increase confidence that we only show this dialog on personal devices.That makes me feel better.
May I suggest stating that in more places? Like the announcements, relevant blog posts, or other places that admins will see before they start to flip out?
