Advanced Conditional Access Scenarios

In the early days of network security, we relied heavily on the "castle and moat" strategy. If you were inside the office and connected to the local network, you were trusted. If you were outside, you were untrusted. Today, that model is completely broken. With the rise of remote work, mobile devices, and cloud services, the traditional perimeter has vanished. In its place, identity has become the new primary security perimeter.

Conditional Access (CA) is the engine that powers this new perimeter. At its simplest level, it is an "if-then" statement: If a user wants to access a resource, then they must complete certain requirements. However, as organizations grow in complexity, simple "if-then" rules are no longer enough. Advanced Conditional Access scenarios require us to look at the full context of a sign-in attempt—including the user’s risk level, the health of their device, their physical location, and the sensitivity of the application they are trying to reach.

In this lesson, we will move beyond basic Multi-Factor Authentication (MFA) prompts. We will explore how to design sophisticated policies that balance high security with user productivity, ensuring that security controls are invisible when things are safe and restrictive when they are not.

The Core Philosophy: Signal, Decision, and Enforcement

Before diving into specific scenarios, we must understand how Conditional Access processes a request. Every time a user attempts to sign in, the CA engine aggregates "signals" from various sources.

1. Signals: These are the data points provided at the time of access. They include the user's identity, their group memberships, their IP address, the type of device they are using, the specific application they are requesting, and real-time risk intelligence from Microsoft’s threat signals.
2. Decision: The engine compares these signals against the policies you have created. It asks: "Does this request meet the criteria for Policy A? Policy B?"
3. Enforcement: Based on the policy match, the engine either allows access, blocks access, or requires a "grant control" such as MFA or a compliant device.

Understanding this flow is critical because advanced scenarios often involve "stacking" multiple policies. A single user might be subject to five different policies simultaneously, and the most restrictive combination of those policies will always win.

Scenario 1: Securing Privileged Administrative Access

Administrative accounts are the "keys to the kingdom." If a Global Administrator account is compromised, your entire digital estate is at risk. Standard MFA is a good start, but for high-privileged roles, we need to go further.

In an advanced setup, you should require that administrators only perform their duties from "Managed Workstations." This means that even if an attacker steals an admin's password and their MFA token (via a sophisticated phishing attack), they still cannot log in because they are not using a device that is joined to your organization's management system.

Implementation Logic

For this scenario, we create a policy that targets specific directory roles (Global Admin, Security Admin, etc.) rather than just users.

• Users: Select Directory Roles (choose high-impact roles).
• Target Resources: All Cloud Apps.
• Conditions: Any device platform.
• Grant Controls: Require Multi-Factor Authentication AND Require device to be marked as compliant.

Callout: The "AND" vs. "OR" Logic When configuring Grant Controls in Conditional Access, you can choose "Require all the selected controls" (AND) or "Require one of the selected controls" (OR). For standard users, an "OR" logic (MFA or Compliant Device) provides flexibility. For administrators, you should almost always use "AND" logic to ensure multiple layers of defense are active.

The "Break-Glass" Exception

A common pitfall in advanced CA is locking yourself out of the tenant. If your policy requires a compliant device and your device management system (like Intune) fails, no one can log in to fix it. Always exclude at least one "Break-Glass" or Emergency Access account from your policies. This account should have a long, complex password stored in a physical safe and should not be used for daily tasks.

Scenario 2: Risk-Based Access with Identity Protection

Not all sign-ins are equal. A sign-in from a known laptop in the user’s home city is low risk. A sign-in from a new device in a country the user has never visited is high risk. Advanced CA uses "User Risk" and "Sign-in Risk" to automate responses to these threats.

User Risk vs. Sign-in Risk

• Sign-in Risk: Represents the probability that a given authentication request isn't authorized by the identity owner. This looks at "anonymous IP addresses," "atypical travel," and "malware-linked IP addresses."
• User Risk: Represents the probability that a specific identity is compromised. This is a "long-term" risk score. For example, if a user's credentials are found on the dark web, their User Risk becomes "High."

Practical Example: The Self-Remediation Workflow

Instead of blocking a user when risk is detected, you can create a policy that forces a password change.

1. Condition: User Risk is "High."
2. Grant Control: Require Multi-Factor Authentication AND Require Password Change.

This allows the user to prove their identity via MFA and then immediately rotate their password, which automatically clears the "High Risk" flag without IT intervention.

