TODO: Move from the ‘Allow users to remember multi-factor authentication on devices they trust’ option to Conditional Access

Azure Multi-factor Authentication

Last month, I made the case to move from per-user MFA to Conditional Access to leave behind the remnants of the PhoneFactor infrastructure, presented as old pages linked to from the Azure Portal.

Today I want to talk about the ‘Allow users to remember multi-factor authentication on devices they trust’ option, that allows administrator to specify a number of ‘Days before a device must re-authenticate (1-60):

RememberMFA

I see many organizations using this option, believing that it helps their people with less authentication prompts. Often, the setting is set at 14 days, as seen in the above screenshot.

 

Why you’d want to move away from ‘Allow users to remember MFA on devices they trust’

As documented by Microsoft in its Optimize reauthentication prompts and understand session lifetime for Azure Multi-Factor Authentication page, this setting can have negative side-effects through its persistent cookie:

  • It overrides the ‘Keep me signed in’ (KMSI) setting in Company Branding. Therefore, it prompts for re-authentication more often than when the setting is not configured.
  • It overrides the default behavior for modern authentication clients (like Microsoft Outlook) who only prompt every 90 days, by default.

 

Why you’d want to use Conditional Access

Conditional Access is fast becoming the one-stop-shop for all Microsoft Cloud authorization decisions. Switching from the ‘Allow users to remember multi-factor authentication on devices they trust’ option to Conditional Access, allows Azure AD admins to:

  • Set persistent cookies per Microsoft Cloud application, Azure AD-integrated application and Azure AD Application Proxy-published application, allowing for fine-grained ‘Remember multi-factor authentication’ settings
  • Leave the ‘Keep me signed in’ (KMSI) world behind, where people in the organization need to tick the box themselves at the Stay signed-in? screen. Now, an admin controls this behavior centrally.

 

Why you might not want to make the switch

One of the big differences between the ‘Allow users to remember MFA on devices they trust’ option and Conditional Access, is that the option is available even for Azure AD Free tenants, while Conditional Access requires Azure AD Premium licenses for people in scope.

As Enterprise Mobility + Security E3, E5, Microsoft 365 Business Premium, Microsoft 365 Business Premium Free (for non-profit organizations), Microsoft 365 Enterprise F1, F3, E3, E5 and Microsoft 365 for Education A3, A5 all contain Azure AD Premium P1 licenses, most organizations will be ready to go with Conditional Access.

 

How to make the switch

Switching from the ‘Allow users to remember MFA on devices they trust’ option to Conditional Access requires three actions:

  1. Disable the ‘Allow users to remember multi-factor authentication on devices they trust’ option
  2. Create the corresponding Conditional Access policy that defines the same coarse-grained ‘Persistent browser session’ control
  3. Tweak your Conditional Access policies to define the optimal session control settings for your organization’s use cases

 

Disable the ‘Allow users to remember multi-factor authentication on devices they trust’ option

First, we disable the ‘Allow users to remember multi-factor authentication on devices they trust’ option. As this setting overrides all other settings, we need to clear it first. Perform these actions:

  • Start a browser and navigate to the Azure AD Portal.
  • Sign in with an account with Global Administrator privileges.
    Perform multi-factor authentication when prompted.
  • In the left navigation menu, click Azure Active Directory.
  • In Azure AD’s navigation menu, click Security.
  • In the Security navigation menu, click on MFA under Manage.
  • Follow the Additional cloud-based MFA settings link in the main pane.
    A new tab or browser window opens.
  • In the remember multi-factor authentication (learn more) area, clear the option labeled Allow users to remember multi-factor authentication on devices they trust if it is enabled.
  • If the option was enabled, note the number of Days before a device must re-authenticate (1-60):. We’ll use this value when we create the Conditional Access policy to mimic the option.
  • Click the save button at the bottom of the screen.
  • Close the browser tab, or window to go back to the Azure Portal.

 

Create the corresponding Conditional Access policy

Off course, now the Azure AD tenant operates with default settings. We need to address this issue by creating the same coarse-grained policy through Conditional Access as our new starting point. Perform these actions:

  • While still signed in to the Azure AD Portal, navigate back to the main Azure AD Tenant level or the Security level through the bread crumbs in the top bar of the Azure Portal.

Note:
If you’ve closed the browser window, or only want to perform this part of the steps, complete steps 1 through 4 of the steps for disabling the ‘Allow users to remember multi-factor authentication on devices they trust’ option above.

  • In the Security navigation menu, click on Conditional Access.
  • In the Conditional Access | Policies main pane, click the + New policy link in the top action bar.
    The New pane appears.
  • In the Name field, enter a name for the Conditional Access policy following your organization’s naming policy for policies.
  • Under Assignments, click on the 0 users and groups selected status for Users and groups.
  • Select the All users option.
  • Under Assignments, click on the No cloud apps or actions selected status for cloud apps or actions.
  • Select the All cloud apps option.
  • Then, under Access Controls, under Session, click the 0 controls selected link.
    The Session blade opens
  • On the Session blade, select the Sign-in frequency option. This option defines the time period before a user is asked to sign-in again when attempting to access a resource. The default setting is a rolling window of 90 days, i.e. users will be asked to re-authenticate on the first attempt to access a resource after being inactive on their machine for 90 days or longer.
  • In the first field enter the number of days for the Days before a device must re-authenticate (1-60): option that we’ve noted in step 8 of the previous set of steps.
  • In the second field, select Days from the drop-down list.

