Advanced Conditional Access Use Cases – Part 2: Controlling the actions in a session

Veröffentlicht am 12. April 2020 von Christopher Brumm

After my introduction to Policy Design for Conditional Access and the integration of Risk Based Conditional Access I would like to deal with the first session controls today. While all other policies so far were concerned with the question of whether an access is allowed or not, session controls define conditions within the access or the length of the session. In this blog post I want to deal with the controls that work within a session. I am saving the topic cookies and tokens for another blog post 😉

App Enforced Restrictions and Conditional Access App Control

These two features allow us to control to a certain extent what a user is allowed to do within a session – but implement this in a technically different way.
While App Enforced Restriction tags the session and leaves the service in control, Conditional Access App Control routes the session through Microsoft Cloud App Security.

For better understanding here are a few examples of what I mean by Session Control:

Unmanaged devices should not be able to upload or download documents to SharePoint Online.
Unmanaged devices should not be able to download attachments from Outlook on the web.
Unmanaged devices should not be able to sync OneDrive
Guest Users should not be able to copy & paste content from SharePoint Online.

These Use Cases all pursue the goal of integrating guest users and enabling the use of private devices while maintaining a high level of data loss prevention. All of them can be implemented well with both session controls. To work out the difference, let’s look at a few use cases where it depends on which one we use.

App Enforced Restrictions Use Cases

These use cases can be implemented with App Enforced Restrictions, since Conditional Access marks the session and granular configurations can then be applied at site level in SharePoint Online. (I haven’t found how this is done in detail – if you know it please tell me!):

Users outside of a special location should not be able to access a special site.
Unmanaged devices should not be able to upload or download documents to SharePoint Online from a special site.

This granular control is possible because SharePoint Online takes over the control of permissions. Conditional Access cannot differentiate between individual sites. In addition, App Enforced Restrictions is also able to control how file types that cannot be edited in Office Online are handled.

The basic setup of App Enforced Restrictions is relatively straight forward and can be well integrated into a conditional access ruleset.

For guest users the (hopefully) existing GRANT rule requesting MFA / Terms of Use can be easily extended.
For enabling the usage of private devices for internal users you propably have to switch from Access Controls to Conditions in your Policies. (see next section)
Additionally, Exchange Online / SharePoint Online must be configured for use.

I find the creation and the look & feel very well described in these blog posts for SharePoint Online and Outlook on the Web. The documentation from Microsoft is also very meaningful.

Attention: During configuration to SharePoint Online, CA policies are sometimes generated automatically. I recommend to either adapt them or better replace them with your own.

Integration of App Enforced Restrictions in the App Profile Concept

In my App Profile concept, the starting point is to split the category Medium Restricted in such a way that Exchange Online and / or SharePoint Online are treated separately. My recommendation is to define another App Profile (maybe Welter Restricted) that only contains Exchange Online and/or SharePoint Online.
This is very important because only these apps support App Enforced Restrictions.

This new profile will then have a new policy for browser access in addition to the two policies for desktop and mobile. Says:

A policy for Win & Mac enforcing trusted devices and excluding trusted locations and browser access.
A policy for Android & iOS enforcing a trusted devices or trusted app.
A policy for browser access from Win & Mac enforcing App Enforced Restrictions and excluding trusted locations and trusted devices.

In this example I only consider access from desktops, because I don’t see the Use Case for Mobile Devices. Mobile Application Management is much better suited for the integration of mobile BYOD.

Conditional Access App Control Use Cases

Other use cases can only be implemented with Conditional Access App Control, as the session is then routed through Microsoft Cloud App Security:

Unmanaged devices should not be able to upload or download documents to SharePoint OnPrem published via AppProxy
Unmanaged devices should not be able to upload or download documents to SalesForce
Guest users should present a certificate from a trusted PKI to prove that they are accessing from a managed device to access SharePoint Online.
Files should be dynamically tagged with a (MIP-)Label including protection during download. (My Favorite!)

Conditional Access App Control is quite powerful by combining Conditional Access and Cloud App Security. To understand the given possibilities, it is a good start to look at the possibilities of Access Policies and Session Policies.