Note: Risk-based policies require Azure AD Premium P2 (or Microsoft Entra ID P2) licenses. If you are on a P1 license, these specific "Risk" conditions will not be available in the policy builder.

Scenario 3: Geofencing and Impossible Travel

While "Location" is a signal, simply blocking countries is often too blunt an instrument. Advanced scenarios involve a combination of "Named Locations" and "Trusted IPs."

Defining Named Locations

You should define your corporate office ranges as "Trusted Locations." However, for remote workers, you might want to allow access only from specific countries where your company operates.

Step-by-Step: Creating a Geofence Policy

1. Navigate to Protection > Conditional Access > Named locations.
2. Create a "Countries location" and select the countries where you do not do business.
3. Create a new CA Policy.
4. Users: All Users (excluding your break-glass account).
5. Target Resources: All Cloud Apps.
6. Conditions > Locations: Include the "Blocked Countries" list you just created.
7. Access Controls: Block.

The Trap of the "Trusted IP"

Many admins check the box "Skip MFA for Trusted IPs." While this improves user experience, it is a significant security hole. If an attacker gains access to your physical office or a VPN, they can bypass MFA entirely. A better approach is to require MFA everywhere but allow a "Compliant Device" to satisfy the requirement when in a trusted location.

Scenario 4: Managed Devices and Compliance Integration

This is perhaps the most powerful advanced scenario. By integrating Conditional Access with Microsoft Intune, you can ensure that only healthy, updated, and encrypted devices can touch your data.

Comparison: Device States

The "Compliant Device" Requirement

A device is only "Compliant" if it meets the rules you set in Intune (e.g., BitLocker is on, Antivirus is active, OS version is up to date).

In an advanced scenario, you might allow users to check their email on any device (MFA required), but for sensitive applications like Finance or HR systems, you require a Compliant Device. This ensures that sensitive data never touches an unmanaged, potentially infected personal computer.

Scenario 5: Session Controls and Continuous Access Evaluation (CAE)

Standard CA policies are evaluated at the time of sign-in. But what happens if a user's account is disabled after they have already logged in? Normally, their session might last for hours or even days.

Continuous Access Evaluation (CAE)

CAE is a mechanism that allows Azure AD to revoke a session in near real-time if certain events occur, such as:

• User account is deleted or disabled.
• Password is changed or reset.
• MFA is enabled for the user.
• Admin explicitly revokes all sessions.

Session Controls: Sign-in Frequency

For highly sensitive environments, you may want to limit how long a session lasts. You can use Session Controls to force a user to re-authenticate every 4 hours when accessing a specific application, even if they are on a managed device.

Browser Session Persistence

You can also prevent users from staying logged in after they close their browser. This is particularly useful for shared workstations or kiosks. By setting "Persistent browser session" to "Never persistent," the session cookie is deleted when the browser window is closed.

Scenario 6: Securing External Identities (B2B)

When you invite guests (vendors, partners) into your tenant, they bring their own security posture—or lack thereof. Advanced CA allows you to enforce your security standards on their accounts.

Cross-Tenant Access Settings

You can now configure your tenant to "trust" MFA from the guest's home tenant. This prevents "MFA Fatigue" where a guest has to perform MFA for their own company and then a second MFA for yours.

However, you should still have a CA policy specifically for "Guest or external users."

• Target: All Guest and external users.
• Grant Control: Require Multi-Factor Authentication.
• Logic: If you trust their home MFA, they won't see a prompt. If their home tenant doesn't require MFA, your policy will force them to register for MFA in your tenant before they can see your data.

Automation: Managing Conditional Access as Code

In large organizations, managing dozens of policies through the GUI is error-prone. Advanced practitioners use the Microsoft Graph API to manage policies. This allows for version control (using Git) and consistent deployment across multiple tenants.

PowerShell Example: Creating a Policy

The following script uses the Microsoft Graph PowerShell module to create a policy that requires MFA for all users when accessing the Azure Management portal.

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess", "Application.Read.All"

# Define the Policy Parameters
$policy = @{
    DisplayName = "Require MFA for Azure Management"
    State = "enabled"
    Conditions = @{
        Users = @{
            IncludeUsers = @("All")
            ExcludeUsers = @("eb97e3a3-XXXX-XXXX-XXXX-XXXXXXXXXXXX") # Break-glass account ID
        }
        Applications = @{
            IncludeApplications = @("79701c1c-2247-4965-971e-97c0f97679a2") # Azure Management ID
        }
    }
    GrantControls = @{
        Operator = "OR"
        BuiltInControls = @("mfa")
    }
}

