Designing, evaluating and deploying Conditional Access Policy Framework (2023 Edition)

Azure AD Conditional Access Policies were released in 2016. Since then there have been lots of improvements and the prefix has changed from Azure AD to Entra ID. Basic principles have stayed the same, though. Meaning that CA Policies are crucial feature when protecting identities. This blog posts concentrates on designing and deploying CA Policy framework into production. Recommended background info can be found in these sources:

Techdays 2019 – Protecting User Identity with Azure AD Conditional Access – Bloggerz.cloud (albeit a bit dated, but still valid)

https://learn.microsoft.com/en-us/azure/architecture/guide/security/conditional-access-architecture

https://learn.microsoft.com/en-us/azure/architecture/guide/security/conditional-access-framework

Why now?

Many organizations have CA Policies in place and have had for years. Typical issue is that because the targeting of the policies is very wide there needs to be certain amount of exclusions and exceptions so that the end result has more gaps than London tube platforms.

Additionally the ways and scenarios of working have changed during the past years rather radically and that presents different kinds of challenges for protecting identity.

Lastly the technology itself has evolved and become more advanced to better suit different use scenarios.

That is why now is good time to re-evaluate and possibly re-construct CA Policies based on Microsofts Conditional Access Policy Framework idea.

Planning and designing

When planning for CAP Framework the first step is to recognize different target groups that Microsoft calls Personas. Most common Personas and their targeting are described in table below

Now as you can see there are different use scenarios that obviously all cannot meet one policy. In order to keep the exclusions minimal we want to target different policy requirements to different Personas. If we would target same policy for Internal and Service accounts we would probably need to have some network exclusions in place that actually are needed only for the Service accounts and not Internal accounts. You get the idea.

For those Personas the policies could be designed for example like this:

Note that because we are targeting policies per Personas and not all users (except Global Persona) we need to have the “CatchEmAll” policy in place in order to prevent login from any and all accounts that are not targeted policies via specified Personas. Otherwise you might still have gaps that you wouldn´t know about.

And yes I am aware that to prevent Advisory in the middle – attacks it is recommended that browser access would also require compliant / hybrid joined device. If that kind of policy is possible to deploy in your environment, go for it. Just know that by default it basically prevents the use of InPrivate/Incognito modes with browsers.

NOTE!: Always deploy your planned policies to Report Only – mode to gather data before actually enabling them

CAP targeting

So now you have recognized at least some of your target Personas and planned suitable policies for them, good. Next step is to identify or create the actual groups that the policies will be targeted to. You should begin with Internal and External Personas. It is obviously beneficial if you can take advantage of Dynamic groups or groups that are populated automatically via for example IDM solution. For dynamic group targeting you can use attributes such as EmployeeType for example.

After you have Internal and External sorted out pay some attention to the Admin Persona. Easy way is to tick all the Entra ID Admin Roles and target the policy to them. Thats a good start, but then you must also consider the following:

• Admin users that don´t have any Admin role before activating PIM
• Accounts that are admins in some systems (Sharepoint, Teams, Exchange, Defender) via RBAC and not via Entra ID Admin Role
• Accounts that have admin permissions to OnPrem and are used for logging to cloud (probably without you knowing about it)

So my suggestion is that you also create a group that has all the Admin accounts and target the Admin policies to that as well as the Entra ID admin roles.

Guest Persona is fairly easy. Just tick them from the CAP targeting options.

If you have Shared and Service accounts currently identified and separated to different groups or OUs good for you. Then you should have no problems with targeting CA Policies to them. If you are like most then you probably don´t have that luxury or you think have, but actually you don´t. This is when the “CatchEmAll” Policy comes in handy.

After you have created / identified the targeting groups for Internal, External and Admin groups you can create the CatchEmAll policy and configure it to target all users and exclude Internal, External, Admin and Guests from the policy. This way you can get data on all the logins that don´t fall in any of your target groups currently. Among these are probably some Shared and Service accounts and you can even come across some use scenarios and findings you never thought existed.

Insights and reporting

Now that you have implemented the policies in “Report Only” mode for at least some of your Personas and target groups it´s time to take a look at the reports and evaluate the actual effects of the policies. I assume you are familiar with CAP Insights and reporting – tool so I wont waste time on explaining that here. Instead I summarize an example what you should be looking into:

Internal	How many users use desktop client from non-compliant or non-hybrid joined device
External	How many users use desktop client
Admins	How many logins from admin – accounts that don´t have admin role in Entra ID
CatchEmAll	What accounts fall into this category and why

You then use the data and information to fine-tune policies or to recognize needs for new Personas and target groups. Examples being:

• RPA Accounts
• Test Accounts
• Other Special accounts you had no idea about

Every time you create a new Persona and target group you should exclude that from the CatchEmAll policy. After some period of analysing and planning you should have a pretty good undertstanding of needed Personas and policies to them. At this point there shouldn´t be any “hits” to the CatchEmAll policy. You will also probably notice that some of the service or other special accounts are accessing from cloud services or other locations that are not known and therefore some accounts need to be excluded from the policies totally. You should create one exclusion group for these and it´s members should be monitored and it should not ever contain any end user accounts, only service accounts.

Some other key principles include

• No network location exceptions in any other policies than Shared (if necessary), Service and/or other special accounts that definately require it
• No targeting exclusions in any other policies than Service and/or special accounts
• If for whatever reason some exclusions are needed they should always be targeted with some other policy and if not then blocked by the CatchEmAll policy.

Deploying the policies

When you are ready to deploy the policies your CAP framework could look something like this:

In this example we decided to target the Internal policies per platform for fine-graining reasons. If you do that then remember to also include “Other platforms” which means all platforms except the ones you have created a policy for.

I recommend deploying the policies one Persona at a time beginning with the Internal persona and monitoring closely. And as always keep your production support teams involved and informed.

Even if you have planned CAP framework really well you can still come across some issues that you did not foresee. Here are some of those listed:

• Device is hybrid joined, but still not recognized as compliant
  • Check device registration state and date from Entra ID. If the date is “Pending” then re-register manually from the device side.
• Internal users accessing services from server OS:s (for example Citrix) that are not recognized as Hybrid joined or compliant
  • Might require network location exception to Internal policy. In that case there should be dedicated public IP for all connections from Citrix environment.
• Accounts in different target groups that are used for scenarios that cannot meet policy requirements
  • Add to exclusion group and document and monitor extra carefully

Conclusion

Protecting identity is even more important than it has been before. Start by deploying carefully planned CAP framework and then add more specific policies on top of it if necessary. Microsoft has just announced a variety of new features and increasing utilization of Conditional Access Policies for example Private access. Make sure you have the base framework in place and sleep your nights more peacefully.