How to build Conditional Access rule sets

In the past months I have spent some time designing and implementing Conditional Access rule sets and would like to capture / share my experiences. In my experience, CA rule sets usually start relatively simply, then grow and become more complex and confusing. With the increasing use of cloud apps, different devices and different user groups, many reach the point where a redesign makes sense. At this point I want to start with this blog post.

In order to make the topic a little easier to digest, I have drawn up a 10-point plan that you can use as a guide if you are facing the same task

1. Prepare yourself!

Fortunately, there is very good material on the Internet with which you can acquire the necessary knowledge.

Know the documentation!

In addition to the Microsoft documentation, I particularly recommend Alex Fields blog as a starting point. His „recommended conditional access policies“ document in particular is excellent.

Get familiar with integrations!

Depending on your licenses, your requirements and your environment, you can or must take advantage of the various integrations of Conditional Access. The resulting possible conditions and access controls have a strong impact on the effectiveness and complexity of the rule set.
I think it makes sense to divide it into two categories at the beginning:

• Basic integrations, such as MFA and Intune, which everyone should use, otherwise it will be really difficult to effectively secure cloud services.
• Advanced integrations, such as Microsoft Cloud App Security, AAD Identity Protection and Microsoft Defender Advanced Threat Protection, which bring very powerful features and can take your rule set to the next level.

In this blog post I will focus on the basic integrations, because I am mainly concerned with the methodology used to design and implement a rule set. However, you should familiarize yourself with all the integrations and the possible conditions and access controls during the preparation, because the additional options often enable new approaches and complicated constructions to be avoided.

Get familiar with Conditions / Assignments!

You should know how you can scope your policies regarding users and groups.
Keep in mind that you can use directory roles or the user type attribute – this is often easier and more secure.

Unfortunately, the field is much more complex for apps, since not all Microsoft endpoints can be selected as an enterprise application. This makes it especially difficult to use „All Apps“. The initially implemented policies à la MFA for all apps become difficult at the latest when chicken and egg situations e.g. result in the enrollment of mobile devices or you want to block access to all apps except a few special ones and find that the MyApps portal cannot be excluded (please support this uservoice).

In my policies I also use the following conditions a lot

• Location -> to integrate clients who cannot identify themselves better, e.g. Terminal server or mobile devices that are managed with a system other than intune
• Device platform -> mainly to be able to separate policies for PCs and mobile devices
• Client apps -> to close security gaps (see below)

Get familiar with Access Controls!

First of all, it is important to understand that the access controls are very heterogeneous and sometimes do not work for all platforms. It is also easy to build policies that are unachievable. Here is an overview of the possible usage of the Grant Access Controls:

• MFA and Terms of Use are device-independent
• Hybrid Azure AD joined only works for Windows
• Approved Client App and App Protection Policy only work for Android and iOS
• Device compliance supports many device types but only works for Intune managed devices in the same tenant (means: not for guests)

Another important topic is to understand that the Access Control are different regarding efficiency for Data Loss Prevention:

• MFA is improving the authentication but won’t help you regarding DLP. You can connect with any device and copy the data. MFA does not allow any link to data loss protection measures.
• By using Trusted Location you can leverage the already implemented DLP measures in your datacenter but this is a very loose link.
• With Require Approved App and corresponding App Protection Policies you can ensure that the data is enclosed in a container on the device.
• Trusted devices vary greatly in effectiveness, but can reach a very high level.

Here are some good practices for using Access Controls:

• At first you should focus on your managed devices and try to use Device Compliance for all platforms. This means: with Intune Conditional Access is a lot more powerful!
• For unmanaged (BYOD) Mobile Devices you should try to use the Approved Client Apps (imho App Protection Policy will need some additional time to get really usable) Control and build App Protection Policies in Intune.
• For managed Mobile Devices you should use both when possible: Device Compliance and Approved Client Apps.
• Terms of Use is really good for guest users.

2. Know your apps and devices!

After the preparation, an inventory makes sense. Apps, data and devices are particularly important.

Do an assessment of the used enterprise apps

In the CA sense, apps are always enterprise applications. In contrast to an app registration, an enterprise application can also be located in another tenant. This is e.g. also the case with Microsoft apps like teams.

The first useful starting point is the Azure AD application activity report in the Usage & insights area. Here you can order your apps by successful sign-ins and see your most used apps.

