Implementing Conditional Access Policies

Implementing Conditional Access Policies

In the early days of corporate networking, security was often compared to a castle with a moat. If you were inside the castle walls (the corporate network), you were trusted. If you were outside, you were not. This model worked well when everyone worked from a physical office and used company-owned desktop computers. However, the modern workspace has moved far beyond the castle walls. Today, employees work from home, coffee shops, and airports, using a mix of corporate laptops, personal tablets, and smartphones to access cloud-based applications.

This shift necessitates a new approach to security: Zero Trust. At the heart of the Zero Trust model in the Microsoft ecosystem is Conditional Access. Conditional Access is the "if-then" engine of identity security. It allows you to create specific rules that govern how users access resources based on the context of their login attempt. For example, "If a user is logging in from an unknown country, then require Multi-Factor Authentication (MFA)." Or, "If a user is accessing sensitive financial data from an unmanaged device, then block access entirely."

In this lesson, we will explore the architecture of Conditional Access, walk through the implementation of various policy types, and discuss the best practices that keep organizations secure without frustrating their users.

The Core Architecture: Signals, Decisions, and Enforcement

To understand Conditional Access, you must understand the three-step process it follows every time a user attempts to sign in. Every access request is evaluated in real-time against the policies you have defined.

1. Signals (The Context)

Signals are the data points the system gathers about the login attempt. Think of these as the "If" part of your policy. Common signals include:

• User or Group Membership: Who is trying to log in? Is it a regular employee, a guest user, or an administrator with high-level permissions?
• IP Location Information: Where is the request coming from? Is it a trusted corporate branch office or a public IP in a country where your business doesn't operate?
• Device State: Is the user on a device that is managed by the organization? Is the device compliant with security policies (e.g., disk encryption enabled, antivirus running)?
• Application: Which app is the user trying to reach? Accessing a public menu in SharePoint requires less scrutiny than accessing the HR payroll system.
• Real-time Risk: Using machine learning, the system can identify "risky" behavior, such as a login from an IP address associated with known botnets or a "leaked credential" alert.

2. Decisions (The Logic)

Once the signals are gathered, the engine compares them against your active policies to make a decision. There are three primary outcomes:

• Block Access: The most restrictive decision. The user is stopped immediately.
• Grant Access: The user is allowed in, but often with additional requirements (like MFA).
• Report-only: The policy is evaluated, and the result is logged, but no enforcement action is taken. This is critical for testing new rules.

3. Enforcement (The Action)

Enforcement is the "Then" part of the policy. If the decision is to grant access with requirements, the user might be prompted to:

• Perform Multi-Factor Authentication.
• Mark the device as compliant via Microsoft Intune.
• Change a password (if a high risk is detected).
• Accept a Terms of Use document.

Callout: Conditional Access vs. Security Defaults Many smaller organizations start with "Security Defaults," which provide a baseline level of protection (like requiring MFA for everyone). However, Security Defaults are an "all-or-nothing" setting. You cannot turn them off for specific users or customize the rules. Conditional Access is the professional-grade version of this, allowing for granular control, exclusions, and context-aware rules. If you enable Conditional Access, you must disable Security Defaults.

Designing Your First Policy

Before clicking buttons in the portal, you need a plan. A poorly designed policy can accidentally lock every administrator out of the tenant—a situation often referred to as "locking the keys inside the car."

Step 1: Define the Scope

Every policy needs to target a specific group. It is a best practice to never apply a policy to "All Users" without having an exclusion group in place. This exclusion group should contain your "Break-Glass" or emergency access accounts. These are accounts that are not used for daily work and have highly complex passwords stored in a physical safe.

Step 2: Choose the Target Resources

You can apply policies to all cloud apps, specific apps (like Teams or Exchange), or even "User Actions" like registering security information. Most organizations start by targeting "All Cloud Apps" to ensure no backdoors are left open.

Step 3: Configure Conditions

This is where you define the triggers. For a standard security policy, you might select "Any Location" but exclude "Trusted Locations" (your office IP ranges). This ensures that when people are at the office, they have a smoother experience, but when they are remote, they are challenged for extra verification.

Step 4: Select Grant Controls

For most policies, the goal is to "Grant Access" but "Require Multi-Factor Authentication." You can also require that the device be "Microsoft Entra hybrid joined" or marked as compliant.

Practical Example: Blocking Legacy Authentication

Legacy authentication refers to older protocols like POP, IMAP, and SMTP that do not support modern MFA prompts. These are the primary targets for credential stuffing attacks because they cannot challenge a hacker for a second factor.

Why this matters

Hackers love legacy protocols. If you have MFA enabled for your web-based email but leave IMAP open, a hacker can bypass your MFA entirely by using an old mail client or a script to guess passwords.

Implementation Steps

