Conditional Access demystified, part 2: What is Conditional Access?

Now available: May 2020 update of the Conditional Access Demystified Whitepaper, Workflow cheat sheet, Implementation workflow and Documentation spreadsheet

This article is part 2 of a series, for which the following articles are available:

Conditional Access demystified, part 1: Introduction
Conditional Access demystified, part 3: How does Conditional Access work?
Conditional Access demystified, part 4: Designing a Conditional Access strategy
Conditional Access demystified, part 5: Implementing Conditional Access
Conditional Access demystified, part 6: Troubleshooting Conditional Access
Conditional Access demystified, part 7: Modifying Conditional Access to suit your special needs
Conditional Access demystified, part 8: Resources and further references

Microsoft describes Conditional Access as followed: “With Conditional Access, you can implement automated access control decisions for accessing your cloud apps that are based on conditions.” and “Conditional Access policies are enforced after the first-factor authentication has been completed. Therefore, Conditional Access is not intended as a first line defense for scenarios like denial-of-service (DoS) attacks, but can utilize signals from these events (e.g. the sign-in risk level, location of the request, and so on) to determine access.”

The way I see it, the best way to explain what Conditional Access does, is by making the comparison to a firewall. A firewall determines what traffic can access your resources, under what circumstances and Conditional Access sort of does the same. Conditional Access describes under what circumstances users can access your cloud applications.

With cloud applications Microsoft means applications which use Azure Active Directory (Azure AD) for authentication. Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management service. So if you access an SaaS based application through Azure AD you can use Conditional Access as your “access firewall”. Microsoft’s SaaS offerings like Office 365, Dynamics, the Azure Portal all use Azure AD as its authorization mechanism.

This also means that if you can access the SaaS application in some other way, you can bypass Conditional Access making the solution less effective. For example, you only the credentials of the application in Azure AD, and through Azure AD you can login using SSO making use of Conditional Access, but when accessing the SaaS application directly you can also provide your userid and password. So it’s important that you modify the SaaS identity provider to leverage Azure Active Directory.

If you have SaaS apps which have a federation with your ADFS infrastructure, you can use claim rules in ADFS which provide similar functionality as Conditional Access, if you want to make use of Conditional Access you need to modify the federation to use Azure AD instead of ADFS.

Licensing

Conditional Access is a feature which is part of an Azure AD Premium P1 and P2 license which you can buy individually or is part of a suite license like Enterprise Mobility and Security (EM+S) E3/E5 or Microsoft 365 E3/E5, and recently announced Conditional Access is now also included  as part of Microsoft 365 Business licensing.

Some of the Conditional Access settings require that you have licensed other products, for example in order to use the sign-in risk condition you need to have Azure AD Identity Protection licensed. (Part of Azure AD premium P2). In order integrate Conditional Access with Microsoft Cloud App Security (MCAS), you must of course have MCAS licensed as well.

Keep in mind though, that you can apply Conditional Access policies to users which are not licensed for Azure AD Premium P1 and P2, since assigning Azure AD Premium P1/P2 to any user in the Azure AD puts the whole Azure AD in that modus. Even though this technically works, you are in conflict with the licensing terms. Microsoft states that if you use/benefit from a specific service within Azure, you must be licensed for it.

Therefore I advise to use group based licensing and make sure that these groups are used for conditional access configuration as well.

Secure Score

Implementing Conditional Access policies can help with receiving points in Secure Score (https://securescore.microsoft.com/). Secure Score provides a numerical summary of your security posture based on system configurations, user behavior and other security related measurements.

Conditional access provides functionality which is part of a secure identity infrastructure, more actions than just implementing conditional access are needed. See this article for more information on the steps needed to secure your identity infrastructure: Five steps to securing your identity infrastructure – https://docs.microsoft.com/en-us/azure/security/azure-ad-secure-steps#step-2—reduce-your-attack-surface

In the next article (part 3), I’m going to discuss how Conditional Access works