Where is your data stored?

The next important step is to write down where your data is stored. If you have a look at the shared responsibility model, you’ll see that this is your responsibility and with Conditional Access you have a great tool to do so.

In my experience the data of the most organisations is stored in apps like these:

• Exchange Online (or Exchange OnPrem, GSuite, …)
• SharePoint Online (or SharePoint OnPrem, Confluence)
• OneDrive (or Box, ShareFile, Dropbox, …)
• Salesforce, SuccessFactors, Workday,…

You should now have a list of apps with a flag for apps that contain company information. Now you should take the time to mark the apps that contain (wanted / planned) sensitive internal data.
In order to protect against the outflow of sensitive data in services in which this is not wanted, we need other tools such as MCAS or AIP.

Which device platforms are in use in your environment?

As already described in the section access controls, CA has effective measures to implement under which conditions which devices are allowed to access the connected services.

Maybe you have a list of supported / managed platforms today. Experience shows, however, that you should definitely take a look at which devices are used in practice. This can easy be done in the sign-ins section of the Azure AD by filtering the field operating system. If you want to dig a little deeper take a look at the section „Prepare your tool box…“ below.

How can you manage and secure them? How are you doing today?

CA is a powerful tool to secure your apps but of course not a panacea. In addition to securing the apps, it must also be ensured that the accessing devices are configured securely. CA cannot evaluate how these configurations look in detail, but it can be assumed that the admin has taken appropriate measures based on certain properties (intune device compliance, hybrid join). You should familiarize yourself with the options for securing the devices, for example GPOs or Intune, and how they are currently being used in your environment.

3. Define categories of applications!

Now that you know all your apps and where your data is, you should think about whether and how the apps and data can be categorized. Remember who and in what situations the apps are accessed. Maybe your application has built-in protection features and can be used from private devices like Citrix.

Useful categories according to data protection requirements can be:

• Unrestricted – for applications that contain no or only uncritical data, e.g. the Office Activation
• Need Strong Auth – for applications that contain internal data but e.g. are able to prevent the data outflow themselves like Citrix
• Only on managed devices – for applications that contain sensitive data like Exchange, SharePoint or Confluence

4. Take care of E-Mail!

The service email should play a special role in your planning. There are a number of good reasons for this:

• Email has been one of the core services since the first days of the Internet and has been and is business critical almost everywhere
• Over time, email has spawned a number of clients and protocols for all platforms and many companies are already making email available on mobile devices.
• Email has been the first service for many companies to migrate towards Office 365 and often there are complex situations with Exchange Hybrid and / or ongoing migrations.
• Especially in the field of email, Basic Authentication is still used in many implementations today, which is heavily used by attackers to take over accounts. This is so problematic that Microsoft announced that it would turn off Basic Authentication in October 2020.

Email at mobile devices!

If you use only Exchange Online with the Outlook App on Intune managed mobile devices you can skip this section. If there are other uses, it becomes a little more complicated.

Since there are many different scenarios, I would just like to point out a few basic facts at this point and give you the advice of someone to either deeply familiarize yourself or get help:

• Most mailclients are able to use Modern Authentication but using Basic Authentication as default.
• The iOS Mail App is using a different Endpoint for the communication to Exchange Online -> the Enterprise App iOS Accounts.
• If you’re using a legacy (OnPrem) MDM solution for accessing Exchange Online you will run into the following problems:
  • Lack of support for the protection of Outlook and the other MS Office apps
  • No device compliance or app protection and fallback to Network Backhauling (means routing the traffic through your perimeter.)
• If you want to use CA for controlling the access to your OnPrem Exchange you have to use Hybrid Modern Authentication.
  (You should avoid internet facing Exchange Servers and restrict the communication to the Microsoft IP ranges )
• Only with Outlook mobile you will have access to:
  • The approved app Access Control and App Protection Policies
  • AIP Support
  • Accessing Shared Mailboxes
  • Integration in Office

5. Write down or visualize your ruleset!

Now it’s time to write down your ruleset. This step is really important because you have to convince the people maintaining the apps and the people maintaining the devices for your plan.

This just means:

• Define your App Categories
• Assign Enterprise Apps to the App Categories
• Define Access Controls to the Categories

