This blog post is part 3 in a series. If you have not seen parts 1 and 2, you should go back and read those first.

Now we are really on that ladder! For me, MFA should be the default level of security for all Azure AD accounts as I stated in the last post in this series. Now we are getting into “advanced” features that you should consider. The rest of the features we will talk about in this series are going to require high license levels, and more administrative work to implement and maintain. Many accounts in many organizations may not need the higher levels of protection that we will talk about from this point forward.

After you have managed your way up the first rung of our metaphorical ladder, you are ready to move on to more complex configurations. Rung 2 is conditional access.

Rung 2: Conditional Access

Not all authentication attempts are equal. For an organization that is completely US based, a login attempt from your offices in New York is probably rates considerably less scrutiny than a login attempt from China. Azure AD gives originations a powerful tool for evaluating authentication requests and handling them differently based on many factors.

Before “the cloud” IT departments generally hosted most or all of their applications in a company owned data center that are separated from the public internet by firewalls. With IT assets moving to the cloud, that clear separation of users authenticating to data from inside the company network may not exist.

By using Conditional Access (CA) policies, you can apply the right access controls when needed to keep your organization secure and stay out of your user's way when not needed.

Licensing for CA

CA does require that each user taking advantage of this feature have an Azure AD Premium P1 license. There are circumstances where this licensing requirement is not enforced, but keep in mind that you are required to have that license level for each user using CA.

All Office 365 licenses include Azure AD Basic. To Get Azure AD Premium (either P1 or P2) you need to buy EMS, Microsoft 365, or the Azure AD Premium stand-alone licenses.

Signals used by CA policies

Conditional access polices are examined after the first factor authentication has been completed. Once that first factor authentication is validated, CA takes over and can examine any or all of the following signals in the flow of authenticating that specific authentication request.

• User or group membership – CA policies can be targeted to specific users and groups giving you the ability to designate a different authentication flow for different groups of users within your organization.

• IP Location information - You can create trusted IP address ranges that can be used when making policy decisions. You can also specify entire countries/regions IP ranges from which to block or allow traffic.

• Device - Users with devices of specific platforms or marked with a specific state can be used when enforcing Conditional Access policies. We will cover device compliance in a later rung of our auth ladder.

• Application - Users attempting to access specific applications can trigger different Conditional Access policies.

• Real-time and calculated risk detection - Policies can force users to perform password changes or multi-factor authentication to reduce their risk level or be blocked from access until an administrator takes manual action.

• Microsoft Cloud App Security (MCAS)- Enables user application access and sessions to be monitored and controlled in real time, increasing visibility and control over access to and activities performed within your cloud environment. MCAS will be covered in more detail high up our auth ladder.

Based on the above signals, CA policies can either allow or deny an authentication attempt. When allowing an authentication attempt, CA policies can also be configured to require:

• multi-factor authentication (rung 1)

• device to be marked as compliant by Intune

• Hybrid Azure AD joined device

• approved client app

• app protection policy

There are many different scenarios for which CA allows enhanced authentication flows. How about I list a few of the more common scenarios where CA is useful.

Common CA Policies

While this is not intended to be a comprehensive list of everything you can do with CA policies, I find it’s helpful to give customers a few ideas of the more commonly deployed CA policies and let them run from there.

Require terms of use – If your organization has a terms of use statement that users must agree to before they can access company data, you can implement a CA policy that will force users to accept those terms of use as part of the authentication flow.

Block legacy authentication – As part of the Rung 1 discussions, we talked about MFA. As covered there “legacy authentication” in the Microsoft world is authentication via a protocol that does not support MFA. While there are other ways to force users to use MFA to authenticate into your Azure AD tenant, a CA policy that blocks legacy authentication is the quickest and easiest.

Require MFA for administrators – As you work through the process of requiring MFA for all authentication into your Azure AD tenant, you can implement a CA policy that will require MFA for any account with admin privileges. Using Privileged Identity Management (PIM) in conjunction with this policy will allow admins to authentication without MFA when their admin roles are not active, but force MFA when they have an active admin role.

User risk-based CA – While this requires Azure AD Premium P2 licensing, it is possible to create a CA policy that will force users into more detailed authentication scenarios based on their risk. This enables scenarios like forcing users to change their password if Microsoft finds that username/password combination in a leaked data set or forcing users to authentication flows with MFA when they are signing-in from non-company owned devices.

Require managed devices – In conjunction with Azure AD device management (covered in a higher rung) CA can block users from accessing your organization’s data from non-compliant devices.

Require approved client apps – In a BYOD scenario, it can be very difficult for IT departments to support an almost infinite number of different client apps that can be used to access Office 365 data. CA policies can be implemented to only allow users to use approved apps like the Outlook Mobile app when accessing company e-mail.

Testing CA policies

Implementing CA policies must be done carefully. A reckless implementation of a CA policy can easily cause large numbers of your users to be locked out of Azure, Office 365, and any other applications that rely on Azure AD for authentication. There are two stragity I recommend for avoiding a catastrophic CA policy implementation.

Firstly, I recommend assigning your CA policies to test users and test groups before a full roll out to your user base. When creating a CA policy, you will have the option to apply that policy to specific users or groups. I highly recommend a testing new CA policy with small groups of users or test users who will not be sorely impacted if the policy turns out to be too restrictive.

The second testing suggesting is for organizations to take advantage of the “What If” tool in the CA portal. This tool can simulate the results of an authentication attempt for a specific user in specific situations. It does take a bit of practice to become proficient with the What if tool, and I would rate its usefulness as below a good testing of a CA policy with a test account. The What if tool can still come in handy for pointing out unexpected allow or denials for a new CA policy.

Does AD FS do CA?

AD FS does have a feature called “claims rules” that can work similarly to CA policies, however there are several important differences.

1. AD FS claims rules are much more complicated to setup and maintain than CA policies.

2. AD FS claims rules are do not include the same level of functionality that CA policies do. There is just more you can do with a CA policy.

I believe that the only real-world functionality I have personally deployed with AD FS claims rules is to prevent users from authenticating into Office 365 from home. I have not deployed this in a few years, and if a customer asked for this setup today, I would steer them in the direction of using CA policies over AD FS claims rules.

I am not going to do a deep dive into AD FS claims rules here. I think it’s enough for now to state that AD FS claims rules can provide some of the functionality you get with CA policies, but I feel claims rules is a far inferior solution.

Continuing up the ladder

That’s what I have to say about Conditional Access. The next rung in our auth ladder is going to be device compliance.

Stay tuned.