Sep 19 2017
- last edited on
Jul 24 2020
A common request we get from our customers is to reduce the number of times users are prompted to sign into Azure AD. One way to reduce the frequency of prompts is to check the “Keep me signed in” checkbox on the sign-in flow, but our telemetry shows that usage of that checkbox is very low. But we know from talking to customers, that cutting down on the number of sign-in prompts is REALLY important. Nobody wants to have to sign-in to an app multiple times!
So today I’m happy to share that we’re improving how “Keep me signed in” option is shown to users. We’re also adding intelligence to ensure users are prompted to remain signed in only when it’s safe to do so.
Read about it in the Enterprise Mobility & Security blog.
Sep 19 2017 08:21 PM
and you thought replacing a simple checkbox with an extra annoying pop up dialog box is good because of what again?! people want to move away from sign in page as quickly as possible, even having separate dialogs for username and password was something "interesting". now you added the 3rd one?!
Sep 21 2017 10:18 AM
Sep 22 2017 04:45 AM
actually we would like to enable this setting for all users as it improves the user experience and allows us to get rid of the additional pop-up. In a recent case we found that this setting can not be controlled by GPO etc. Are you planning to add this option ?
Sep 22 2017 01:32 PM
Sep 23 2017 01:58 AM
Something that is not clear to me is how this interacts with ADFS?
Does it makes a difference if you tick the checkbox before one is redirected to the internal ADFS log in page upon entering his UPN.
I don't know if your telemetry also shows how many users quickly thicking the box after entering their UPN and the browser is already starting to redirect to the internal ADFS log in page.
Sep 25 2017 11:31 AM
Oct 02 2017 11:23 AM
Oct 02 2017 03:40 PM
Oct 04 2017 11:22 AM
Thanks for yor reply..
OK, I was able to get the new log on option back for OWA.
Unfortunately it doesn;t seem to be working any differently that the old version.
I was logged off from OWA again today.
FYI I work remotely for several sites
So I don't use the full Outlook client, but instead keep in touch thru multiple OWA sessions in IE.
What I've noticed...
I ONLY have problems with sites who are running Office 365.
- Never have issues staying logged on with sites that maintain Exchange/SMTP on site.
- So I am guessing the root cause for not being able to stay logged on?
i.e. is out of local admins control, issues are "baked into" Office 365 or the admins at MS have disallowed staying logged on?
Easy for me to be suspicious when 3rd party administation could be involved.
One of the reasons why Office 365 still hasn't won me over.
Oct 05 2017 02:09 PM
Hi there Bruce - My name is David Los, I work on the Outlook on the Web team. For Office 365 Tenants, there is a default activity timeout of 6 hours, that is set for all tenants (https://support.office.com/en-us/article/Session-timeouts-for-Office-365-37a5c116-5b07-4f70-8333-5b8... And admin can configure that or disable the Activity timeout if they desire. If a user selects KMSI, they should not be hitting the activity timeout.
If you are experiencing something different, I recommend reporting the feedback from within OWA. Click the question mark at the top/and select feedback.
Thanks for the feedback
Nov 06 2017 03:41 PM
Is there a way to force my tenant to the new login experience? If not what is the current timeframe for when this will be rolled out?
Nov 29 2017 12:05 PM
I "regularly" log on as a different user on this machine for testing purposes. As per this blogpost this appears to have disabled the "Stay signed in?" prompt for my user.
Is there any way to stop Microsoft from thinking that this is a shared device? Having to log on -every- time is pretty frustrating. Especially as I have MFA enabled.
Dec 02 2017 06:17 PM
Dec 06 2017 04:42 AM
Kelvin, could you share any additional information about the shared device logic? I receive the additional keep me signed in prompt when using google chrome but it will not appear for me in IE, nor for any of my colleagues in the office.
Is there any particular setting that it could be picking up from IE?
Dec 06 2017 10:58 AM
Feb 21 2018 04:04 AM
We are experiencing an issue with the KMSI feature for IE11 only. We currently use ADFS 3.0 with Single Sign on. When users connect to services such as the office portal or SharePoint they are prompted to select there account, after which the service signs in. The issue is that the KMSI prompt is not presented to the users in the new experience. Within the old experience users were able to check the box to remain signed in.
What's strange is that from testing in other browsers such as Edge or Chrome we receive different results. In Edge users are redirected to the old sign-in experience where they can check the box. For Chrome, they again are taken to the old experience sign-in screen, but after entering there credentials they are redirected to the new KMSI prompt which can be selected and keeps the user signed in.
From our on-prem ADFS server we have enabled the KMSI feature, this has also been configured from the Azure Tenant level within the company branding section.
Any help would be greatly appreciated.
Feb 21 2018 07:30 AM
We have ADFS and Single Sign On working through IE with the "Automatically logon only in Intranet zone" set.
Our users don't get the final option for Keep me signed in, which would be ok if only the first Pick an account window also did not show. This seems like a pointless prompt because if I select Use another account and then enter email@example.com it will still sign in with the currently logged on user. So if this is the behaviour, why do we have the option to pick an account for SSO enabled browsers when it just appears to ignore it?
A better user experience for SSO-enabled browsers would be to not show the first prompt, and just log the user straight in. Alternatively - although less preferred - is to give them the prompt to allow them to stay logged in. Having the first prompt really defeats the purpose of SSO.
Feb 21 2018 02:59 PM
Feb 21 2018 03:18 PM