Here is an example of a visualized ruleset:

6. Prepare your tool box and create a Report-Only Ruleset!

Before you start implementing the rule set, however, you should prepare your tools to get maximum insight and control during and after implementation.

• Get familiar with the „What if tool„
• Route your AAD Logs to Azure Monitor
• Get familiar with the AAD Workbooks (and Kusto Queries)
• Prepare a test environment to test the policies

Now it’s time to implement the rules in Report-Only Mode. Here are some good practices for the design:

• Include all users and use Group Based App Access for scoping
• Exclude your Break-Glass-Accounts, exclude guests and build an own ruleset for them
• Don’t overload your policies, build separate policies for PC and Mobile devices by using the platform condition
• If you have the choice of whether you can achieve your goal with a condition or an access control, you should prefer the access control to have better reporting capabilities. Good examples for this are Device Compliance and Hybrid Joined Devices. I use this as only as a condition in BLOCK policies.

After some days of data collection you will see how handy the Conditional Access Insights Workbook is. Simply filter by your new policies and see what they would have done.

After this preparation, the policies then only have to be activated.

7. Take care of your guests!

In the last section I gave you the advice to exclude the guests from your main policies and build a separate rule set for them. This is a good idea, as guests usually have different requirements, restrictions, and permissions than an internal employee. Even if the guests registered their devices in a different tenant and met all compliance requirements, this cannot be evaluated by CA. This means that guest users will always access the environment with a – from CA’s perspective – unmanaged device.

In most scenarios, I create two policies for guests:

• A GRANT policy to enforce MFA (and Terms of Use)
• A BLOCK policy to restrict the Access to dedicated apps

When dealing with guests, you should also know about :

• the external collaboration settings
• the 1:5 rule for licensing AAD guests
• the licensing rules for O365
• Access Reviews

8. Take care of your admins!

Securing your admin-accounts is a topic on its own and would go beyond the scope of this blog. For CA …:

• Usage of separated accounts for administrative tasks and enforcement of MFA for admin-accounts is mandatory.
• It’s really important to make sure that your Break-Glass-Accounts are excluded from all CA policies.
• For security reasons you should scope your policies on roles. This will cover all users with critical administrative privileges and does not depend on the quality of group assignments.
• If you’re using PIM (what you should do) be aware that the used policies will change with the role activation.

9. Close some security gaps!

Conditional Access can help you in many ways to make your environment more secure, but I’d like to point out some topics you should focus on.

Block Basic Auth!

One of your top priorities these days should be to eliminate legacy / basic authentication. Conditional Access gives you an opportunity to do this in a very controlled manner. You can use the above described procedures and tools to plan this change (instead of waiting for the day when Microsoft disables the protocols). And you should use the workbook for detecting legacy auth.

Block Unsupported Platforms!

As a hardening measure, it is advisable to block Unsupported Platforms. The reason for this is that the device platform is used as a condition, i.e. as part of the policy scoping. To determine the device platform, CA uses the „user agent“ header in the HTTP packet, which is determined by the client. This combination can mean that none of the known device platforms is recognized and the default behavior of CA – Allow – comes into play.

10. Define a process to discover and integrate new apps!

Congratulations when you have successful implemented a CA rule set – but your job is not done. Your environment and the list of enterprise apps will hopefully grow. You need to detect when there are new apps and you need a plan to integrate them in your rule set.

Detecting new enterprise apps

There are several scenarios for how enterprise apps can get into the tenant.

Some of the apps will come into the environment in a very controlled manner through IT. This applies to all apps that are connected via SAML or AppProxy. The process for integrating an app should include an integration into the CA rule set, for example an assignment to one of the categories.

With OAuth / OIDC apps, it depends heavily on the configuration of the tenant. In the default configuration, every user is allowed to register apps in the tenant and consent to apps accessing company data on their behalf. An option to get into the process of onboarding these apps is to use the admin consent workflow. Another approach for detection is to use Microsoft Cloud App Discovery (which is included in AAD P1) and goes far beyond and helps you to find apps you should integrate with AAD. Regardless of the discovery function, you should know and use the Cloud App Catalog for evaluating the apps.

Integrating new apps into the rule set

For every new app, the same procedure as for the initial creation must be followed. Evaluate whether the app contains internal / sensitive data and whether guests need to have access to it.