1. Navigate to the Microsoft Entra admin center.
2. Go to Protection > Conditional Access.
3. Select Create new policy.
4. Name: Global - Block Legacy Authentication.
5. Users: Include All users, Exclude Break-Glass Group.
6. Target resources: All cloud apps.
7. Conditions > Client apps:
   • Toggle "Configure" to Yes.
   • Uncheck "Browser" and "Mobile apps and desktop clients."
   • Check Exchange ActiveSync clients and Other clients (which includes POP, IMAP, etc.).
8. Grant: Select Block access.
9. Enable policy: Set to Report-only for at least 24 hours to see who is still using old protocols, then move to On.

Note: Before turning this policy to "On," check your sign-in logs. You might find that some old printers or scanners are using SMTP to send emails. You will need to upgrade those devices or create a specific exclusion (with other security controls) for their IP addresses.

Risk-Based Conditional Access

If you have Microsoft Entra ID P2 licenses, you can use "Identity Protection" signals. This is one of the most powerful features of the platform because it uses global intelligence to identify compromised accounts.

User Risk vs. Sign-in Risk

It is important to distinguish between these two types of risk:

• Sign-in Risk: This identifies the probability that a specific sign-in request is unauthorized. For example, if a user logs in from New York and then ten minutes later from London, the system flags this as "Impossible Travel."
• User Risk: This identifies the probability that the user's identity has been compromised. A common trigger for this is when Microsoft finds a user's username and password on a "leaked credentials" list on the dark web.

Example Policy: High Risk Password Change

You can create a policy that says: "If User Risk is High, then Grant Access but Require Password Change." This forces the user to prove their identity via MFA and then immediately rotate their password, effectively neutralizing the leaked credential.

Step-by-Step: Requiring Compliant Devices for Admins

Administrators have the "keys to the kingdom." It is not enough for an admin to just have a strong password and MFA; you should also ensure they are using a secure, company-managed device.

The Process

1. Requirement: Ensure your devices are enrolled in Microsoft Intune and meet your compliance baseline (e.g., BitLocker enabled, OS version up to date).
2. Create Policy: Name it Admin - Require Compliant Device.
3. Assignments: Target specific roles like Global Administrator, Security Administrator, and Exchange Administrator.
4. Target Resources: All cloud apps.
5. Conditions: Leave as default (applies to all locations/platforms).
6. Grant: Select Grant access and check Require device to be marked as compliant.
7. Session: (Optional) Set sign-in frequency to 4 hours for admins to ensure they re-verify frequently.

Warning: Never apply a "Require Compliant Device" policy to your only Global Admin account if that account is not currently on a compliant device. You will immediately lose access to your own tenant and will have to call Microsoft support to regain entry, which is a lengthy process.

Managing Policies with PowerShell and Microsoft Graph

For large environments, managing dozens of policies via the GUI is inefficient and prone to human error. Using the Microsoft Graph API allows you to treat your security policies as code.

Listing Policies via PowerShell

To see your current policies and their states, you can use the Microsoft Graph PowerShell SDK.

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Policy.Read.All"

# Get all Conditional Access Policies
$Policies = Get-MgConditionalAccessPolicy

# Display a clean list of names and their states
$Policies | Select-Object DisplayName, State, CreatedDateTime | Format-Table

Creating a Policy via Script

This is useful for ensuring consistent deployments across multiple customer tenants or testing environments.

# Define the policy parameters in a hash table
$policyParams = @{
    DisplayName = "Block Access Outside US"
    State = "enabled"
    Conditions = @{
        Applications = @{
            IncludeApplications = @('All')
        }
        Users = @{
            IncludeUsers = @('All')
            ExcludeUsers = @('admin-recovery@yourdomain.com')
        }
        Locations = @{
            IncludeLocations = @('All')
            ExcludeLocations = @('AllTrusted') # Assuming you have a 'Trusted' named location for the US
        }
    }
    GrantControls = @{
        Operator = "OR"
        BuiltInControls = @('block')
    }
}

# Create the policy
New-MgConditionalAccessPolicy -BodyParameter $policyParams

Explanation of the Code:

• Connect-MgGraph: This authenticates you to the Microsoft cloud. You need the Policy.ReadWrite.ConditionalAccess permission to create policies.
• $policyParams: We define the logic in a structured format. We include "All" users but exclude a specific recovery account.
• IncludeLocations = @('All') combined with ExcludeLocations = @('AllTrusted'): This logic effectively blocks everything except what you have defined as a trusted location.

Best Practices for a Secure Implementation

Implementing Conditional Access is an iterative process. You don't just "set it and forget it." Follow these industry standards to ensure a smooth rollout.

1. Use "Report-Only" Mode

This is the single most important rule. When you create a new policy, the "Report-only" toggle allows the policy to run in the background. You can then go to the Sign-in logs and see exactly what would have happened if the policy were active. This helps you identify users who might be blocked unexpectedly.

2. The "Break-Glass" Account

