During Microsoft Ignite in March this year, Microsoft announced several new upcoming functionalities for Azure Active Directory. One of the announcement was the Azure AD Conditional Access authentication context, for which I that time I already wrote about what it could do in my blog article: Modern Workplace Management key takeaways from the Microsoft Ignite March 2021 announcements.

On May 26th, Conditional Access authentication was made available in public preview as announced by Alex Simons and Caleb Baker in the following article: Conditional Access authentication context now in public preview.

Current data protection options

With Conditional Access, we are able to protect the identity of our Azure Active Directory users and control the access to company data hosted in Office 365 and SaaS applications. In order to protect the company data we have several options available.

1. We can allow full access on managed devices, these devices are either Azure AD Hybrid joined devices, or devices which are compliant and therefore managed by Microsoft Endpoint Manager.
2. We can restrict access on non-managed devices, by either blocking or limiting the access given.
3. We can protect the data itself, by using sensitivity labels which are either applied by the user, or automatically.

Conditional Access App Enforced Restrictions

We can use a Conditional Access policy, to either restrict or block access to data hosted in SharePoint Online on tenant or granular level. When the access control for unmanaged devices in SharePoint online is configured to Allow limited, web-only access you can restrict access to the content hosted in SharePoint online to be only available in a web browser where downloading and printing of an opened file is prohibited. This functionality can be accomplished by leveraging the Conditional Access App Enforced Restrictions option as part of the session access controls in a Conditional Access policy. I’ve described this functionality in the following article: Limit Access to Outlook Web Access, SharePoint Online and OneDrive using Conditional Access App Enforced Restrictions.

If you require more granularity for your Conditional Access App Enforced Restrictions you can either specify the Control access from unmanaged devices setting on a per SharePoint site level using PowerShell or use Sensitivity labels, as described in the following article: Defining more granularity for your Conditional Access App Enforced Restrictions using Sensitivity Labels

Microsoft Cloud App Security (MCAS)

When our company data is not hosted on SharePoint online and Single Sign On (SSO) to a SaaS based 3rd party application is configured, we can route the users session to the third party application through Microsoft Cloud App Security (MCAS) which has a reverse proxy functionality (session control). Routing a user’s session through MCAS is accomplished by leveraging the Conditional Access App Control functionality available under the session access controls.

Once a session is reversed proxied through MCAS we have several options available to control what can be done with files downloaded from the 3rd Party SaaS application. You can also decide not to use App Enforced Restrictions and use App Control instead for your SharePoint Online sites as well. I’ve explained some of the use cases in the following article before: Extending Conditional Access to Microsoft Cloud App Security using Conditional Access App Control

Conditional Access Authentication Context

Conditional Access Authentication Context is able to trigger a Conditional Access policy when sensitive content is accessed. With this new functionality new scenario’s become available, some examples are:

• You can require MFA when a SharePoint site with a certain sensitivity label gets accessed on a unmanaged device.
• You can block the session from a Conditional Access policy when a SharePoint site with a certain sensitivity label gets accessed on a unmanaged device.
• You can require that Terms of Use must be accepted first before access to a SharePoint site with a certain sensitivity label gets accessed.
• You can set the sign-in frequency to a low value when a SharePoint site with a certain sensitivity label gets accessed.
• You can trigger the Authentication Context from within a session control policy defined in MCAS, for example to trigger MFA as defined in the Conditional Access policy. You could for example trigger MFA when a document with a certain sensitivity label gets downloaded, or require the user to accept a Terms of Use first.
• App developers can leverage the authentication context in their own apps

So, how does it work?

Create Authentication context labels

The first thing that needs to be done in order to start working with Authentication context is to create a new label/new labels for authentication context. These labels can be created under the Authentication context (Preview) menu in the Conditional Access section of the Azure AD Admin portal. You can create a new label by clicking on + New authentication context which will open up a new windows where the name and description for the new label can be supplied. By default the Publish to apps option is selected, making the label available for use within apps.

To explain the concept I’m going to create the following authentication context labels

Label name	Explanation
Internal – High Authentication Context	Requires compliant device, TOU, or MFA
Internal – Medium Authentication Context	Requires compliant device
Internal – Low Authentication Context	MFA

With these labels we can build the following scenario’s:

1. Only grant access to internal users when they work on a compliant device, and require them to provide MFA
2. Only grant access to internal users when they work on a compliant device
3. Only grant access to internal users after they have provided MFA
4. Only grant access to guest users after they accepted the Terms of Use (TOU), and require them to provide MFA
5. Only grant access to guest users after they have provided MFA

Please be aware that at this time, you cannot delete any authentication context labels, you can modify existing ones though.

Creating the total solution requires the following steps:

