In this introduction to Conditional Access we will be exploring what Conditional Access is, why you should use it in your Azure/Microsoft 365 environment and provide setup instructions for four (4) basic rules that will help secure your environment. The rules that we will be implementing are:
- Require Multi-Factor Authentication For All Users
- Require Multi-Factor Authentication For Administrators
- Block Legacy Authentication
- Require Compliant (Intune) or Trusted Devices (Hybrid Join)
Conditional Access requires an Azure AD Premium 1 license, this license can be bought standalone but is also part of the following licenses: Enterprise Mobility + Security E3/E5 or Microsoft 365 E3/E5.
What is Conditional Access
Before we dive into the technical part, a simple way for beginners to understand Conditional Access is simply to compare it to something from our everyday life, like locking the front door to our appartement or house. The drawing below is something that I frequently use to describe Conditional Access to those who are unfamiliar to the concept or tool.
When we leave our house we always lock our front door to protect our belongings from being stolen (at least most of us do). Most likely the front door is locked with a traditional key, the same principle of locking your door can be applied to the cloud.
Conditional Access uses signals to evaluate if a user should be approved, asked for Multi-Factor Authentication (MFA) or blocked (there is also a way to give limited access but we will leave that for now). When you approach your front door, the locked door can be opened because you possess the key. When there is a logon attempt to Azure AD we can evaluate who the user is, where he/she is signing-in from, what application or service are they trying to access, what type of device is being used, is the device managed or trusted and how risky is the logon attempt. Based on those signals we can then decide if we want to allow that user into our environment or not.
Why Use Conditional Access?
When moving workloads into Microsoft 365 and Azure it is important to recognize that public cloud services are open to anyone by default. This makes securing your data and services extremely important. There are lots and lots of security services in Azure and Microsoft 365 but starting with Conditional Access is probably one of the best things to do from a security perspective.
One of the things that Conditional Access can assist with is making sure all your users are using Multi-Factor Authentication. Utilizing Multi-Factor Authentication is something that all organizations should enable, as it increases security by 99.9% according to Microsoft. My personal opinion is that it should be enabled by default for all of Microsoft’s customers because its such an essential security component. Below are some shocking numbers from Microsoft that provides a disturbing picture as to how few organizations are protecting their identities (users) with MFA:
- The amount of Admin accounts in Azure/Microsoft 365 protected by MFA in 2018: 2%
- The amount of Admin accounts in Azure/Microsoft 365 protected by MFA in 2019: 8%
- The amount of User accounts in Azure/Microsoft 365 protected by MFA in 2019: 16%
Some might say that they already have implemented MFA through their Office 365 license, and that is better than nothing. However Office 365 MFA must be enabled on a per user level (can be scripted/automated) and does not have the same granularity or advanced features that Conditional Access does. In addition Conditional Access can make sure that legacy authentication is blocked, that data/services can only be accessed by trusted or compliant devices and combined with Cloud App Security session and app control be used for further granularity.
Creating Conditional Access Policies
Next lets dive into the console and create some policies. Start by opening the Azure Portal and searching for Conditional Access in the search bar at the top. Since we want to encourage the use of Zero Trust principles (meaning explicitly verify, assume breach and principle of least privilege) the example policies will not include any exemptions based on location such as a corporate office.
Note: You should always have a Break Glass User (Emergency User) that is excluded from all Conditional Access Policies. It is very easy to lock your self out of the tenant, if this happens you will need to contact Microsoft Support and prove that you own the tenant in order to regain access.
Require MFA For All Users
Enabling Multi-Factor Authentication (MFA) for all your users increases your security by 99% according to Microsoft. Tenants that do not leverage MFA are exposed and vulnerable to password sprays and other types of password attacks. Remember that all users (excluding guests) will need an Azure Multi-Factor Authentication license.
Start by setting the scope of the policy to All Users, this will also include guests that have been invited into the tenant.
Next select All Cloud Apps to enforce MFA for any application that uses Azure AD for authentication (recommended). Select a specific app such as SharePoint or Exchange to limit to those specific applications.
Finally select Require Multi-Factor Authentication on the Access Control page.
Require MFA For Admins
This policy will be similar to the first policy, however this time we will specifically target those users who have administrator rights in the tenant. The previous policy would obviously also cover Administrators, but it is in my opinion good design to explicitly target those with administrative rights.
In the example below we have targeted any user with a specific directory role (all 60 roles at the time of writing have been selected). There could be additional users doing administrative tasks that might not have a particular role in Azure AD that we can target. An example could be a user that is doing tasks in your Azure infrastructure that is working with subscriptions rather than Azure AD roles. If this is the case create a Dynamic Azure AD group and then add this group to the Conditional Access policy.
Next, choose all Cloud Apps or limit it just to specific applications such as Azure Management. Azure Management includes the following resources:
- Azure portal
- Azure Resource Manager provider
- Classic Service Management APIs
- Azure PowerShell (not Azure AD PowerShell)
- Visual Studio subscriptions administrator portal
- Azure DevOps
- Azure Data Factory portal
Remember that the first policy will apply to All Users, the objective here is to explicitly make sure that anyone with an administrative role is prompted for MFA. My personal preference is simply to target All Cloud apps but Azure Management has been chosen in the image below as an example.
Finally under Access Control select Require Multi-Factor Authentication like before.
Block Legacy Authentication
Legacy protocols such as IMAP, SMTP, POP or MAPI don’t support Multi-Factor Authentication so we really don’t want to use these insecure protocols in our environment. Microsoft has previously announced that they will be restricting legacy authentication on Exchange Online in Q3 2021. Blocking legacy authentication already now allows organizations to test this change in advance and make any adjustments to prepare for the change.
Note: Make sure modern authentication is enabled for all your Microsoft 365 services before enabling this policy, this can be done in PowerShell for each service. Modern Authentication is enabled for newer tenants but could be disabled for older ones.
Select All Apps since we don’t want any legacy authentication against our environment. If there are any specific applications that do not support modern authentication exclude them until modern authentication can be implemented.
On the Conditions tab select Exchange Active Sync and Other Clients under Client Apps.
Finally select Block Access under Access Controls.
Require Compliant or Trusted Devices
This final policy will make sure that only those devices managed by the organization are allowed access to the organizations data in Microsoft 365/Azure. This means that only devices managed in Intune, or Windows 10 devices that are members of the on-premise Active Directory that have been Hybrid Joined are allowed access.
Note: This is a drastic change for end-users who might already be using Microsoft 365 services such as email on devices that are not managed by the organization, make sure adequate testing is done before putting into production and that end-users have been informed of the consequences.
Start by setting the user scope to All Users. Guest will need to be excluded since they probably dont have any corporate devices. This brings up an important discussion as what Guest users should and should not be able to access within the environment, we wont cover that discussion here but its something to be aware of.
Select All Cloud Apps
On the Access Control page, select Require Device To Be Marked As Compliant and Require Hybrid Azure AD Joined Device, make sure that only one of the conditions is required.
Depending on the organization security requirements the Multi-Factor Authentication could also be selected in addition to Require Device To Be Marked As Compliant and Require Hybrid Azure AD Joined Device. This would allow connections from untrusted devices as long as the user is able to authenticate with MFA.
