Governing when users receive authentication prompts when authenticating to Azure Active Directory (Azure AD) is depending on more than one setting, on which functionalities are in use and also in which scenario you authenticate (Browser, Modern clients or other). Reauthentication can take place by asking for a single factor, like password, FIDO,  the password less option in the Microsoft Authenticator app or by using Multi Factor Authentication (MFA)

So you might understand that how reauthentication must be configured really depends per company and per scenario, so luckily Microsoft provides options which you can configure.

Some examples:

• You want users to reauthenticate more often when they come from a non-managed or non-registered device
• You want users to reauthenticate more often when using a certain cloud application which you make available via Azure AD single sign on
• You might want some users in your organization to authenticate more often than others based on their risk profile

In this article I’m going to explain the different options available and where to configure what setting so that you can govern your own reauthentication settings.

Disclaimer: This post reflects the status of assigning groups to Azure AD roles as of October 21, 2020. Functionality may change, even right after this post has been published.

The settings which make up the experience

Azure AD has a default sign-in frequency of 90 days, this might seem like a long time but there are some scenario’s which require the user to sign in again, like:

• A change in the compliancy status of the managed device
• Disabling the account
• Revoking the sessions for the user
• Changing the password

Microsoft explains this default configuration as followed: “don’t ask users to provide their credentials if security posture of their sessions has not changed”, and also states: “If users are trained to enter their credentials without thinking, they can unintentionally supply them to a malicious credential prompt.“

Personally I think this default sign-in frequency makes sense when users work on managed devices, for other scenario’s some adjustments might be necessary.

Azure Multi Factor Authentication Settings

When configuring Multi Factor Authentication you have the option to remember the multi factor authentication on trusted devices. When configured, the option allows you to bypass verifications for a specified number of days.

When using the Browser this is achieved by setting a cookie which expires after the specified time. In the screenshot below this has been set to 7 days. 

Non-browser apps use refresh tokens with a default validity of 1 hour, while validating the refresh token the check for MFA is performed as well.

Microsoft recommends that you set this setting to 90 days, in line with the default sign-in frequency. If needed, you must revoke the MFA session to force the user to re authenticate using MFA.

Show option to remain signed in (KMSI)

Another option influencing the experience is the option “Show option to remain signed in, also known as “Keep me signed in (KMSI)” for which the configurable settings can be found in a really strange place, the Company Branding settings.

When users are presented with the Stay signed in option but abandon it, this is reflected in the Azure AD logging with a status of “Interrupted” and error code 50140.

Conditional Access

Conditional Access policies can be used to override some of the default settings in certain scenario’s. By using session controls you can control how users must authenticate in different scenarios.

Sign-in Frequency

By setting the Sign-in Frequency session control you can override the default setting of 90 days to a lower setting, you can do this for example if users access your Office 365 environment from a non-managed device via the Browser, in the screenshot above we have set a sign-in frequency for 1 day.

See: Policy 1: Sign-in frequency control for an example on how to create a Conditional Access policy leveraging the sign-in frequency session control.

Persistent Browser session

A persistent browser session setting controls if users remain signed in after closing and reopening their browser window. We have 2 options here, either “Always persistent” or “Never persistent”.

• This setting works correctly when “All cloud apps” are selected
• This does not affect token lifetimes or the sign-in frequency setting.
• This will override the “Show option to stay signed in” policy in Company Branding.
• “Never persistent” will override any persistent SSO claims passed in from federated authentication services.
• “Never persistent” will prevent SSO on mobile devices across applications and between applications and the user’s mobile browser.

See: Policy 2: Persistent browser session for an example on how to create a Conditional Access policy leveraging the “Persistent browser session” session control.

The scenarios which make up the experience

The scenarios under which users authenticate to your Azure AD environment are diverse, and you should understand which scenarios you will encounter and want to support within your organization. Below are some topics which should be considered when defining your scenarios.

Supported applications

This sign-in frequency works with applications that have implemented Open Authorization (oAuth2) or OpenID Connect (OIDC) authentication protocols, which is supported for most applications working with Azure AD. Sign-in frequency also works with applications implementing the Security Assertion Markup Language (SAML) protocol for authorization and authentication as well.

When working in a Microsoft 365 modern environment you can assume that the Office desktop and mobile apps will work, also accessing the Office 365 web portals will support this without any issue. When it comes to 3rd party applications it depends. For example if an applications drops its cookies for some reason and therefore redirects back to Azure AD, then the sign-in frequency can be less.

Non registered devices

If you work on devices which are not registered in Azure AD, it might also be that applications running on top of that device are not sharing their oAuth refresh token with each other, requiring the user to authenticate multiple times.

Azure AD joined or Registered devices

Devices which are either Azure AD Joined, or Active Directory Joined/Azure AD registered via Hybrid AD join receive a so called Primary Refresh Tokens (PRT) allowing them to use this token for Single Sign-on (SSO) functionality. A PRT is valid for 14 days and continuously renewed (every 4 hours at least) as long as the user actively uses the device. For more information about how the PRT works, I suggest to read the following article: “What is a Primary Refresh Token?” on the Microsoft website.