Unlike App Enforced Restrictions, control is not limited to Exchange Online and SharePoint Online. You can use Conditional Access App Control for any in AAD integrated app, including your OnPrem SharePoint (via AppProxy) or SaaS Services like Salesforce.
Conditional Access App Control also allows client certificates to be queried, thus complementing or partially replacing the capabilities of Intune. This is especially helpful for the integration of partner companies.
The integration of MCAS and Azure Information Protection, Conditional Access App Control can also use AIP Label in the policies:
- for example, to prevent the upload of sensitive documents to certain services, labels can be used as a filter in the activity sources (similar to the condition in CA)
- for example to attach a label during download the Action Protect can be used.

In these videos you can see some impressive examples.

The setup of Conditional Access App Control is – depending on the use case – a bit more complex, but can be easily integrated into a conditional access ruleset.

For guest users the (hopefully) existing GRANT rule requesting MFA / Terms of Use can be easily extended.
For enabling the usage of private devices for internal users you propably have to switch from Access Controls to Conditions in your Policies. (see next section)
For the Session Controls you can either choose one of the Built-In Policies or use a Custom Policy, which must then be configured in MCAS.

Integration of Conditional Access App Control in the App Profile Concept

There are several approaches for the integration into a rule set and to be honest I’m still a bit unsure what works best in practice.

A use case could be integrated like App Enforced Restriction. Some apps are moved from the Medium Restricted profile to a new profile (here: Welter Restricted) and an additional set of policies is created including one for Conditional Access App Control.

When designing the CA rule set, it is important to note that only the Built-In Policies in CA can be selected, i.e. it makes sense to perform scoping in the MCAS policies. The additional scoping of the session policies in MCAS may offer a little more flexibility but the clarity and readability suffers a lot.

I will (hopefully) talk about policy design in MCAS in a future blog…

Comparison and Recommendation:

My opinion after having studied the two functions a bit deeper is clear: They are both super valuable and should be used!

Which one you use depends, in my opinion, on these factors:

What exactly does the Use Case look like?
Which licenses are available to you?
(When) is the introduction of MCAS on your roadmap?

Use Cases

I have tried to answer the question about the use cases in the previous sections. I ask myself the following questions for the selection of the appropriate method:

Which apps are we talking about?
- App Enforced Restrictions is limited to a few services but offers added value here.
- For SharePoint Online, Microsoft generally recommends the use of App Enforced Restrictions
Which filter methods are required?
- Is it about a special site in SharePoint Online?
- Are labels or certificates required as filter criteria?
Which actions should be used?
- Is it just about blocking downloads or do I have more demanding requirements?

Licensing

If you got this far, I assume that licenses for conditional access are available 😉
But not all variants described here are covered by the AAD P1 license and sometimes commercial arguments play a role in selecting the appropriate method:

A great advantage of App Enforced Restrictions is that it is included in the AAD P1 license.
For Conditional Access App Control you will definitely need another license for Cloud App Security.
- Office 365 Cloud App Security enables the use of Conditional Access App Control for Office 365 apps like SharePoint Online.
- Microsoft Cloud App Security enables the use of Conditional Access App Control for any in AAD integrated app, including your OnPrem SharePoint (via AppProxy) or SaaS Services like Salesforce.

The Power of MCAS

Microsoft Cloud App Security functions that can be used with Conditional Access App Control can take the integration of e.g. guests and BYOD to a new level. However, these functions are only a fraction of the possibilities offered by MCAS but can be a very good reason to start with MCAS.

It would go beyond the scope of this blog post to discuss all the features of MCAS so I will limit myself to the reverse proxy used in Conditional Access App Control and would like to point out a few links to give an overview:

A Combination of both?

As already mentioned, both approaches have their strengths and should be used. In my example scenario, I want to block unmanaged device downloads for both SharePoint Online and SharePoint OnPrem.

For SharePoint Online I use App Enforced Restrictions
For SharePoint OnPrem I use Conditional Access App Control
This allows me to control SharePoint Online on site level.
Additionally I integrate a policy that requires MFA from the Session Risk Medium (see integration of Risk Based Conditional Access)

As described above, the condition client apps – browser is important for policy scoping.

Limitations and open questions

None of the functions shown replaces a Web Application Firewall. Depending on your Use Case the Azure WAF in Application Gateway or Azure Front Door can be a good choice.

Some questions I could not answer so far and will test a little bit with it in the future (or maybe learn from others):

What happens if (accidentally) App Enforced and Conditional Access App Control are active in a session?
What happens if I use the new Enterprise App Office 365 (preview) instead of the individual services Exchange Online / SharePoint Online for App Enforced Restrictions?
Can I use the Teams Client App in any of these scenarios?