Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community

The new Azure AD sign-in and “Keep me signed in” experiences rolling out now!

Community Manager

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.

 

Slide1.PNG

 

Read about it in the Enterprise Mobility & Security blog.

121 Replies
Hi Andy, a quick clarification - are you reporting that the "Pick an account" screen is showing up for you now but it didn't before? If so, can when did it start showing?
Hi Kelvin,

Yes the pick account screen is appearing this started showing in the last 2 weeks or so according to the users. The main issue is this appears each time an office 2010 user opens an office document from SPO. A workaround is to visit the old login page and check the KMSI option but this is far from ideal. When opening a document the pick an account screen appears, if users click the page they are authenticated to ADFS and the document opens, but this occurs each time a document is opened. There is no issue with office 2016 but we have thousands of office 2010 users who are not updated to 2016 yet.

Thanks
One more question - With the old login page, if your users did *not* check the KMSI option, were they also prompted to click on their username each time? Did you train all your users to always check the KMSI option on the old login experience?

@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.

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

 

Hi Marco,

sorry for the delay. I had to sync with the Seamless SSO team to understand what's going on.

The correct way to ensure the user isn't always prompted with MFA when Seamless SSO is set up is for the user to check the "Don't ask me again for <x> days" checkbox on the MFA screen. This suppresses MFA for the duration called out. Note that <x> can be configured on MFA.
Hi Marc, We're trying it out. Many thanks!

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....

 

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.

Azure AD does respect the PSSO claim even when it comes from a source besides ADFS. So, it should work in your case. I would recommend that you contact Microsoft support to take a look at what's going on.
To make sure I understand, sending the PSSO claim should suppress the "Keep Me Logged In" question from SharePoint Online and drop the persistent SPO cookies in my browser automatically, correct? MS Support seems stymied for the moment on this one.
To be accurate: Sending the PSSO claim will suppress the KMSI prompt (since it's not needed as PSSO essentially says "Yes" to that question), and drops a persistent Azure AD token in your browser. SPO will use that persistent token.

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

 

From your description, it doesn't sound like PSSO is set up correctly, or it could be due to an interaction with some external site settings (as you pointed out).

I'm not familiar with how SharePoint handles internal vs external sites. I would recommend that you contact Office 365 or SharePoint support to help you with that. They would be the best resource to help you here.

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 :)

@Marc Debold does this new claim rule replace both the insidecorporatenetwork claim and the psso claim or is it in addition to them?


@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.

@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.

@Michael Kostuch 

 

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.

What is the parameter you added, to make this change at tenant app level rather than global company branding level.