Managed devices

Managed devices are devices on which you can measure compliance using Microsoft Endpoint Manager/Intune. Even though these devices are also registered, you also have the option to measure whether other security requirements are met, like for example BitLocker and Secure Boot being enabled on the device.

Browser used

Which browser is used is an important factor when determining the scenarios. Is the browser being used an old browser like Internet Explorer, or a modern browser like Google Chrome, the new Microsoft Edge and Mozilla Firefox

Google Chrome

In order for the Google Chrome browser to support the device authentication you must deploy the Windows 10 accounts extension in the Chrome browser to your devices. You’ll need this extension for example if you want to check on whether the device is compliant in one of your Conditional Access policies.

Mozilla FireFox

Mozilla Firefox isn’t a supported browser when it comes to Conditional Access. If you configure a conditional access policy enforcing App Enforced Restrictions for example, you will experience these restrictions even when working on a compliant device. See the following article for more details on how to configure this CA policy: Limit Access to Outlook Web Access, SharePoint Online and OneDrive using Conditional Access App Enforced Restrictions 

Microsoft Edge

Microsoft Edge obviously supports device authentication, but whether this is being used is depending on the profile you are signed into. When you’re signed into a Microsoft Edge profile with enterprise Azure AD credentials, Microsoft Edge allows seamless access to enterprise cloud resources protected using Conditional Access. On a compliant device, the identity accessing the resource should match the identity on the profile. See: Accessing Conditional Access protected resources in Microsoft Edge for more information.

Default settings when creating a new tenant

When you create a new tenant today, the following default settings are available.

Multi factor authentication

Multi Factor Authentication by default is configured to not remember MFA on devices people trust. If you enable the setting the default number of days is set to 90 days.

Show option to remain signed in

By default in a new tenant, Company branding is not enabled and therefore the setting “Show option to remain signed in” is off.

Conditional Access

A new tenant doesn’t have any Conditional Access policies configured. In the tenant I provisioned even the default security settings weren’t applied, but that can have something to do with the fact that I used a temporary tenant which was already hydrated.

The Default Security settings provide the following settings by default.

• Requiring all users to register for Azure Multi-Factor Authentication.
• Requiring administrators to perform multi-factor authentication.
• Blocking legacy authentication protocols.
• Requiring users to perform multi-factor authentication when necessary.
• Protecting privileged activities like access to the Azure portal.

For more information, see: Microsoft deprecates Conditional Access baseline policies in favour of Security Defaults, here is what you need to know and do

Bringing it all together

So now that we know the different options on how to configure reauthentication behavior and have an idea of the different scenarios we can face we can start designing our reauthentication scenarios.

Managed devices

For MDM managed devices, having the option to measure compliance gives us options to check whether the device is secure. Because of this I would advise to keep the defaults of the supplier in this case to keep the sign-in frequency to 90 days. MFA

Managed applications

For applications which you manage using Mobile Application Management (App Protection Policies) you can set a more strict sign-in frequency policy. For example set this 7 days using a Conditional Access policy.

Non-managed devices

On non-managed devices (devices not compliant or not hybrid AD joined), especially when accessing the environment using the web browser (which is at this moment the real manageable option to keep your company data protection IMHO), you should even set a more restrict sign-in policy and also disable browser persistence. An example would be to set the sign-in frequency to 1 day/4 hours and disable browser persistence.

Microsoft also provides some recommended settings depending on whether you have Azure AD Premium yes or no, which you can find here: Recommended settings

Conclusion

Understanding how reauthentication within an Azure Active Directory environment works is crucial if you want create a solid design for implementing security measures related to authentication. I hope this article has shed some light, knowing that there might be other scenario’s as well. F.e. while writing this article I didn’t take into account environments using Federation with Active Directory environments.

Things can become even more interesting once Azure AD continuous access evaluation is fully available, since this allows us to react faster is the scenario changes, f.e. user switches from trusted to untrusted network. See: Azure AD Continuous access evaluation (CAE), a first look for more information.

References

Below are some of the references used to write this article:

• Optimize reauthentication prompts and understand session lifetime for Azure Multi-Factor Authentication – https://docs.microsoft.com/en-us/azure/active-directory/authentication/concepts-azure-multi-factor-authentication-prompts-session-lifetime
• What is a Primary Refresh Token? – https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token
• Configure the ‘Stay signed in?’ prompt for Azure AD accounts – https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/keep-me-signed-in
• Configure authentication session management with Conditional Access – https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime
• Azure AD registered devices – https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-azure-ad-register
• Accessing Conditional Access protected resources in Microsoft Edge – https://docs.microsoft.com/en-us/deployedge/security-overview#accessing-conditional-access-protected-resources-in-microsoft-edge
• Enable passwordless sign-in with the Microsoft Authenticator app (preview) – https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-phone