Conditional Access – are you really getting the most out of it? Part 1 of 2

Introduction

Conditional Access is a powerful tool in many ways. You could easily create a chaos playing around with it and not fully understanding the consequences.

This series is more of a technical approach to implementing your Conditional Access policies so please read Matti’s post about securing the cloud identities with Conditional Access.

Microsoft is providing a light but yet useful best practices for Conditional Access but in this two part series I wanted to share my thoughts about implementing strong and comprehensive policies to cover some security areas which you might’ve not yet thought.

With Conditional Access you can achieve a very secure control over your cloud identities, services and data which are the attack surfaces nowadays.

I have seen organizations implement Conditional Access just for some cloud apps and users or the worst – not at all. Creating overall and effective policies can require a lot of effort depending of the state of your cloud infrastructure in general, devices and cloud identities.

You need to understand your environment, services and their configuration and most importantly how Conditional Access policies work.

Basic principles

My example here is basically based on five main areas which you could easily modify according to your organization’s needs.

1. Control your own employees with device-based access
2. Control your administrative accounts
3. Control your guest accounts
4. Control everything else possibly passing through the above
5. Last but not definitely the least, block legacy authentication including Exchange ActiveSync

These are the corner stones where the policies are based and of course you could have more sophisticated policies for just one of your cloud apps which might for example require more strict controls – like allowing access just from one geographical location and/or IP address.

Defining user roles

Now that we have an idea for whom the policies should be assigned we need to think of the necessary groups and roles that we use in our policies.

Organization’s own employees

Your own employees could be a tricky one if you don’t have a existing group and/or process for managing these users.

If you have any sort of integration between your HR system and Active Directory I strongly recommend to add a process to the integration which adds the employees to a general ‘all employees‘ group that is synced to cloud.

You could easily gather your current employees with a single PowerShell query but the point is to add dynamicity to make sure the policies are also applied in the future for any new employees.

Administrative accounts

Controlling administrative accounts is made easier thanks to Microsoft. You can enable a baseline protection policy to cover some of your administrative accounts based on their Azure Active Directory roles.

Enabling this policy enforces Multi-factor Authentication (MFA) to all the Global, SharePoint, Exchange, Conditional access and Security Administrators.

Remember to be careful and not lock yourself out. Most of the Azure Governance’s recommend to use a backdoor account which is excluded from MFA rule(s) for emergency use – do not use this account for daily administration.

You also have a possibility to create policies for any of the other directory roles.

But is this enough? Usually, no. All of the previously mentioned roles should be reduced to absolutely minimum amount, especially the Global Administrators. You most likely have dozens or even hundreds of other administrative accounts based on either AAD directory roles or some other powerful access – for example to Azure resources. These administrative accounts might not have any AAD directory roles apart from being normal users or guests.

For these accounts it is again recommended to implement a solution which assigns them to group(s) based on their naming convention, AD OU structure or whatever suits your environment.

After you have inventoried all of your administrative accounts you can use your own policy to enforce MFA, device-based access or something else in addition to the baseline protection.

Guest accounts

Not many organizations control or enforce MFA to their guest (B2B) accounts. Why not? This is mostly a governance and management discussion regarding instructions and landing the policies. There is also an annoying feature for guest user’s MFA that might require double MFA from guests if they also have MFA enabled on their own organization’s tenant.

Nevertheless you should also implement some control over the guest accounts. Otherwise you are letting them in to your cloud apps without any access control and therefore you are requiring more strict control over your own employees than guest accounts.

Technically speaking this is an easy task as you can control Guest users with Conditional Access out-of-the-box condition.

Controlling all of the other users

There might be scenarios where none of the above user roles apply to someone who is accessing your resources. Let’s say a cloud-only user which is not synced from your on-premises AD nor it is a guest user or has a directory role.

Conditions are always verified and if you have a user which doesn’t belong to any of your assignments – access is possibly allowed.

So just to be sure that you have covered all the worm holes you can create a ‘All users‘ policy that for example enforces MFA from anyone accessing any cloud app except your own employees, administrative accounts and guest users as they have their own policies to follow.

Block legacy authentication

This is a very crucial step to be done as recently a lot of attacks are performed using legacy protocols (basic, not modern authentication) like IMAP/POP3 and bypassing MFA.

Usually this requires that someone’s credentials are phished first but it happens daily and should not be underestimated.

This is honestly quite difficult task to do for 100% all of the cloud apps as I know that there is an ongoing issue with Skype for Business client Modern Authentication flow.

Sign-in logs are your friend when trying to understand what kind of (legacy) authentication is going on in your tenant.

Next steps

Please stay tuned as I will show you how to configure the policies and their pre-requirements in part 2 of this series