Always exclude at least one (ideally two) emergency access accounts from your policies. These accounts should:

• Not be assigned to a specific person.
• Have a very long, randomly generated password.
• Be excluded from all MFA and Conditional Access policies.
• Be monitored with an alert so that if anyone ever logs into them, the security team is notified immediately.

3. Naming Conventions

As your list of policies grows, it becomes difficult to manage. Use a clear prefixing system:

• [BLOCK]: Policies that outright deny access.
• [MFA]: Policies that require multi-factor authentication.
• [DEVICE]: Policies requiring compliant or joined devices.
• [GUEST]: Policies specifically for external users.

4. Location-Based Security

While "Trusted IPs" are useful, they shouldn't be your only line of defense. Modern attackers can easily use VPNs or compromised local machines to appear as if they are inside your network. Always combine location signals with device compliance or MFA.

5. Review "What If" Tool

The "What If" tool in the Entra portal is a simulator. You can input a user, an app, and an IP address, and the tool will tell you exactly which policies will apply and why. This is your best friend when troubleshooting why a user is being blocked.

Common Pitfalls and How to Avoid Them

Even experienced administrators make mistakes with Conditional Access. Here are the most common traps.

Overlapping Policies

If a user is targeted by two different policies, both must be satisfied. For example, if Policy A requires MFA and Policy B requires a Compliant Device, the user must provide both to get in. If the user is on a personal device that can't be made compliant, they will be blocked, even if they pass the MFA challenge.

• The Fix: Regularly review your policies for redundancy. Use the "What If" tool to see how multiple policies interact.

Misconfiguring Guest Access

Many organizations forget that "All Users" includes Guest users (B2B). If you require a "Compliant Device" for "All Users," your guests will be blocked because their devices are managed by their own organization, not yours.

• The Fix: When requiring device compliance, target "Internal Users" specifically, or ensure your cross-tenant access settings allow you to trust compliance claims from other organizations.

Blocking "All Apps" without excluding the Portal

If you create a "Block" policy for "All Cloud Apps" and don't exclude the Microsoft Entra ID management portal, you might block yourself from the very screen you need to fix the mistake.

• The Fix: Always ensure your admin account or a specific management workstation is excluded during the initial setup of a restrictive policy.

Forgetting the "Register Security Info" Action

If you require MFA for a user to log in, but they haven't set up MFA yet, they might get stuck in a loop.

• The Fix: Create a specific policy that allows users to register their MFA information from a "Trusted Location" (like the office) without needing MFA to get in the first place.

Comparison: Grant Controls vs. Session Controls

It is helpful to understand the difference between controlling how someone gets in (Grant) and what they can do while they are in (Session).

Callout: App Enforced Restrictions This is a powerful session control for SharePoint and Exchange. You can set a policy that says: "If a user is on an unmanaged device, let them view files in the browser, but block them from downloading, printing, or syncing." This protects your data while still allowing the employee to be productive on the go.

Troubleshooting with Sign-in Logs

When a user calls the helpdesk saying they are blocked, the Sign-in logs are your primary diagnostic tool.

1. Open the Sign-in logs in the Entra portal.
2. Find the specific failed login attempt.
3. Click on the Conditional Access tab in the log details.
4. This tab will show you a list of all policies that were evaluated.
5. Look for the status Failure or Not Applied.
6. Click on the "Result details" to see exactly which requirement the user failed to meet (e.g., "MFA required but not performed").

Conclusion and Key Takeaways

Implementing Conditional Access is one of the most effective steps you can take to secure your organization's identity infrastructure. It moves your security posture from a static, easily bypassed perimeter to a dynamic, intelligent system that evaluates risk in real-time. By focusing on signals like user location, device health, and sign-in risk, you can create a security environment that is invisible to legitimate users but an insurmountable wall for attackers.

Key Takeaways:

• Never Trust, Always Verify: Conditional Access is the engine that powers the Zero Trust model by checking every single login attempt against specific security criteria.
• Start with Report-Only: Always test your policies in Report-only mode to avoid accidental business disruption. Use the sign-in logs to verify the impact before going live.
• Protect the Admins First: High-privileged accounts should have the strictest policies, including mandatory MFA and the requirement for a compliant, managed device.
• Emergency Access is Mandatory: Always maintain "Break-Glass" accounts that are excluded from CA policies to ensure you never lock yourself out of your own tenant.
• Kill Legacy Auth: Blocking older protocols like POP and IMAP is one of the "quickest wins" in security, as it eliminates a massive percentage of automated credential attacks.
• Context is Everything: Use signals like "Sign-in Risk" (P2 feature) to automatically challenge users who are behaving suspiciously, such as logging in from an impossible location.
• Granularity over Generality: Instead of one giant policy for everyone, create specific policies for different roles (e.g., Finance, HR, IT) to ensure appropriate levels of access for the task at hand.