Information Technology Navigator

Secure access to email and other business productivity tools continues to be a top priority for IT administrators. Microsoft services, such as Azure Active Directory and Office 365, use OpenID Connect for authentication and OAuth 2.0 for authorization. Here’s how that process works: When Outlook connects to Exchange Online, the API requests are authorized using OAuth 2.0 Access Tokens. They are valid for one hour. When the tokens expire, the Outlook client is redirected back to Azure AD to refresh them. This provides an opportunity to re-evaluate policies for user access. If a user has been disabled in the directory or because of a Conditional Access policy, the admin might choose not to refresh the token.

Continuous Access Evaluation to the Rescue

While token refresh and expiry are a tried-and-true mechanism, it was not enough to reduce security risks and concern around the lag between when risk conditions change for a user and when policies can be enforced related to that change. This is where Continuous Access Evaluation (CAE) comes to the rescue.

Microsoft now leverages OpenID’s Continuous Access and Evaluation Protocol. This new approach to cybersecurity utilizes a user’s online footprint, collected through an exchange of security events and signals between Azure AD and Relying Parties (Resource Providers), to reauthorize or terminate access.

This provides significant improvements for security across Microsoft services.

This blog provides an overview of how using the CAE Protocol can help deliver Zero Trust to Microsoft services by providing signals and events as input to machine learning, addressing current challenges around continuous access to online resources.

A timely response to policy violations or security issues really requires a “conversation” between the token issuer - Azure and the relying party such as Exchange Online.

This two-way conversation gives us two important capabilities:

1. First, the relying party can notice when things have changed (e.g., client coming from a new location) and notify the token issuer.
2. Second, it gives the token issuer a way to tell the relying party to stop respecting tokens for a user due to account compromise, disablement, or other risks.

CAE is the mechanism for this conversation. Here’s how Azure AD’s converses with relying parties: 

• Relying parties (aka resource providers), like Exchange Online and Teams, subscribe to critical events from Azure AD.
• The relying party knows that it should respond to future requests from the impacted client by telling the client to get a new token from Azure AD.
• Doing this requires the client recognize the new response type and handle it appropriately. This is why only client applications that have implemented the flow can benefit from the behavior.

And Relying parties converse with Azure AD: 

• Relying parties can synchronize key policy elements and notify Azure AD if the client varies from the terms of that policy. For example, if the policy is specific about the network the client must be located on and the IP address of the client changes, the relying party can determine whether to redirect the client to Azure AD to reissue a token.

Because CAE security benefits were so great, Microsoft’s initial implementation was rolled out to Exchange, Teams and SharePoint (OneDrive) in April 2020. Initially, this feature was only for tenants with no Conditional Access policies.

A Deeper Dive on How CAE Works

Before CAE, clients would try to replay the access token from its cache, as long as they hadn’t expired. CAE introduces a new case where a resource provider can reject a token even when it is not expired.

In order to inform clients to bypass their cache even though the cached tokens have not expired, Microsoft introduced a mechanism called claim challenge to indicate the token was rejected, and required that a new access token be issued by Azure AD.

CAE requires a client update to understand the claim challenge. The latest versions of Outlook, Teams and Office on - Win, Mac, iOS, Android, support claim challenge. When the access token’s been revoked or the API detects an IP address change, a 401 status and a WWW-Authenticate header containing a Claims Challenge is sent from the API. The client application uses this information to acquire a new access token.

The app checks for:

• the API call returning the 401 status
• the existence of a WWW-Authenticate header containing:
  • an "error" parameter with the value "insufficient_claims"
  • a "claims" parameter

When these conditions are met, the app extracts and decodes the claims challenge.

Token Lifetime

The second level of security CAE provides is through token lifetime changes. Because risk and policy are evaluated in real time, clients that negotiate continuous access evaluation aware sessions will rely on CAE instead of existing static access token lifetime policies. Since revocation is driven by critical events and policy evaluation, and not just an arbitrary time period, Token lifetime is increased to up to 28 hours in CAE sessions.

This change greatly increases the stability of applications without affecting security posture. In situations where Continuous Access Evaluation-capable clients are not being used the default access token lifetime will be 1 hour unless token refresh and session lifetimes have been configured. (Configurable token lifetimes will be going away Jan 2021, replaced by sign-in frequency in Conditional Access)

CAE is implemented by enabling Exchange Online, SharePoint Online, and Teams to subscribe to critical events in Azure AD so those events can be evaluated and enforced near real time. There are two scenarios that make up continuous access evaluation: Critical Event Evaluation and Conditional Access Policy Evaluation

Critical Event Evaluation

Critical Event Evaluation enables a scenario where users lose access to SharePoint files, Exchange email, calendar, or tasks, and Teams from Microsoft 365 client apps within minutes after one of these critical events.

User revocation event flow:

