AzureAD - Conditional Access Resilience defaults

What is resilience?

In the context of your identity infrastructure, resilience is the ability to endure disruption to services like authentication and authorization, or failure of other components, with minimal or no impact to your business, users, and operations. The impact of disruption can be severe, and resilience requires diligent planning.

What happens to AzureAD during an outage?

If there was an outage of the primary authentication service, the Azure Active Directory (Azure AD) Backup Authentication Service may automatically issue access tokens to applications for existing sessions. This functionality may significantly increase Azure AD resilience, because reauthentication's for existing sessions account for more than 90% of authentications to Azure AD. The Backup Authentication Service doesn't support new sessions or authentications by guest users.

For authentications protected by Conditional Access, policies are reevaluated before access tokens are issued to determine:

1. Which Conditional Access policies apply?
2. For policies that do apply, were the required controls are satisfied?

During an outage, not all conditions can be evaluated in real time by the Backup Authentication Service to determine whether a Conditional Access policy should apply. Conditional Access resilience defaults are a new session control that lets admins decide whether to block authentications during an outage whenever a policy condition cannot be evaluated in real-time or allow policies to be evaluated using data collected at the beginning of the user’s session.

?Important

Resilience defaults are automatically enabled for all new and existing policies, and Microsoft highly recommends leaving the resilience defaults enabled to mitigate the impact of an outage. Admins may disable resilience defaults for individual Conditional Access policies.

How does it work?

During an outage, the Backup Authentication Service will automatically reissue access tokens for certain sessions:

When an existing session expires during an #azuread outage, the request for a new access token is routed to the Backup Authentication Service and all Conditional Access policies are reevaluated. If there are no Conditional Access policies or all the required controls, such as MFA, were previously satisfied at the beginning of the session, the Backup Authentication Service issues a new access token to extend the session.

If the required controls of a policy weren't previously satisfied, the policy is reevaluated to determine whether access should be granted or denied. However, not all conditions can be reevaluated real time during an outage. These conditions include:

• Group membership
• Role membership
• Sign-in risk
• User risk
• Country location (resolving new IP or GPS coordinates)

Resilience defaults enabled

When resilience defaults are enabled, the Backup Authentication Service may use data collected at the beginning of the session to evaluate whether the policy should apply in the absence of real-time data. By default, all policies will have resilience defaults enabled. The setting may be disabled for individual policies when real-time policy evaluation is required for access to sensitive applications during an outage.

Example: A policy with resilience defaults enabled requires all global admins accessing the Azure portal to do MFA. Before an outage, if a user who isn't a global admin accesses the Azure portal, the policy wouldn't apply, and the user would be granted access without being prompted for MFA. During an outage, the Backup Authentication Service would reevaluate the policy to determine whether the user should be prompted for MFA.?Since the Backup Authentication Service cannot evaluate role membership in real-time, it would use data collected at the beginning of the user’s session to determine that the policy should still not apply. As a result, the user would be granted access without being prompted for MFA.

Resilience defaults disabled

When resilience defaults are disabled, the Backup Authentication Service won't use data collected at the beginning of the session to evaluate conditions. During an outage, if a policy condition cannot be evaluated in real-time, access will be denied.

Keep in mind

Disabling resilience defaults for a policy that applies to a group or role will reduce the resilience for all users in your tenant. Since group and role membership cannot be evaluated in real-time during an outage, even users who do not belong to the group or role in the policy assignment will be denied access to the application in scope of the policy. To avoid reducing resilience for all users not in scope of the policy, consider applying the policy to individual users instead of groups or roles.

Testing resilience defaults

It isn't possible to conduct a dry run using the Backup Authentication Service or simulate the result of a policy with resilience defaults enabled or disabled at this time. Azure AD will conduct monthly exercises using the Backup Authentication Service and the sign-in logs will display if the Backup Authentication Service was used to issue the access token.

Configuring resilience defaults

You can configure Conditional Access resilience defaults from the Azure portal, MS Graph APIs, or PowerShell. Below I only show how this can be done via the Azure portal.

Azure portal

1. Navigate to the?Azure portal?>?Security?>?Conditional Access
2. Create a new policy or select an existing policy
3. Open the Session control settings
4. Select Disable resilience defaults to disable the setting for this policy (see screenshot below). Sign-ins in scope of the policy will be blocked during an Azure AD outage
5. Save changes to the policy

Recommendations

Microsoft recommends enabling resilience defaults. While there are no direct security concerns, customers should evaluate whether they want to allow the Backup Authentication Service to evaluate Conditional Access policies during an outage using data collected at the beginning of the session as opposed to in real time.

Reference material can be found here