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 26 2018 02:57 PM
Feb 27 2018 12:01 AM
Feb 27 2018 10:59 AM
Feb 28 2018 04:48 AM
@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.
Mar 01 2018 06:39 AM
Hi Kelvin,
We didn't "train" the users directly, they just found that by clicking the KMSI check box they needed to log in less so they just did it. Even with the new experience whilst the option was available to revert to the old experience they did that. Now that option has disappeared they cannot do it (without visiting the old portal directly). The users are indicating that the Office 2010 HRD popup only started occurring recently but they cannot be 100% sure, as it may have been occurring since the new signin experience rollout but probably they have noticed more as they can no longer can set the KMSI option to supress it.
Thanks
Mar 01 2018 05:04 PM
Mar 02 2018 12:57 AM
Mar 02 2018 10:33 AM
Setting up this option seems to have resolved our issues. To be confirmed over the next week, but initial testing on premise, with Seamless SSO enabled, on W10 in Chrome, Firefox, IE and Edge looks positive.
If anyone needs the instructions to enable "Allow users to remember multi-factor authentication on devices they trust" they are here: https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-whats....
Mar 29 2018 06:39 AM
I'm having a slightly different issue. We don't use ADFS for our IdP, (we use PingFederate instead), and I've configured it to pass "true" for both the psso and insidecorporatenetwork claims when a user authenticates through our SSO. While I can see the SamlAttributes appear in the conversation with Azure, it doesn't seem to affect anything: I still get prompted for "keep me signed in" if I clear my cookies first, and no persistent cookies are ever dropped on my computer. Does Microsoft have any guidance for those of us not using ADFS but still wanting those persistent cookies placed? We also have users that claim the KMSI prompt never appears, so having the SSO system do it for them is ideal.
Apr 02 2018 04:36 PM
Apr 03 2018 09:50 AM
Apr 03 2018 06:06 PM
Apr 05 2018 08:55 AM
Hi Kelvin,
Following on from my former posts it seems now that the biggest issue now is the number of times internal users are prompted for authentication whilst accessing a site within our tenant that is shared externally.
On sites that are not shared externally the experience is that you can access a site authenticate and then close and reopen the browser several times without being authenticated again. (no KMSI option it just works)
But for sites that are shared externally every time the browser is closed the user needs to choose the "account pick" screen when re-accessing the site.
So two questions:
1. Are the settings handled differently for externally shared sites rather than sites with only internal user access?
2. Is there another option other than enabling PSSO (if this even works) as we have security concerns about issuing a PSSO token..
Thanks
Andy
Apr 11 2018 10:22 AM
Apr 11 2018 12:56 PM - edited Apr 11 2018 01:02 PM
Sorry I'm a little late to the party, but I just didn't have time back when the thread started and I kind of forgot about it. But now that I've read through all the 3 pages I'm chiming in with my issues:
Our SSO with Chrome and IE worked fine somewhere last year. Probably due to these changes it stopped working flawlessly, but not completely.
My setup consisted of configured Trusted Zones, ADFS on 2012R2 (I remember doing something to get this working for Chrome on ADFS 2 years ago), MFA exemption for onPrem IP Range, AAD-Connect and some URL tricks, like using the WHR parameter (https://login.microsoftonline.com/?whr=mycustomdomain.com)
Then it stopped working flawlessly, and degraded to having to click the pre-populated UPN and getting automatically signed in again after every browser closure.
I believe to have improved the experience, by dropping the WHR parameter, after which the users only had to click the pre-populated UPN about once a day.
This is also my current status, as far as I remember. I've noticed that when I leave my computer running over night (no standby) and return in the morning, I'm signed out of office.com or other pages. There is a sign in button on that office.com sign out portal and when I click it, I'm automatically signed in again after a few redirects without further input. A negative side effect of all this is, that on the first browser open any additional Sharepoint sites are not opened automatically, since the first site hasn't fully authenticated yet.
SSO seems wo work with no issues on my home computer (Mac/Safari) where I get all the KMSI and MFA prompts and I stay signed for multiple weeks.
By reading through everything here I'll start digging in into the ADFS configuration (and this article https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/ad-fs-single-sign-on-setti...), but I'll appreciate any shortcuts you guys have to offer :)
Aug 20 2018 02:21 PM
@Marc Debold does this new claim rule replace both the insidecorporatenetwork claim and the psso claim or is it in addition to them?
Sep 16 2018 11:09 AM
@Daniel Park wrote:@Marc Debold does this new claim rule replace both the insidecorporatenetwork claim and the psso claim or is it in addition to them?
I can't really remember (should have blogged it, darn!), but I suppose, it was a replacement, as it issues the PSSO when inside network condition is met.
Apr 01 2019 03:07 AM
@Michael Kostuch
Did you get any permanent solution for this? Meanwhile could you please explain the process of make this turn off at tenant app level.
Apr 01 2019 03:16 AM
Did you get permanent solution for this?
And could you please let us know the steps to get this change done at tenant app level from Microsoft.
Apr 01 2019 03:33 AM