# Create the Policy
New-MgIdentityConditionalAccessPolicy -BodyParameter $policy

Explanation of the Script

1. Scopes: We request Policy.ReadWrite.ConditionalAccess to ensure we have the right to create policies.
2. State: We set this to enabled. In a real-world test, you might set this to enabledForReportingButNotEnforced (Report-only mode).
3. IncludeApplications: We use the specific App ID for the Azure Management portal. This targets the "Command Line" and "Portal" access to your infrastructure.
4. ExcludeUsers: We hardcode the Object ID of the emergency access account to prevent accidental lockout.

Best Practices and Industry Standards

To implement advanced Conditional Access successfully, follow these battle-tested principles:

1. Use a Clear Naming Convention

Policies are processed in an unordered list, but humans need order. Use a prefix system like:

• [CA001] Block - Legacy Auth
• [CA002] Admin - Require MFA & Compliant Device
• [CA003] User - Require MFA for All Apps
• [CA004] Risk - High Sign-in Risk Block

2. The "Report-Only" Phase

Never move a policy directly to "On." Microsoft provides a "Report-only" state. This logs what would have happened without actually blocking the user.

• Leave a policy in Report-only for at least 7 days.
• Review the Conditional Access Insights and Reporting dashboard to see how many users would have been blocked or prompted for MFA.
• Adjust the policy based on the data before enforcing it.

3. Block Legacy Authentication

Legacy protocols like POP3, IMAP, and SMTP do not support MFA. Attackers love these because they can bypass your MFA requirements entirely. Your very first CA policy should be a "Block Legacy Auth" policy for all users and all apps.

4. Minimize "All Apps" Policies

While it's tempting to create one giant policy for "All Apps," it can cause issues with background services and service accounts. It is often better to have a baseline policy for "All Apps" and then more specific, stricter policies for high-value targets like Salesforce, GitHub, or your HR portal.

Warning: The Service Account Conflict Automated service accounts (like those used for backup or synchronization) often cannot perform MFA. If you apply an "All Users / All Apps / Require MFA" policy, you will break these services. Always identify your service accounts and either exclude them (securing them with other methods like Managed Identities) or use specific policies for them.

Common Pitfalls and How to Avoid Them

The "MFA Fatigue" Attack

Attackers who have a user's password will spam the user's phone with MFA prompts until the user gets annoyed and hits "Approve."

• Solution: Use "Number Matching" in your MFA settings. This requires the user to type a number shown on the login screen into their Authenticator app, making accidental approval impossible.

Overlapping Policies

If Policy A says "Allow if MFA is done" and Policy B says "Block if device is not compliant," a user with a non-compliant device will be blocked, even if they do MFA.

• Solution: Use the "What If" tool in the Azure Portal. You can simulate a sign-in for any user, from any location, to see exactly which policies will apply and what the result will be.

Forgetting the "Device Platform"

If you create a policy that requires a "Compliant Device" but don't specify the platform, you might accidentally block platforms that can't be managed, like Linux or older versions of macOS.

• Solution: Specifically target Windows, iOS, and Android in your policy, or ensure you have a "catch-all" policy for "Other" platforms.

Quick Reference: Policy Design Patterns

Summary and Key Takeaways

Advanced Conditional Access is about moving from a binary "allow/deny" mindset to a nuanced, context-aware security posture. By leveraging signals like device health, location, and real-time risk, you can protect your organization's data without creating unnecessary friction for your users.

• Identity is the Perimeter: In a cloud-first world, your network doesn't matter as much as who is logging in and under what conditions.
• Risk-Based Intelligence: Use User and Sign-in risk to automate responses to compromised credentials.
• Device Compliance is Key: Integrating with Intune allows you to ensure that only "healthy" devices can access sensitive data.
• Never Block Yourself: Always maintain a "Break-Glass" account that is excluded from all CA policies to prevent total lockout.
• Test Before You Enforce: Use "Report-only" mode and the "What If" tool to understand the impact of your policies before they go live.
• Stacking Policies: Remember that CA policies are additive. The most restrictive combination of controls will be enforced.
• Continuous Evaluation: Security isn't just checked at the start of a session; with CAE, it's monitored throughout the entire duration of the user's access.

By mastering these advanced scenarios, you transition from a reactive security posture to a proactive, Zero Trust architecture that can adapt to the ever-changing threat landscape.