Master Planning and Implementation of Conditional Access Policies
Conditional Access is one of Microsoft’s most adaptable and powerful security features. Over the years, it’s grown into a robust tool, with a steady stream of new features being added by Microsoft, like implementing authentication context to identify confidential information that should be protected.
However, despite its impressive capabilities, many organizations still find it challenging to implement Conditional Access effectively. If you’ve ever found yourself tangled in its complexities, you’re not alone. The importance of Conditional Access, especially in the drive to make multifactor authentication the norm, makes it a hot topic. However, when introduced to an organization, the impact of Conditional Access on users and the ripple effect on the overall workflow of an organization can be significant. And let’s be honest, Microsoft’s validation and testing tools fall short of what admins really need. But don’t worry, there’s hope on the horizon!
An Open-Source Framework to the Rescue
With these challenges in mind, I began developing custom scripts and methods to help myself implement and test Conditional Access. After over two years of refinement, I bundled them into the Conditional Access Blueprint (Figure 1). This toolset is designed to help organizations create and validate access policies and strategies, ensuring that security measures are effective and efficient. The framework addresses these challenges with four tools: two for building Conditional Access policies and two for validating their implementation.
Tool #1: Persona Flow Diagram
The first step to building access security is defining the types of accounts used in an Entra environment. We call these personas. A persona can be:
- a group of users/identities: e.g. regular users, ADM users, DEV users, external users, Entra roles, a group of Service Principals, emergency accounts, C-level users, service accounts, or non-interactive accounts (like Entra Connect sync accounts, phone service accounts, server service accounts, meeting room service accounts, etc.)
- an individual user/identity: such as a service account, a Tier 0 account, an Entra role, or a Service Principal.
It is recommended to start by listing all existing personas in your environment. For this, you can use a table with the following columns:
- ‘Persona’
- ‘Persona Owner’ (individual or team responsible for the persona)
- ‘Persona Description’
- ‘Entra Group Name’.
To visualize the relationships and structure, a good practice is to create a hierarchy chart like the one shown in Figure 2. The chart helps to understand how different personas interact and their place within the organization.
For each persona, define the specific access restrictions or actions that should be applied to that particular persona. To assist with this process, the framework includes a flow diagram. By following the diagram (Figure 3) from start to finish for each persona, you can identify the various actions and restrictions that should be included in a CA policy. This systematic approach ensures that all the necessary security measures are considered.
Tool #2: Policy Requirements
As you work through the Persona Flow Diagram, it’s crucial to document the specific actions and restrictions you plan to apply to each persona. An Excel template is included in the framework for this purpose.
Download the template and list your personas horizontally across the prepared cells. For each security restriction (listed vertically), indicate whether it applies to each persona.
Once you’ve documented all security restrictions for each persona, the next step is to group them. This process will guide you in creating or adjusting your Conditional Access policies. By reviewing each security restriction, you can determine which personas should be included in the policy that enforces this action. The objective is to create Conditional Access policies once and then simply add or remove personas (Entra groups) as needed.
Table 1 lists the names of some example policies you might create:
CA Policy | Included personas | Excluded personas |
CA001 – All Apps: Block legacy authentication | … | … |
CA002 – All Apps: Require MFA | … | … |
CA003 – All Apps: Require phishing-resistant MFA | … | … |
CA100 – All Apps: Require compliant device | … | … |
CA101 – All Apps: Block all devices except Extension Attribute ‘MeetingRoomDevices’ | … | … |
CA102 – All Apps: Block old Windows versions | … | … |
… | … | … |
By adding or excluding personas to the set of Conditional Access policies, your organization will have a strong, clear, and well-documented access security setup based on personas and use cases.
Tool #3: Impact Matrix
Now that documentation for the Conditional Access policies is available, verifying its effectiveness is vital. The Conditional Access Impact Matrix (Figure 4) is designed to help you achieve this by addressing two main challenges:
- Policy Application and Conflicts: Understand which Conditional Access policies are applied to whom and whether there are any conflicts.
- User Impact: Review the impact of recent Conditional Access changes on users.
Running the Conditional Access Impact Matrix tool requires Node.js and an Entra App Registration to connect to the tenant, as detailed in the setup guide.
This Excel report (Figure 4) allows you to quickly filter and review the user accounts that are included or excluded from each of the Conditional Access policies. It simplifies periodic reviews and helps answer common access-related questions. Having these insights is often a requirement to meet security compliance standards. The report includes columns for ‘user internal’ and ‘user enabled’ statuses. Here are some examples of the questions it can help you answer:
- Which internal user accounts are exempt from MFA?
- Which service accounts are restricted to specific IP addresses?
- Which user accounts have access to Azure Management applications?
- Which users are permitted to use legacy authentication methods?
- Which external users are allowed to use Linux devices?
Use the following command in the terminal to run the script:
<em>node index.js</em>
To include Conditional Access policies in ‘report-only’ mode in the report, use the command:
<em>node index.js --include-report-only</em>
The output, in both CSV and JSON formats, will be automatically saved to the directory the script is run from. After opening the CSV file, Conditional Formatting can be applied in Excel, and filters can be added to the table for easier analysis.
The CA Matrix report enables the assessment of how recent Conditional Access changes have affected users. By specifying a previously generated report when running the script, it calculates the impact of changes on users (Figure 5). These changes may result from group membership modifications, direct assignments, or deletions. Many organizations don’t use Entra Groups exclusively for Conditional Access, even though it is a common practice.
To compare the current output with a previously exported one, use the command:
<em>node index.js --compare <Impact-Matrix-export>.json</em>
This will open a web page (Figure 6) showing the differences between the previous and current export.
Tool #4: Simulator
Finally, I want to introduce you to compliance-based testing for Conditional Access. This is the approach of continuously verifying both common and malicious access situations in your environment. Policy misconfigurations are frequent and can lead to security gaps or incidents. An organization’s Conditional Access setup should reflect the access policies defined by business, so it’s crucial to regularly check if the setup still aligns with the agreed vision.. While Microsoft’s What If tool exists, it has limitations: it doesn’t allow saving and running multiple simulations, repeated scenario testing, or providing strategic and technical insights that map to compliance controls, nor does it offer clear outcomes of the simulations.
In February 2022, the Conditional Access Simulator was developed as a closed-source paid web service, enabling organizations to simulate and validate their access policies across various scenarios and predict the impact on users. In 2024, Maester (open-source) was released offering similar functionality. An advantage of Maester (Figure 8) is that an organization can add its own tests (written in PowerShell) to the framework.
These Breach and Attack Simulators (BAS) allow you to define the expected outcome of each simulation (e.g., MFA, company device, password reset, block). If the simulation results match the expected actions, your setup is compliant. If not, it indicates a misconfiguration or an incorrectly configured Conditional Access policy. These reports can earn you credits from your CISO! Additionally, tools like the Conditional Access Documenter can export PowerPoint documentation of Conditional Access policies for review or sharing with security teams and stakeholders.
Conclusion
The Conditional Access Blueprint is a useful tool for any organization aiming to enhance its access security strategy. By using the four tools contained in the blueprint, you can ensure that your Conditional Access policies are well-defined, effectively implemented, and continuously validated. This approach mitigates many risks associated with Conditional Access and empowers the security team to maintain a secure and efficient access management system.