Organizations adopting Microsoft’s cloud services need to keep their employees safe, especially when employees need to access these cloud services while being outside of the organization’s network. In this guide, we’ll explain how organizations can set up Conditional Access policies to restrict how their users can access Office 365 and other Microsoft services.
As more and more employees now want to be able to work remotely and on any device chosen, security has become a crucial topic for all organizations. Over the past few years, it has become critical for an organization to figure out how to secure employees working both in the office and remotely.
Many organizations migrate to cloud services such as Microsoft 365 to provide better management and support. Cloud services bring many benefits to an organization, though they often add complexity from a security perspective.
Microsoft 365 does provide excellent tools to assist organizations in migrating their data to the cloud, all while securing access to the company’s information. The key to using these tools is to know where they are, have a valid license, and learn how to use them for monitoring purposes.
In a Microsoft 365 environment, Azure Active Directory (Azure AD) is the core authentication component that provides core access control to the tenant and all available services. Microsoft 365 does not utilize anonymous access, which minimizes the process for accessing these services no matter the device.
As part of the Azure Active Directory service, Microsoft provides the ability to control access based on conditions. Conditional Access policies, as they are known, combine different signals to determine if access to an application or service should be granted or denied.
These policies, at their core, are simple if-then statements. For example, if a user wants to gain access to Microsoft Teams, we can require them to meet the condition of being in the office to be granted access to the app.
Conditional Access policies serve as a protection layer executing at the point of authentication to control access to Microsoft 365. You can enforce these policies for internal employees and external guest users. You can also create policies targeting specific users, groups, devices, or other signals available to Azure Active Directory.
The most common signals used by Conditional Access policies are:
The most common access decisions used by Conditional Access policies are:
To utilize Conditional Access-based policies, your organization needs to have one of the following licenses:
If you are an educational or government organization, you must use the equivalent “A” or “G” license.
When Microsoft first enabled Conditional Access policies within Azure Active Directory (Azure AD), they deployed a few basic policies. Over time, these policies were replaced with what’s now called security defaults, but the company also provided templates for manually creating policies as an alternative.
Microsoft’s goal with security defaults is to deliver a basic level of enabled security at no extra cost to the organization.
The security defaults include the following settings:
Security defaults are for organizations who want to increase their security posture but don’t know how or where to start. They’re for organizations using the free tier of Azure Active Directory (Azure AD) licensing.
If an organization has more complex security requirements, security defaults will not be enough and it’s recommended to use Conditional Access policies instead.
Conditional Access templates provide an easy method for deploying policies that match Microsoft‘s recommendations. There are currently 14 policy templates split into different policies that you can assign to either user identities or devices.
The full list of Conditional Access policy templates includes:
You’re not required to use any of these templates, but they serve as a starting point for quick and easy deployment. These policies can also be modified or even added to organizational-specific ones.
You can find below three common examples of Conditional Access policies you can use to restrict access to Microsoft 365.
Here are the different settings we’ll be using to set up this Conditional Access policy:
Here are the different settings we’ll be using to block sign-ins from legacy authentication protocols:
Here are the different settings we’ll be using to require MFA authentication for all guest users accessing company resources:
These basic examples show the configuration properties available when creating Conditional Access policies. They provide deep granularity to ensure policies require the correct identities for specific workloads.
When choosing the users or groups to assign to a policy, you can either choose “all users,” select “All guest and external users,” “Directory roles,” or specific users or groups.
The Cloud apps or action property allows you to select all apps or specific ones for your Conditional Access policy. You can also choose specific user actions such as registering security details or authentication context provided by another service such as SharePoint Online.
The condition property allows you to check the user or sign-in risk level, the device platform used for the connection, the location the request is coming from, and whether it is a modern or legacy authentication request. You can also use filters to select specific devices within the directory.
The other properties of Conditional Access policies include options to restrict user sessions. As an example, it’s possible to force users to re-authenticate after a specific amount of time.
Conditional Access policies determine the conditions for accessing Microsoft apps and services within an organization. If Microsoft’s security defaults may work well as a starting point for most organizations, many of them may need to create custom policies that better fit their security needs.
Personally, I think every organization should use Conditional Access policies to generate protection rules executed at the point of authentication to control who can enter the tenant. Once someone makes it into the tenant, only permissions may or may not restrict what they can do
If you have not started using Conditional Access policies yet, you can go through Microsoft’s documentation to plan a conditional access deployment and check out the current templates provided by the company to get started. You can also check out my separate post on how to create Conditional Access policies with PowerShell.