Have questions about Microsoft Azure AD Conditional Access? You’re in luck! Today, I’m going to lay out all the key things you need know.
What is Conditional Access?
Conditional Access is a feature of Azure AD that helps organizations improve security and compliance. By creating Conditional Access policies, you can fine-tune your authentication process — without unduly burdening users.
Consider how the authentication process has traditionally worked: Organizations require users to supply a user ID and password. Most of the time, it’s the legitimate account owner typing them in and everything’s fine — the user can go on to access all the data, applications and other resources they’ve been granted permissions for. But sometimes, it’s an attacker who has stolen or guessed a user’s credentials, and now they’re merrily romping around your network, and your organization is at risk of ending up in the data breach headlines or being slapped with an enormous compliance fine.
To reduce these risks, organizations can put additional authentication hurdles in place. Usually that takes the form of multi-factor authentication (MFA) — requiring the user to supply a code sent to their mobile device, a fingerprint or some other additional authentication factor.
These strategies can be extremely effective. Microsoft reports that its telemetry shows that 99.9% of organization account compromise could be stopped by simply using MFA. The trouble is, MFA is a pretty blunt tool. It introduces an unnecessary hassle in most cases, when legitimate users are just trying to do their jobs, increasing user frustration and hurting productivity. And it can be woefully insufficient in others, like when it’s a highly privileged admin accessing highly sensitive systems and you really want additional evidence that the authentication request is legitimate.
Azure AD Conditional Access helps you strengthen your authentication process in a way that avoids issues like these. For example, you can create a policy to require administrators — but not regular business users — to complete an MFA step. But you can get a lot more granular than that. You’re not limited to simple facts like whether the user is an admin; you can also factor in things like the user’s location and the type of authentication protocol being used. For instance, you can deny all requests that come from North Korea, allow all requests that come from your headquarters location, and require MFA for all the rest. Moreover, you can create multiple policies that work together to put guardrails in place exactly where you need them.
To see how it works, let’s dive into the details.
Components of an Azure AD Conditional Access policy
Essentially, a Conditional Access policy is an if-then statement: If an authentication attempt meets the specified criteria (assignments), then apply the specified access controls. Here’s what the screen for creating a policy looks like:
The Name section is straightforward enough, but let’s review the other three critical elements of Conditional Access: Assignments, Access controls and Enable policy.
The Assignments section is the “if” portion of the policy; it specifies what has to be true for the policy to kick into action. It is divided into three areas:
- Users and groups — The Users and groups section specifies who the policy will include or exclude. A policy might apply all users, all Finance team members, or just B2B guests and external users.
- Cloud apps or actions — You can also specify which cloud apps or actions the policy will include or exclude. For example, you can create a policy that applies anyone accessing Office 365 and one that applies only to folks trying to use PowerApps.
- Conditions — A policy must contain one or more conditions, which are sometimes also called signals. These include the device’s operating system, location and client apps, as well as risk information from Microsoft Identity Protection (if you have an Azure AD Premium P2 license). Multiple conditions can be combined to create very fine-grained policies.
You also control what happens when a policy’s assignments are satisfied. One option is to simply block access. That can be appropriate in some cases, such as requests to access highly sensitive apps that come from highly suspicious locations, or any authentication attempt that uses a legacy authentication protocol. (Since legacy authentication does not support MFA, even if you have MFA enabled, an attacker using an older protocol could bypass MFA.) However, blocking access can have unintended side effects, so use it with caution.
More often, you’ll want to choose to grant access but put additional hurdles in place, such as requiring MFA, requiring the device to be marked as compliant (requires Microsoft Intune) or requiring an approved client app.
It’s crucial to test your policies before you deploy them in your production environment. Policies can be complex and apply to broad swaths of users, so it can be quite difficult to anticipate their impact. For example, do you know offhand what would happen to important business processes if you blocked all legacy authentication? Now imagine if you designed a more complex set of risk conditions and required MFA or compliant devices based upon the result — how many users would be impacted? Would your helpdesk be ready to handle the fallout?
Moreover, remember that multiple policies can apply during a given sign-in. In that case, the assignments are logically ANDed. For example, suppose two policies apply to you: one that requires MFA and another that requires a compliant device. In that case, you must complete MFA and use a compliant device. Is that what you intend, or is it more stringent than necessary?
Testing is essential to understanding how your policies would work in practice so you can assess whether the results are appropriate and desirable. Accordingly, by default, Enable policy is set to Report-only for new policies. In this mode, you get a powerful Conditional Access insights and reporting workbook that will help you assess the impact of the new policy. Once you verify that the policy works as intended, you can apply it to everyone by setting Enable policy to On. If you have a policy that you want to save without it being active, simply change the setting to Off.
Does my organization need Azure AD Conditional Access?
Now that we’ve covered what Conditional Access does, let’s tackle the harder question: Who needs it and who doesn’t?
There’s no doubt that Azure AD Conditional Access policies can be valuable, but they do require setup, thorough testing and ongoing maintenance. Before you make that investment of time and effort, be sure to review the security that Microsoft provides out of the box.
To help organizations establish a basic level of security, Microsoft makes security defaults available to everyone at no extra cost. New tenants get security defaults automatically. For older tenants, you can turn on security defaults in the Azure portal. This feature automatically enforces the following policies:
- All users must register for Azure AD MFA.
- Users must complete an MFA step when they authenticate using a new device or application, and when the request to perform critical tasks.
- Administrators must complete an MFA step every time they sign in. This policy applies to nine key Azure AD roles, including Global Administrator, SharePoint Administrator, Exchange Administrator, Conditional Access Administrator and Security Administrator.
- Any user trying to access the Azure portal, Azure PowerShell or the Azure CLI must complete additional authentication.
- All authentication requests made using older protocols are blocked.
For some organizations, these default security measures are sufficient, at least for a while. But if you want more fine-grained control, you need to use Azure AD Conditional Access instead of the security defaults. (You can’t use both.) Alex Weinert, Director of Identity Security at Microsoft, offers additional advice in his blog post on security defaults.
How do I set up Conditional Access?
To create, modify or check Conditional Access policies in Azure AD, you must sign in to the Azure portal as a Global Administrator, Security Administrator or Conditional Access Administrator.
How to create a Conditional Access policy
- Navigate to Azure Active Directory > Security > Conditional Access.
- Click New policy.
- Give your policy a name and complete the other three critical elements of Conditional Access (Assignments, Access controls and Enable policy) as described earlier in this blog post.
How does Conditional Access relate to Zero Trust?
So glad you asked! I hope you had a chance to read my blog post about Zero Trust. As I explained there, Zero Trust is a security model for modern IT environments built on the recognition that a strong perimeter is no longer enough for ensuring security and compliance. Instead, organizations need to accept that breaches are inevitable and malicious forces might well be inside the network already.
Azure AD Conditional Access is an extremely valuable tool for helping you implement a Zero Trust model. Indeed, it helps you implement all three core principles detailed in Microsoft’s Zero Trust Deployment Guide for Microsoft Azure Active Directory:
- Least privilege — Conditional Access helps you grant the right access at the right time to only those who need it by enabling you to configure trusted locations and IP ranges, implement stronger controls for more privileged users, and control access to sensitive applications and content.
- Verify explicitly — Azure AD Conditional Access also helps you continually verify identities as users move around the network by requiring MFA when users appear on new devices and from new locations.
- Assume breach — Weak passwords, password spraying and phishing all but guarantee malicious actors are inside your network. Conditional Access helps you keep them from achieving their goals with measures like blocking legacy authentication and putting stronger access controls in front of your most valuable resources.
Azure AD Conditional Access is a powerful tool for strengthening security and ensuring regulatory compliance. Using the information and links in this blog post, you can make an informed decision about whether to implement it in your organization.