Conditional Access Policy Design

Introduction: What and Why

In today's dynamic threat landscape, traditional perimeter-based security is no longer sufficient. Users access resources from various devices, locations, and networks, making it critical to adapt security controls based on the context of each access attempt. This is where Conditional Access (CA) comes into play.

Conditional Access is a powerful policy engine within Microsoft Entra ID (formerly Azure Active Directory) that allows organizations to enforce security requirements based on specific conditions. It acts as an "if-then" statement: If a set of conditions is met (e.g., a user is an administrator, signing in from an untrusted location, or using a non-compliant device), then specific access controls are enforced (e.g., require multi-factor authentication, block access, or require a compliant device).

Why is Conditional Access Crucial?

1. Zero Trust Alignment: Conditional Access is a cornerstone of the Zero Trust security model, which dictates "never trust, always verify." Every access attempt is explicitly verified based on all available data points.
2. Adaptive Security: It allows you to move beyond static, binary access decisions to a more adaptive approach, dynamically adjusting security requirements based on real-time risk signals.
3. Granular Control: Instead of a "one size fits all" approach, CA enables highly granular control over who can access what, from where, and under what conditions.
4. Mitigate Risks: By integrating with Microsoft Entra ID Protection, CA can detect and respond to risky sign-ins and user behaviors, preventing potential breaches.
5. Enforce Compliance: It helps enforce organizational and regulatory compliance by ensuring users meet specific device or authentication requirements before accessing sensitive data.

Detailed Explanation with Practical Examples

A Conditional Access policy is built around assignments and access controls. Let's break down its components:

The "If" Part: Assignments and Conditions

This section defines when a policy applies.

1. Users or Workload Identities:

   • Include: Specify which users, groups, or directory roles (e.g., Global Administrator, Exchange Administrator) the policy applies to. You can also target "All users," "Guest or external users," or "Directory roles."
   • Exclude: Crucially, you can exclude specific users or groups from the policy. This is vital for emergency access accounts (break-glass accounts) to prevent accidental lockout.

2. Cloud apps or actions:

   • Include: Target specific cloud applications (e.g., SharePoint Online, Salesforce, a custom enterprise app), or "All cloud apps." You can also target user actions like "Register security information" (for MFA setup) or "Register or join devices."
   • Exclude: Exclude specific applications from the policy.

3. Conditions: These are additional "if" statements that provide context to the access attempt. All conditions within a policy must be met for the policy to apply (logical AND).

   • User risk: Integrates with Microsoft Entra ID Protection to detect the likelihood that a user account has been compromised.
   • Sign-in risk: Integrates with Microsoft Entra ID Protection to detect the probability that a given sign-in attempt is not performed by the legitimate owner of a user account.
   • Device platforms: Target specific operating systems (e.g., Android, iOS, Windows, macOS, Linux).
   • Locations: Define trusted IP ranges (named locations) and target or exclude them. You can include "Any location" and exclude "All trusted locations" to target untrusted access.
   • Client apps: Specify which client applications (e.g., browser, mobile apps and desktop clients, Exchange ActiveSync, other clients) the policy applies to.
   • Device state (Preview): Target devices that are "Hybrid Azure AD joined" or "Marked as compliant."

The "Then" Part: Access Controls

This section defines what happens when the policy applies.

1. Grant:

   • Block access: Deny the user access entirely.
   • Require multi-factor authentication: Enforce MFA.
   • Require device to be marked as compliant: Device must be compliant with Intune or a third-party MDM.
   • Require Hybrid Azure AD joined device: Device must be joined to on-premises AD and registered with Azure AD.
   • Require approved client app: Require use of specific Microsoft apps (e.g., Outlook Mobile, Teams).
   • Require app protection policy: Require an Intune app protection policy to be applied to the app.
   • For multiple grant controls: If you select more than one grant control, you can choose to require "All the selected controls" (logical AND) or "One of the selected controls" (logical OR).

