Here we go again, starting with Conditional Access naming convention! First of all, what is conditional access policies (CA policies)? I hate reinventing things that are already invented, so from Microsoft:
“Modern security extends beyond an organization’s network perimeter to include user and device identity. Organizations now use identity-driven signals as part of their access control decisions. Microsoft Entra Conditional Access brings signals together, to make decisions, and enforce organizational policies. Conditional Access is Microsoft’s Zero Trust policy engine taking signals from various sources into account when enforcing policy decisions.
Conditional Access policies at their simplest are if-then statements; if a user wants to access a resource, then they must complete an action. For example: If a user wants to access an application or service like Microsoft 365, then they must perform multifactor authentication to gain access.”
Blog series overview
How about them Conditional Access Policies! Part 1 – Naming convention – Wallo Blog
How about them Conditional Access Policies! Part 2 – Policies that everyone needs – Wallo Blog
How about them Conditional Access Policies! Part 3 – Advanced policies – Wallo Blog
Sound simple, right?
When it comes to Conditional Access (CA) policies, I’ve learned a few key do’s and don’ts. One of the most critical aspects is the naming convention. Properly planning your naming convention before rolling out refreshed policies is essential. Often, old policies are a tangled mess, and a “refresh” is simpler than trying to decipher the existing ones.
Here are some insights and recommendations for refreshing and naming of CA policies:
- Start with a Clean Slate: Old policies, especially those older than five years, can be outdated and may not utilize new features or meet current organizational security needs. Refreshing these policies can bring them up to date with the latest security standards.
- Leverage Zero Trust Principles: Many organizations aim to implement Zero Trust principles. Ensure your refreshed CA policies align with these principles to enhance security.
- Annual Review: It’s crucial to review your CA policies yearly. This helps ensure they remain relevant and effective in addressing evolving security threats and organizational changes.
By following these best practices, you can maintain a robust and up-to-date CA policy framework that supports your organization’s security goals.
How I name my policies is a mixture of Microsoft recommendations and other blogs that I’ve used as a reference to think about how do I want to build my CA policies.
Naming convention
To further streamline your CA policies, consider the following naming convention structure:
- Prefix: Always start with “CA” followed by “G” for Grant or “B” for Block, and a rolling number.
- Example: CAG001: or CAB002:
- This approach is simple, effective, and easy to read on Entra sign-in logs or Sentinel.
- Cloud Resource: Specify “All” or a specific resource. If multiple resources are assigned, use “Selected”.
- Example: CAG001: All or CAB002: Selected
- Requirement: Clearly state the requirement, such as MFA, compliant device, location, or any other condition.
- Example: CAG001: All require MFA or CAB002: Selected exclude Trusted Location
- For Who: Indicate the target group, such as all users, selected users, externals, devices, guests, service accounts, or admins.
- Example: CAG001: All require MFA for All Users or CAB002: Selected exclude Trusted Location for Admins
- When Conditions: Specify the conditions, such as browser, client app, excluding something with filters, platforms, etc.
- Example: CAG001: All require MFA for All Users when Browser or CAB002: Selected exclude Trusted Location for Admins when Mobile Apps and desktop clients
- Version Number: Include a version number for documentation, development, or planning stages.
- Example: CAG001: All require MFA for All Users when Browser v1.0 or CAB002: Selected exclude Trusted Location for Admins when Mobile Apps and Desktop clients v1.0
Sample naming convention
Here are some examples to illustrate the naming convention:
- CAB001: All non-supported platforms v1.0
- CAB002: All for Break Glass Accounts when other than Trusted Locations v1.0
- CAG001: All require compliant device for All users when Browser v1.0
- CAG002: All require MFA for all users when browser on non-compliant devices v1.0
- CAG003: All require compliant device for All users when mobile apps and desktop clients on Windows v1.0
- CAG004: M365 and require MFA and App Protection Policy for all users when mobile apps and desktop clients on unmanaged Android and iOS v1.0
Categorizing and Reserving Rolling Numbers
To further enhance organization and management, you can categorize and reserve rolling numbers for different CA policies, some sample cases for reference:
- CAB001 to CAB010: Reserved for block policies
- CAG001 to CAG010: Reserved for browser access policies
- CAG011 to CAG020: Reserved for client app access policies
- CAG021 to CAG030: Reserved for platform access policies
How you categorize and reserve rolling numbers is entirely up to you. Both approaches – reserving and not reserving – can work, but in the long run, managing and documenting policies is simpler when you have reserved some space.
Now, I do know that there are lot of features on CA policies and some of those features are pretty hard to implement on naming convention. Hope you got some idea how to name your CA policies.
Entra ID security groups
Conditional access policies do require Entra ID security groups. I recommend to use prefix for all groups related to Conditional access for easier management. Common security groups are related to excluding users from policy or really specific policy for group of users.
Prefix: CA-
Sample group name with prefix:
- CA-CAG001-Excluded
- CA-Partner-accounts
- CA-Service-accounts
Next Up: Conditional Access Policies That Everyone Needs
Stay tuned for the next part of this series, where i’ll write about essential Conditional Access policies that every organization should implement.