In-Depth

Conditional Access Policies - Your New Firewall

• By Paul Schnackenburg
• 07/30/2024

In my many years as an IT trainer I have always emphasized the importance of "plumbing technologies" that fade into the background so that no-one thinks about them until they break. Examples include internal DNS name resolution -- "Active Directory is broken," no it's most likely not, you've just misconfigured the DNS servers on the client. Or DHCP scopes have run out of IP addresses and now everyone thinks there's something wrong with the network, or file share permissions rely on complex group structures created 20 years ago and now someone deleted the wrong group and no one can access their documents.

In the cloud it can be authentication. This VM isn't starting because it can't access its managed identity, or this automation stopped working because an access key changed, and no one noticed for a month. And of course, it can be a routine update to an EDR product that wasn't tested properly, and the whole world notices when 8.5 million machines crash simultaneously (cue the meme of old Obi-Wan clutching his chest saying "it was like a million voices cried out in terror and were suddenly silenced").

In some businesses I suspect Conditional Access policies in Entra ID have also become plumbing technology. They've grown in importance for years, and are now the equivalent of a firewall for access to everything. In this article I'll give a brief introduction to Conditional Access (CA) policies, what you can use them for and how they work. Then we'll look at some new alternatives for managing them (given their importance) such as the Maester open-source tool, options for backing them up and a documentation tool.

Conditional Access Policies 101
In the Entra ID portal, under Protection - Conditional Access - Policies, you'll find all policies listed.

To use CA policies, you need a minimum of Entra ID P1 licensing, part of M365 E3. If you step up to Entra ID P2, you get Identity Protection (IdP). This uses machine learning in the background to correlate information about a user account to assign a risk score to the account. If it's elevated, CA policies can kick in and force the user to change their password on the next login, for example. The same is done for every single sign-in (in real time), and again, if the sign-in risk is elevated, you can have a policy that requires an extra MFA prompt just to make sure it's really you.

CA policies are built using Assignments (user and group accounts, with optional exclusions), Target resources (cloud apps or user actions), Network (trusted networks, and if you're using Microsoft's VPN replacement, Global Secure Access (GSA), compliant network locations) and Conditions (user and sign-in risk, insider risk, device platform, client app).

Based on the combination of all those conditions (this user, on this device, from this network, accessing this resource from this client application), you then set the Access controls (kudos to Microsoft for actually having a logical name for this feature). Options include blocking the access, granting it but require MFA, require a particular flavor of MFA, a compliant device, a device joined to both AD and Entra ID (hybrid) or require a password change. You can add some session controls such as sign-in frequency and round it off by creating a policy in the Off state, Report-only or On. Speaking from firsthand experience, Report-only is your friend here, letting you see what would have been blocked to ensure that the policy does what you want it to do, and doesn't cause a RGE (Resume Generating Event) when you lock everyone out.

Conditional Access Policy Uses
Now that you understand the power of CA policies, let's look at what you can use them for. Microsoft provides a set of handy templates to create new policies from:

• Require MFA for admins, users, Azure / M365 management access, risky sign-ins, or guest access.
• Requiring MFA for registering a new device for a user.
• Block legacy authentication protocols (which don't support MFA).
• Require compliant / hybrid Entra ID joined devices for access.
• Limit access in SharePoint Online / OneDrive / Exchange Online depending on the device / network used to access it.
• Block access for users flagged for Insider risk.
• Control access to on-premises applications, Microsoft 365 apps and third-party SaaS cloud applications through Microsoft's Secure Services Edge solution, GSA.

And of course, you can build custom policies for just about anything you can think of.

Common use cases include blocking or limiting access to corporate data from personal devices, enforcing MFA for access to sensitive applications, controlling access from different locations and networks and making sure IT administrators in particular can only perform management in a secure manner.

There are also a few Microsoft-managed CA policies that enforce best practices in all tenants, unless you disable them (you can't edit these)

Operationalizing CA Policies
By now you should have a good understanding of how powerful CA policies are, but as more and more conditions have been added, with more complex grant options, truly understanding that they're working as expected is difficult. There's also the ongoing reality of entropy. A real-world example is a business that created a policy to ensure that guest users performed MFA at least every 14 days. But sometime later, another administrator deleted the group that the CA policy was scoped to. The CA policy was still active -- an audit would have ticked the box that it was working as expected -- but only through deeper investigation would you have realized that it was in fact doing nothing.

This is where the new open-source project Maester comes in. It's built on the popular Pester test framework for PowerShell, but adapted to make it easy to use for IT administrators who are not PowerShell experts (like me) to use. It was created by Merill Fernando, Fabian Bader and Thomas Naunheim. It'll download new tests that are added automatically, and you can also write your own custom tests for your environment. There's quite a community around Maester already (it's been out for less than a year), and they're developing more tests for other Microsoft products.

Getting started is straightforward. Run the following commands in a PowerShell 7+ window:

Install-Module Pester -SkipPublisherCheck -Force -Scope CurrentUser
Install-Module Maester -Scope CurrentUser
md maester-tests
cd maester-tests
Install-MaesterTests
Connect-Maester
Invoke-Maester

You'll need to sign as part of Connect-Maester, and you'll need to approve access to the Microsoft Graph API if you haven't done so previously.

This is the step where you approve read-only access to the API:

Optionally you can add the tests that are part of CISA's free Secure Cloud Business Applications (ScuBA) security configuration baselines by running these additional commands:

Install-Module Az -Scope CurrentUser
Install-Module ExchangeOnlineManagement -Scope CurrentUser
Connect-Maester -Service All

This adds another set of tests that are performed.

Unlike with Pester in normal PowerShell, you don't get a wall of red text when tests fail. Instead, Maester generates an easy-to-read HTML report (JSON is an optional output format), showing how this tool is geared toward IT administrators and not developers.

When you click on each test, you get a detailed description of why the setting is important, what the recommended state is and how to remedy (if the test failed), along with links to further documentation.

That's running the tests interactively as a once-off, which is a good start and gives you a to-do list to work through to fix any important issues. Maester also supports integration with Azure DevOps, Azure Automation or GitHub Actions to have it run regularly (daily) and even email you the reports.

Backing up Conditional Access Policies
Another fundamental task in IT is to back up anything important, which definitely includes CA policies. There are some PowerShell cmdlets available, but they rely on accessing the Microsoft Graph API, which isn't exactly non-developer territory. I like this particular solution in Microsoft's Azure GitHub repository, as it creates a Logic App, backs up the JSON version of each CA policy to OneDrive for Business, relies on managed identity (instead of a password or certificate) and has built-in functionality for running regularly.

Documenting Your Conditional Access Policies
Another important task is documenting your CA policies, and track changes. The aforementioned Merill Fernando (who works at Microsoft here in Australia), maintains a great site, idPowerToys, which currently hosts two tools. The Conditional Access Documenter is simple, just sign in to your tenant, then click Generate documentation.

The output is a PowerPoint file, which is an interesting choice for documentation, but each policy gets its own slide, clearly showing who the policy applies to, what the Grant settings are, the target resource and any Session controls.

Conclusion
Conditional Access policies have gone from a minor part of most organization's security posture a decade ago, to now being a crucial part of the overall Zero Trust identity access process. It's time we started managing CA policies seriously, checking them against best practices regularly with Maester, backing them up and documenting them.