Conditional Access Policy Design

Conditional Access (CA) is the policy engine in Microsoft Entra ID that brings together signals from various sources to make access decisions. It is not an authentication mechanism itself; rather, it is a conditional gatekeeper that runs after primary authentication (user/password or other) but before access is granted to a resource. The purpose is to enforce granular, risk-based access controls that go beyond static rules like "require MFA for all users." CA enables organizations to protect resources based on conditions such as user identity, location, device state, application sensitivity, and real-time risk.

When a user attempts to access an application that is configured to use Azure AD for authentication, the following sequence occurs:

Key internal details: CA policies are stored in the Azure AD tenant as JSON objects. They are evaluated on every authentication request, including token refresh requests (if the session is within the token lifetime). The evaluation is performed by the Azure AD Security Token Service (STS).

A CA policy consists of:

#### Assignments in Detail

Users and groups: All users, specific users/groups, or exclude certain users (e.g., emergency break-glass accounts). Exclusions take precedence over inclusions.

Cloud apps or actions: All cloud apps, select apps, or user actions (like Register security info). Common exam trap: you cannot target on-premises apps directly unless they are published via Azure AD Application Proxy.

Conditions: - Sign-in risk: Low, Medium, High (requires Azure AD Premium P2). Risk is calculated by Azure AD Identity Protection. - Device platforms: Android, iOS, Windows, macOS, Linux (only for device-based conditions). - Locations: Named locations (IP ranges, countries) or trusted/untrusted locations. Trusted locations are typically corporate networks. - Client apps: Browser, Mobile apps and desktop clients, Exchange ActiveSync clients, Other clients. - Filter for devices: Use device attributes (e.g., device model, operating system version) with rules.

Access Controls

Grant: - Block access: Overrides all other controls. - Grant access: Requires one or more of: Require MFA, Require device to be marked as compliant, Require Hybrid Azure AD joined device, Require approved client app, Require app protection policy, Require password change. You can choose to require all selected controls (AND) or one of the selected controls (OR).

Session: - Use app enforced restrictions: For Exchange Online and SharePoint Online, this lets the app enforce its own restrictions (e.g., download limits). - Use Conditional Access App Control: Routes traffic through Microsoft Defender for Cloud Apps for session-level monitoring and control. - Sign-in frequency: Controls how often the user must re-authenticate. Values: every 1-14 days (for persistence) or every 1-24 hours (for session). Default for Azure AD is 90 days for refresh tokens. - Persistent browser session: Allows users to stay signed in even after closing the browser. Default is off for most tenants.

CA policies are configured in the Azure portal under Azure Active Directory > Security > Conditional Access. They can also be managed via Microsoft Graph API (beta endpoint).

Example PowerShell using Microsoft Graph:

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$params = @{
    displayName = "Require MFA for all users"
    state = "enabled"
    conditions = @{
        userRiskLevels = @()
        signInRiskLevels = @()
        clientAppTypes = @("all")
        platforms = @{
            includePlatforms = @("all")
            excludePlatforms = @()
        }
        locations = @{
            includeLocations = @("All")
            excludeLocations = @()
        }
        applications = @{
            includeApplications = @("All")
            excludeApplications = @()
        }
        users = @{
            includeUsers = @("All")
            excludeUsers = @()
        }
    }
    grantControls = @{
        operator = "OR"
        builtInControls = @("mfa")
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Verification: Use the What If tool in the CA portal to simulate access requests. Also, check Azure AD sign-in logs for policy evaluation details.

A multinational corporation wants to require MFA for all users accessing Office 365 from outside the corporate network. They create a CA policy targeting all users, all cloud apps, and exclude trusted locations (their on-premises IP ranges). The grant control is 'Require MFA'. In production, this works well but causes friction for users who frequently travel. They mitigate by using sign-in frequency of 7 days to reduce MFA prompts. A common misconfiguration is forgetting to exclude emergency access accounts, which can lock out admins. Performance is not an issue; MFA is handled by Azure AD, and policy evaluation is fast.

A healthcare organization must block legacy authentication protocols (POP, IMAP, SMTP) to prevent credential stuffing attacks. They create a CA policy targeting all users, all cloud apps, and under Conditions > Client apps, select 'Exchange ActiveSync clients' and 'Other clients'. Grant control is 'Block access'. This effectively blocks all non-modern auth. However, they must ensure that service accounts using legacy protocols are excluded or migrated. A common mistake is blocking 'Other clients' without realizing that some legitimate apps (like older Office versions) use modern auth but are categorized as 'Other clients'. They use report-only mode to identify affected users.

A financial services firm wants to ensure that only managed, compliant devices can access their internal CRM app. They create a CA policy targeting the CRM app, all users, and require device compliance. Devices must be enrolled in Intune and comply with policies (e.g., encryption, antivirus). In production, this requires that all users have Intune licenses and devices are enrolled. A common issue is that personal devices (BYOD) may not be enrolled, blocking access. They create a separate policy for BYOD that requires MFA and app protection policy instead. They also configure session controls to limit download of sensitive data. This scenario tests the candidate's understanding of device-based conditions and the interplay between Intune and CA.