Managing Azure AD’s Keep Me Signed In (KMSI) Feature

Feature Can Suppress Sign-in Prompts

Azure AD’s Keep Me Signed In (KMSI) feature uses a persistent cookie to allow users with member accounts in the tenant directory to close and resume browser sessions without needing to sign in again. Azure AD generates the persistent cookie if a user responds affirmatively to the Stay signed in? prompt after a successful authentication (Figure 1). Azure AD uses the persistent cookie to extend the user session (and thus avoid sign-in prompts) and revokes the cookie only after the user signs out.

According to Microsoft’s documentation, Azure AD shows the KMSI prompt only when “it can benefit the user” and doesn’t prompt guest accounts, if Azure AD considers the sign-in risk score to be high, if persistent browser session control is configured in a conditional access policy, and if accounts sign in via SSO or AD FS.

The Value of KMSI

I understand the value of KMSI for users who work with Microsoft 365 apps through browser sessions. Some applications, like Planner, don’t have desktop clients, so you’re forced to use browser or mobile clients. SharePoint Online and OneDrive for Business are also in this category. However, if a high percentage of user interaction with these workloads is through Teams, I wonder how important persistent connectivity is for their browser sessions.

Overall, given the influence of Teams and mobile clients, the argument for facilitating persistent browser sessions weakens. A good case is arguable that it is better to disable KMSI and force users to reauthenticate if they close the browser as this removes the possibility of compromise should an attacker be able to access a workstation. Requiring reauthentication when opening a session to a Microsoft 365 application seems to take the proactive approach to security endorsed by Microsoft in their Zero Trust model. It also seems to be aligned with recent developments such as enabling continual access evaluation for critical Azure AD events in all Microsoft 365 tenants. In a nutshell, it might be true that KMSI is not as valuable as it once was.

Disabling KMSI

Unless you deploy conditional access policies to control browser session persistence, KMSI is either on or off for everyone in a tenant. If you decide to disable KMSI, the way to do so is through Azure AD company branding. Tenants with Azure AD Premium or Office 365 licenses can customize different graphic elements displayed on user sign-in screens, such as the background screen. Company branding is one of those often overlooked features that every tenant should use (Figure 2).

To apply custom branding, go to the Company branding section of the Azure AD admin center. You can then create elements for the default locale or for individual language-specific locales. Azure AD applies the default locale if custom elements aren’t available for a user’s selected language.

Applying custom branding is straightforward and requires just a few graphic files (PNG preferred, JPEG works fine):

• A background image (1920×1080 pixels). This is the type of image used in Figure 2.
• A banner logo (280×60 pixels). This is the type of image used at the top of the Enter password screen in Figure 2.
• Square logo (240×240 pixels). This image appears elsewhere, like the bottom of email notifications sent when users share files.

Azure AD replaces its standard images with the custom images defined in company branding Figure 3 shows the properties for company branding applied to my tenant. The important point for this discission is that the option for users to remain signed in is off (at the bottom of the screen).

When you disable KMSI, Azure AD notes:

Important: some features of SharePoint Online and Office 2010 have a dependency on users remaining signed in. If you hide this option, users may get additional and unexpected sign in prompts.

Given that Microsoft 365 no longer supports Office 2010, you can safely ignore that warning. I cannot find precise details of what SharePoint Online features the removal of KMSI affects, but so far, I have experienced few problems since I removed KMSI. OWA signs out automatically after a period of inactivity and sometimes users need to reenter credentials to keep a SharePoint Online session active, but that seems to be all. The rebuttal is that signing out and forcing users to reauthenticate after they leave browser sessions inactive for a while is a good thing. It’s less convenient for the users, but more secure for the organization,

It’s possible that the Azure AD warning is old and reflects concerns when Microsoft revamped the KMSI implementation in 2018. Although improvements in Azure, federation, and SharePoint Online since 2018 might have eliminated some or all of the difficulties reported in this Microsoft Technical Community discussion, it’s still worth reading to understand some of the complexities involved in authentication.

I obviously can’t test every authentication flow in use by tenants, so it’s important that anyone considering disabling KMSI should conduct a full suite of tests to validate whether this action causes problems for users.

Prioritizing Administrative Effort

One of the joys of working in the Microsoft 365 ecosystem is that there’s always something to investigate and debate. Disabling KMSI is probably an easier decision for cloud-only tenants. Hybrid deployments invariably introduce complications, especially in authentication. In those scenarios, it might be best to leave KMSI in place as there’s probably more urgent matters to deal with than plunging into the minutiae of testing authentication pathways.

---

Make sure that you’re not surprised about changes which appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.