1. A CAE-capable client presents credentials or a refresh token to Azure AD asking for an access token for a resource.
2. An access token is returned.
3. An Admin explicitly revokes all refresh tokens for the user triggering a revocation event to be sent to the resource provider from Azure AD.
4. An access token is presented to the resource provider. The resource provider evaluates the validity of the token and checks whether there is a revocation event for the user and using this information, decides whether to grant or deny access to the resource.
5. In this case, the resource provider denies access, and sends a 401+ claim challenge back to the client.
6. The CAE-capable client understands the 401+ claim challenge. It bypasses the caches and goes back to step 1, sending its refresh token along with the claim challenge back to Azure AD. Azure AD will then reevaluate all the conditions and prompt the user to reauthenticate in this case.

Conditional Access Policy Evaluation

In the second scenario for Conditional Access policy evaluation, Exchange and SharePoint are able to synchronize key Conditional Access policies so they can be evaluated within the service itself. This process enables the scenario where users lose access to SharePoint files, Exchange email, calendar, or tasks from Microsoft 365 client apps, Exchange Outlook on the web or SharePoint Online immediately after network location changes. Not all app and resource provider combinations are supported for this scenario.

For this scenario, imagine that a user leaves the company network and joins the guest network in the building’s public café area. All locations outside of corporate are blocked.

A Conditional Access Policy has been implemented to block all non-enterprise networks: 

1. Assignments

• User and groups: Corp Users group
• Cloud apps or actions: All cloud apps
• Conditions: Select include any location

1. And excludes all trusted locations. 
2. Access controls
• Select Block access and enable the policy.

User condition change flow (Preview)

1. A CAE-capable client presents credentials or a refresh token to Azure AD asking for an access token for some resource.
2. Azure AD evaluates all Conditional Access policies to see whether the user and client meet the conditions.
3. An access token is returned.
4. The user moves out of an allowed IP range
5. The client presents an access token to the resource provider from outside of an allowed IP range.
6. The resource provider evaluates the validity of the token and checks the location policy synced from Azure AD.
7. In this case, the resource provider denies access, and sends a 401+ claim challenge back to the client because it is not coming from an allowed IP range.
8. The CAE-capable client understands the 401+ claim challenge, bypasses the token cache and goes back to step 1, sending its refresh token along with the claim challenge back to Azure AD.

Azure AD reevaluates all the conditions and will deny access in this case.

Supported Services and Clients

• Outlook on the Web, Outlook and Office desktop apps are supported for SharePoint and Exchange Online.
  • However, Office web apps are not supported at this time.
• Outlook for iOS and Android support Exchange Online but NOT SharePoint Online.
• Both SharePoint and Exchange online are supported for iOS and Android Office apps.
• Outlook and Office on Mac apps are supported for SharePoint and Exchange Online.

CAE (Preview) for tenants with Conditional Access policies is now available for tenants as of October 2020.

1. To enable this feature for Conditional Access policy evaluation; in the Azure portal under Azure Active Directory > Security > Continuous access evaluation and select Enable preview and Save.
2. Once enabled, you can optionally limit to users and groups only subjected to the preview.

Caveats

There are a few caveats worth noting.

• Supported location policies: Microsoft only has insights into named IP-based named locations. Insight into other location settings like MFA trusted IPsor country-based locations are not available. CAE will not be enforced after users from these locations move to a different location. In those cases, a 1-hour CAE token will be issued without instant IP enforcement check.
• IP address configuration: Azure AD sees one IP address from the client that is part of an allowed IP range in policy, but the resource provider sees a different IP address from the client after passing through a proxy. For example: due to network proxy implementations – Netskope CASB, etc. If this scenario does exist, to avoid infinite loops Azure AD issues a one-hour CAE token and doesn’t enforce client location change. Even in this case, security is improved compared to traditional one-hour tokens since the other events besides client location change events are still being evaluated.
• Policy change timing: Due to the potential of replication delay between Azure AD and resource providers, policy changes could take up to 2 hours to be effective for Exchange Online. As an Example: An admin adds a policy at 11am to block a range of IP addresses from accessing email, a user coming from that IP range could possibly continue to access email until 1:00 PM.
• Enable after a user is disabled: If you enable a user right after they are disabled, there will be some latency before the account can be enabled.
• SPO and Teams - 15-mins delay
• EXO - 35-40 min delay
• Sign-in Frequency: Sign-in Frequency is honored with or without CAE.

CAE was a topic we covered at one of our Cloud Clinic sessions – a series of complimentary training webinars. In addition, my colleagues Jared Kennefick and Chris Beamon, have authored blogs on other topics including Azure Reserved Instances and Azure Sentinel to explain how these features work. I encourage you to check them out. We’ll be hosting more Cloud Clinics in 2021. Follow us on Twitter @Daymarksi to keep up with new topics and dates.