1. Create Authentication context label
2. Apply authentication context applicability in sensitivity label, MCAS or App configuration
3. Create Conditional Access policy which gets triggered if the authentication context applies.

Use the Authentication context label in your sensitivity labels

You can use authentication context in a sensitivity label. The authentication context in this case will replace the options which are available in SharePoint on how to handle unmanaged devices. So, you either need to choose between unmanaged device options in SharePoint (full access, limited web only access, or block access) or use authentication context.

When you create a new or modify an existing sensitivity label, you will get the screen similar to the one below.

The option to apply authentication context is only available within the Groups & sites section of the sensitivity label, which means that you can only define it on the container level and not on file level.

Creating the Conditional Access policy for the Authentication context label

So, now that the authentication context is added to the sensitivity label (sensitivity labels) we can define the Conditional Access policy which gets triggered at the moment that the SharePoint site which has the sensitivity label applied is accessed.

The Authentication context is an configurable action as part of the “Cloud apps or actions” section of the Assignments within a Conditional Access policy. Here you can a list of the Authentication Context labels which have been defined, notice that you can also use multiple authentication context labels at once.

Below are some examples on possible Conditional Access policies which you can configure

In the example below we require both a compliant device and MFA for All users except Guest and External users (since we can’t require them to have a compliant device)

With this policy active, from that point forward we can see that we can only access the SharePoint site from a Compliant device, with multi-factor authentication (1). We are not required to provide MFA, since the device I’m using for this test is using Windows Hello for Business (WHfB) which meets the MFA requirement.

If we would access the environment from a non-compliant device we would receive the message as mentioned in (3), which reflects to the Failure described in (2). Keep in mind that also your browser must meet some requirements in order to be able to leverage this functionality, see: Browser restrictions and configuration when using Conditional Access on your modern workplace.

For the conditional access policies we can create some variants, for example the policy below for Guest and External users which requires both MFA and acceptance of the Terms of Use.

Impact on using App enforced restrictions

Since we can either choose between unmanaged device options in SharePoint (full access, limited web only access, or block access) or use authentication context. We cannot offer the option anymore to provide limited web only access and require MFA for example. Since we are using Authentication context in our Conditional Access policy, the App enforced restrictions option under session control in the Conditional Access policy is not available, since you can only use this option if you have Office 365, Exchange Online and SharePoint Online is selected as a cloud app.

So unless we reverse-proxy the session through Microsoft Cloud App Security, we lose the option to restrict users from downloading and printing files as part of App enforced restrictions. See: Limit Access to Outlook Web Access, SharePoint Online and OneDrive using Conditional Access App Enforced Restrictions for more information about the functionality that

Use the Authentication context label in your MCAS Session Policy

We can also use authentication context in a Microsoft Cloud App Security session policy. A new action called “Require step-up authentication” has been added to the action list of a session policy. 

So, in the case of the scenario which I described before in the following article: Extending Conditional Access to Microsoft Cloud App Security using Conditional Access App Control, we described the scenario where we reverse-proxied the SharePoint online connection through MCAS. Within MCAS we defined a session policy with a session control type of “Control file download (with inspection) where we used the action “Block” if the Device was not Intune Compliant or Hybrid Azure AD joined, and the file name contains the word “BSN”

We can now extend this scenario to not block this file download, but trigger the Conditional Access policy which requires the approval of TOU and MFA.

Conclusion

Azure AD authentication context is a welcome addition to the options we have to enforce Conditional Access. When implementing this functionality the overall solution can become more complex though, and therefore people designing a solution like this must really fully understand the impact of adding Authentication Context to their existing Conditional Access policies.

I’m not happy with the situation that you lose the App Enforced Restrictions options, in the case where Sensitivity labels are used on containers, and you have to make an explicit choice between authentication context or unmanaged device options. Let’s hope that Microsoft makes a new session control available in the Conditional Access policy options which brings back this functionality.

Update June 24, 2021: Jan Bakker pointed me to the following thread on Twitter by Tobias Zuegel (@MrAzureAD). Tobias mentions that in order to use Authentication Context either an Microsoft 365 E5 or Microsoft 365 E5 Compliance license is needed as indicated in the following MS article: Manage site access based on sensitivity label. This will be another major drawback for using this functionality.

Want to know more about Conditional Access? – I’ve written a free downloadable whitepaper on the topic containing much information on the topic. I plan to release new versions of the paper on a regular basis. The latest version of the paper can be found here: February 2021 update of the Azure AD Conditional Access demystified whitepaper and workflow cheat sheet.

References

Conditional Access authentication context now in public preview

Protect files on download – MCAS session policy

Configuring Conditional Access authentication context

How to configure groups and site settings