2. Session:

   • Use app enforced restrictions: Works with supported cloud apps (e.g., Exchange Online, SharePoint Online) to restrict actions within the app.
   • Use Conditional Access App Control: Integrates with Microsoft Defender for Cloud Apps for real-time monitoring and control over sessions.
   • Sign-in frequency: Define how often users must reauthenticate.
   • Persistent browser session: Allow users to remain signed in after closing and reopening their browser.

---

Practical Examples

Let's explore some common Conditional Access scenarios:

Scenario 1: Enforce MFA for Administrators

This policy ensures that all users assigned to administrative roles must perform MFA when accessing any cloud application.

• Users or Workload Identities:
  • Include: "Directory roles" -> Select roles like "Global Administrator," "Exchange Administrator," "SharePoint Administrator," etc.
  • Exclude: Your emergency access accounts.
• Cloud apps or actions:
  • Include: "All cloud apps."
• Conditions: None (or you could add "Locations" to only require MFA when outside trusted networks).
• Grant: "Require multi-factor authentication."

Scenario 2: Block Access from Untrusted Geographies

This policy prevents users from accessing sensitive applications when they are outside approved geographic regions.

• Users or Workload Identities:
  • Include: "All users" (or specific groups if only certain users access the app).
  • Exclude: Your emergency access accounts.
• Cloud apps or actions:
  • Include: "SharePoint Online," "Microsoft Exchange Online," or other sensitive apps.
• Conditions:
  • Locations:
    • Include: "Any location."
    • Exclude: "All trusted locations" and specific named countries/regions that are approved.
• Grant: "Block access."

Scenario 3: Require Compliant Device for Salesforce Access

This policy ensures that users can only access Salesforce from devices that are managed and compliant with your organization's security policies (e.g., enrolled in Intune).

• Users or Workload Identities:
  • Include: "All users."
  • Exclude: Your emergency access accounts.
• Cloud apps or actions:
  • Include: "Salesforce" (or your specific custom application).
• Conditions:
  • Device platforms: "Any device."
• Grant: "Require device to be marked as compliant."

Scenario 4: Require MFA for High Sign-in Risk

Leveraging Microsoft Entra ID Protection, this policy automatically challenges users for MFA if their sign-in is deemed risky.

• Users or Workload Identities:
  • Include: "All users."
  • Exclude: Your emergency access accounts.
• Cloud apps or actions:
  • Include: "All cloud apps."
• Conditions:
  • Sign-in risk: "High."
• Grant: "Require multi-factor authentication."

---

Relevant Code Snippets: Managing Policies with Microsoft Graph API

While Conditional Access policies are primarily configured through the Azure portal GUI, you can manage, audit, and automate aspects of them using the Microsoft Graph API. This is particularly useful for large organizations, auditing, or disaster recovery.

Here's a PowerShell example to connect to Microsoft Graph and list your existing Conditional Access policies.

# Install the Microsoft Graph PowerShell SDK if you haven't already
# Install-Module Microsoft.Graph -Scope CurrentUser

# Connect to Microsoft Graph with the necessary permissions
# You'll need at least Policy.Read.All for reading policies
# For creating/updating, you'd need Policy.ReadWrite.ConditionalAccess
Connect-MgGraph -Scopes "Policy.Read.All", "Policy.ReadWrite.ConditionalAccess"

# Get all Conditional Access policies
$caPolicies = Get-MgIdentityConditionalAccessPolicy

Write-Host "--- Conditional Access Policies ---"
if ($caPolicies) {
    foreach ($policy in $caPolicies) {
        Write-Host "Name: $($policy.DisplayName)"
        Write-Host "State: $($policy.State)"
        Write-Host "ID: $($policy.Id)"
        Write-Host "----------------------------------"
    }
} else {
    Write-Host "No Conditional Access policies found."
}

# Example: Get a specific policy by its ID and