Conditional Access framework and policies

This article provides a framework for implementing a persona-based Conditional Access architecture, like the one described in Conditional Access Zero Trust architecture. In this article, there are details on how to form and name the Conditional Access policies. There's also a starting point for creating policies.

If you don't use a framework like the one provided here, including a naming standard, policies tend to be created over time by different people in an ad-hoc way. This can result in policies that overlap. If the person who created a policy is no longer available, it can be difficult for others to know the purpose of the policy.

Following a structured framework makes it easier to understand the policies. It also makes it easier to cover all scenarios and avoid conflicting policies that are difficult to troubleshoot.

Naming conventions

A properly defined naming convention helps you and your colleagues understand the purpose of a policy, which enables easier policy management and troubleshooting. Your naming convention should fit the framework you use to structure your policies.

The recommended naming policy is based on personas, policy types, and apps. It looks like this:

<CANumber>-<Persona>-<PolicyType>-<App>-<Platform>-<GrantControl>-<OptionalDescription>

The components of this name are described here:

Numbering scheme

To make administration easy, we suggest this numbering scheme:

Policy types

These are the recommended policy types:

App

The following table describes the App component of a policy name:

Platform type

The following table describes the Platform component of a policy name:

Grant control types

The following table describes the Grant Control component of a policy name:

Named locations

We recommend that you define these standard locations for use in Conditional Access policies:

• Trusted IPs / Internal networks. These IP subnets represent locations and networks that have physical access restrictions or other controls in place, like computer system management, network-level authentication, or intrusion detection. These locations are more secure, so Conditional Access enforcement can be relaxed. Consider whether Azure or other datacenter locations (IPs) should be included in this location or have their own named locations.
• Citrix-trusted IPs. If you have Citrix on-premises, it might be useful to configure separate outgoing IPv4 addresses for the Citrix farms, if you need to be able to connect to cloud services from Citrix sessions. In that case, you can exclude those locations from Conditional Access policies if you need to.
• Zscaler locations, if applicable. Computers have a ZPA agent installed and forward all traffic to the internet to or through Zscaler cloud. So it's worth defining Zscaler source IPs in Conditional Access and requiring all requests from non-mobile devices to go through Zscaler.
• Countries/regions with which to allow business. It can be useful to divide countries/regions into two location groups: one that represents areas of the world where employees typically work and one that represents other locations. This allows you to apply additional controls to requests that originate from outside the areas where your organization normally operates.
• Locations where multi-factor authentication might be difficult or impossible. In some scenarios, requiring multi-factor authentication could make it difficult for employees to do their work. For example, staff might not have the time or opportunity to respond to frequent multi-factor authentication challenges. Or, in some locations, RF screening or electrical interference can make the use of mobile devices difficult. Typically, you'd use other controls in these locations, or they might be trusted.

Location-based access controls rely on the source IP of a request to determine the location of the user at the time of the request. It's not easy to perform spoofing on the public internet, but protection afforded by network boundaries might be considered less relevant than it once was. We don't recommend relying solely on location as a condition for access. But for some scenarios it might be the best control that you can use, like if you're securing access from a service account from on-premises that's used in a non-interactive scenario.

Recommended Conditional Access policies

We've created a spreadsheet that contains recommended Conditional Access policies. You can download the spreadsheet here.

Use the suggested policies as a starting point.

Your policies will probably change over time to accommodate use cases that are important to your business. Here are a few examples of scenarios that might require changes:

• Implement read-only access to Exchange Online for employees using any unmanaged device based on multi-factor authentication, app protection, and an approved client app.
• Implement information protection to ensure that sensitive information isn't downloaded without improved protection provided by Azure Information Protection.
• Provide protection against copy and paste by guests.

Multiple previews are currently going into public preview, so expect updates to the suggested set of Conditional Access (CA) starter policies soon.

Conditional Access guidance

Now that you have a starter set of Conditional Access policies, you need to deploy them in a controlled and phased way. We suggest that you use a deployment model.

Here's one approach:

The idea is to first deploy policies to a small number of users within one persona group. You can use an associated Microsoft Entra group called Persona Ring 0 for this deployment. After you verify that everything works, you change the assignment to a group, Persona Ring 1, that has more members, and so on.

You then enable the policies by using the same ring-based approach until all policies are deployed.

You typically manage the members of ring 0 and ring 1 manually. A ring 2 or 3 group that contains hundreds or even thousands of users could be managed via a dynamic group that's based on a percentage of the users in a given persona.

The use of rings as part of a deployment model isn't just for initial deployment. You can also use it when new policies or changes to existing policies are required.

With a finished deployment, you should also design and implement the monitoring controls that were discussed in the Conditional Access principles.

In addition to automating the initial deployment, you might want to automate changes to policies by using CI/CD pipelines. You could use Microsoft365DSC for this automation.

Contributors

This article is maintained by Microsoft. It was originally written by the following contributors.

Principal author:

• Claus Jespersen | Principal Consultant ID&Sec

To see non-public LinkedIn profiles, sign in to LinkedIn.

Next steps

• Learning path: Implement and manage identity and access
• Conditional Access policies

Related resources

• Conditional Access overview
• Conditional Access design principles and dependencies
• Conditional Access design based on Zero Trust and personas
• Microsoft Entra IDaaS in security operations