How to Use Conditional Access Authentication Context in Microsoft 365

Defining more granular control over our organization’s sensitive information has always been difficult under the current Conditional Access policy.

To address this limitation, the new Conditional Access Authentication Context is introduced.

Conditional Access Authentication Context is a recent feature that is currently in public preview. It can be complemented with the existing Conditional Access policy.

Let’s look through Conditional Access Policy briefly before moving on to the Conditional Access Authentication Context.

Conditional Access policies are used to provide an extra layer of protection for an organization’s resources. CA policies are implemented only after the first factor of authentication is fulfilled in a Multi-Factor Authentication scenario.

A conditional access policy is intended to make decisions based on the signals of access requests. The common decisions are:

• Block access- most restrictive decision
• Grant access- least restrictive decision

Common signals used in conditional access policies to make decisions are:

1. User or groups
2. IP location information
3. Device
4. Application
5. Real-time and calculated risk detection
6. Microsoft cloud app security (MCAS)

Let us try to understand the whole thing with an example-a common Conditional Access policy: Requiring multi-factor authentication for users with administrative roles

In this policy, if a user with administrator privileges requests access to the resources, multi-factor authentication is required. So, if the signal matches a ‘user with the Administrative Role‘ in an access request, the decision to ‘grant access with requiring Multi-Factor Authentication‘ is made.

Further, admins can ensure MFA enforcement with the newly released MFA registration details report in Azure AD.

The existing Conditional Access Policies are primarily app-level and do not provide the resource granularity that we need.

Let us try to understand this with an example scenario.

Assume that an organization has a specific SharePoint site where some confidential data is kept. As a result, the company must provide an enhanced layer of security for that specific SharePoint site.

With the existing conditional access policies, we are only able to provide protection on an app or service level. Also, we can control access only based on the users and directory role assignments. I.e., We could only make the policy apply to the activities of the users we chose here.

In regards of our main concern, we only have the choice to activate the policy for the entire application. That is, the policy will be triggered as soon as the specified applications are visited under the pre-defined conditions.

But what we need is the granular protection which is not available in Conditional Access policy.

The Conditional Access Authentication Context is similar to the concept of sensitivity labels. It is a feature that can be used along with a conditional access policy. With Authentication Context, we can label the resources that need to be protected and grant access to those labelled resources depending on certain conditions. Isn’t it cool?

Let’s check the steps involved in implementing Conditional Access Authentication Context:

1. Create an authentication context and publish it.
2. Add the authentication context with an existing conditional access policy.
3. Finally, tag the resources that we need to protect with the configured CA authentication context.

Here the goal is to enforce conditional access policy when specific contents (resources tagged with CA authentication context) of an app or service are accessed. So that we can protect sensitive and important data of our organization from unwanted utilization. Assume a non-admin user attempts to access a specific SharePoint site that has been tagged with an authentication context. The CA policy associated with that auth context has been configured to require MFA for non-Admins.

As a result, the non-Admin user is now required to complete MFA in order to gain access. Conditional Access restrictions can be triggered by requiring Multi-Factor Authentication, a compatible device, or even a GPS-based location.

Let’s dive into the steps involved in implementing Conditional Access Authentication Context with the Conditional Access Policies:

Step 1: Configuring Authentication Context

In the Azure AD portal, Go to Conditional access -> Authentication Context (Preview). Select New authentication context.

Give the authentication context a relevant name and description.

Remember to tick the ‘publish to apps’ check box, as this will make the authentication context available to all compatible apps in your organization.

Note: Because this functionality is in preview status, authentication contexts that have been generated cannot be deleted. Furthermore, it is restricted to 25 authentication context definitions.

Step 2: Tagging Resources with Authentication Context

We need to tag the resources that we want to preserve. Here, let us tag a SharePoint site with the Authentication Context.

This can be done in two ways:

1. Using sensitivity label
2. Using SharePoint management shell.

Using Sensitivity Labels:

When creating a sensitivity label, we can configure our authentication context with the “external sharing and device access” configuration of the sensitivity label. Refer to the below image.

Now, the resources we are going to label with this sensitivity label will be automatically tagged with the authentication context.

Using SharePoint Management Shell:

For this, run the below command in the SP management shell:

<site url> is the URL for the SharePoint site you want to tag your authentication context. And the name of the authentication context is to be provided in the cmdlet

Note: If the site is sensitivity labelled, then the label should be removed before tagging the site with the authentication context.

Step 3: Using Authentication Context in the Conditional Access Policy as a Decision-Making Signal

Now we are going to use the authentication context in the CA policies.

For that, you can create a CA policy and assign it to the authentication context instead of assigning the CA policy to a cloud app.

Else you can modify an existing conditional access policy in such a way that it can be triggered for the resources with the authentication context tag. Additionally, you can confirm these changes by auditing CA policy changes in Azure AD audit logs.

Now the policy will be triggered if the resources that are tagged with the authentication context are accessed.

We can confirm the triggered authentication contexts by looking at the results of the applied Conditional Access policies.

Navigate to Azure Active Directory > Monitoring > Sign-ins and verify the information of the sign-ins and compare them to the authentication context configured conditional access policies.

In Conclusion…

The new conditional access authentication context gives a wide range of technical control to the resources of the organization. Apart from being a great feature to granularize control inside our apps, choosing the right Conditional Access authentication context for the right resources becomes a crucial part here.