ConditionalAccessSessionControls

  • On the Session blade, also select the Persistent browser session option. This option enables persistent browser session in which users remain signed in after closing and reopening their browser window. This setting works correctly when All cloud apps are selected, does not affect token lifetimes or the sign-in frequency, but will override the Show option to stay signed-in policy in Company Branding.
  • In the Persistent browser session field, select Always persistent from the drop-down list.
  • Click Select at the bottom of the blade to save the control.
  • At the bottom of the New pane, under Enable policy, select On.
  • Click the Create button.
    You will be linked back to the Conditional Access | Policies pane
  • In the right top corner of the Azure AD Portal, click on the accounts name or profile picture and click on Sign out from the context menu.
  • Close the browser.

 

Tweak your Conditional Access policies

The main reason to switch from from the ‘Allow users to remember MFA on devices they trust’ option to Conditional Access, of course is to have fine-grained control over the frequency we want people in the organization to sign-in.

By creating more Conditional Access policies, creating exceptions on the above Conditional Access policy for specifics (groups of) users and delivering different Persistent browser settings and Sign-in frequency settings, the experience for people in the organization can be tailored to their needs and expectations.

 

Concluding

One by one, the settings in the legacy PhoneFactor pages is being replaced by better alternatives within the Azure Portal.

11 Responses to TODO: Move from the ‘Allow users to remember multi-factor authentication on devices they trust’ option to Conditional Access

  1.  

    Hi,

    I think it's worth noting that by moving "Allow users to remember multi-factor authentication on devices they trust" from per-user to Conditional Access that "device trust" is no longer selective but enforced. This may not be desirable, say for administrative accounts where you want to prompt for MFA on every sign-in or you simply want the choice based on the device you're signing in from.

    I'd like to see some guidance from Microsoft on this, along with their recommendations for migrating these settings to Conditional Access. As I review their documentation for configuring MFA I'm getting mixed messages as it relates to this. In one instance they say the recommendation is to configure MFA via Conditional Access, yet they direct you to per-user service settings for the Remember MFA.

    https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates
    https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-mfasettings#remember-multi-factor-authentication

  2.  

    Awesome Post!! Really helped in my understanding of the difference between MFA Remember and CA Sign-In Frequency as this wasn't clear to me.

    Does this mean that with both the Sign-In Frequency Set to lets say 40 Days AND Persistent browser session set to Always persistent… it would be that a user will:

    1. sign-in first time and be prompted for MFA

    2. User will not be prompted to re-authenticate for 40 days for both Apps AND web apps?

  3.  

    Does this mean that you must create 2 conditional access rules?

    The first one with the grant control of mfa and another identical one with the session control?

    Or I can just add the session control configuration to my existing grant mfa conditional access rule

    If I must create another rule just for this, it makes really difficult to manage as rules can be complex, with exceptions and conditions and you must remember to update both of them

    • Hi Christian,

      The recommended practice is to create a Conditional Access policy per use case.

      If your 'Require MFA' policy applies to all, than you can go ahead and add the session control to the same policy.
      However, if you want the session control to apply to some, but not all; you create a different Conditional Access policy for that use case.

       
  4.  

    Hi Sander,

    We've been successfully using Conditional Access and have 2 different CA profiles.
    1 for browser and one for non-browser access.

    Any idea why applications like onedrive or Teams on desktop still ask for a mfa and dont honer the x days sign-in frequency?

    (I assume the "Show option to remain signed in" below company branding is not needed anymore?)

    • Hi Bart,

      Several applications behave differently than you'd expect.
      For instance, the Microsoft Teams desktop app acts like a web browser, and not always an up to date one.
      Furthermore, with every update, Teams may behave differently to pre-existing Conditional Access policies. Testing policies often is required when creating differences between devices and device capabilities.

       
    • I assume the "Show option to remain signed in" below company branding is not needed anymore?

      Persistent Browser Session configuration in Azure AD Conditional Access will overwrite the “Stay signed in?” setting in the company branding pane in the Azure portal for the same user if you have configured both policies.
      Source: Microsoft Docs

       
  5.  

    Hey, Sander. Is the below scenario possible?

    I'd like for login requests coming from a certain IP range to have MFA timeouts of 180 days. For all other IPs, I'd like the MFA timeout to be 1 day.

    • Hi Jason,

      You can differentiate between the IP addresses using a named location.
      You could create two Conditional Access policies; one policy that applies to sign-ins from the named location (included), and one with the named location excluded.
      Then, in theory, when you do not specify session controls in other policies, the two policies you create will dictate the time-outs.
      When you also enable 'Always persistent' for the the Persistent browser session options, in theory, the time-out would survive browser restarts.

      However, (older versions of) apps may be hard-coded with their own time-outs, and this is where your 180 days time-out might be limited, in practice.

       
  6.  

    I look after a non-profit tenant which doesn't have AAD Premium licenses and this would move the feature behind the CA paywall.

    • Hi Stefan,

      For eligable non-profit organizations, Microsoft Partner Techsoup offers discounted prices for subscription licenses.
      Right now, your organization may have picked an Office 365 subscription plan. If you switch to the Microsoft 365 Nonprofit E3 (USD8 per month per user) plan, Azure AD Premium is included. If your purchasing options with TechSoup allows to puchase additional EMS Nonprofit E3 licenses (USD2,20 per month per user), you gain Azure AD Premium as well as Microsoft Intune, Information Protection and Defender for Identity.

       

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.