Conditional Access Setup for Hybrid Environments

Plan Before You Build

Conditional Access policies evaluate in parallel — a user is blocked if any applicable policy blocks them. Design your policies as a complete set, not one at a time.

For a hybrid environment, the typical policy set is:

Require MFA for all users (with service account exclusions)
Require compliant or hybrid-joined device for M365 apps
Block legacy authentication — SMTP auth, IMAP, POP all bypass MFA
Admin accounts always require MFA — no network location exceptions

Build everything in report-only mode for at least one week before enabling. Never skip this step.

Emergency Access Account

Create this before doing anything else. This is the account you use if CA locks everyone out.

Create a cloud-only account (not synced from on-prem): emergency@corp.onmicrosoft.com
Assign Global Administrator role
Generate a 30+ character random password — store it in a physical safe
Exclude this account from ALL Conditional Access policies
Alert on any sign-in from this account — any use is an incident

Don't skip thisAdmins have locked themselves out of their tenant by enabling CA before creating an emergency access account. It happens constantly.

Enable Report-Only Mode First

In Azure AD: Security → Conditional Access → New Policy → at the bottom, set Enable policy to Report-only.

Review results in Azure AD Sign-in logs → Conditional Access tab. Look for any legitimate users who would be blocked. Fix the policy before enabling it for real.

MFA for All Users Policy

Your baseline policy. Everyone must complete MFA except your emergency account and verified service accounts.

# Policy settings:
# Users: All users
# Exclude: Emergency access account group, Service accounts group
# Cloud apps: All cloud apps
# Conditions: none
# Grant: Require multifactor authentication

Service accountsApps using username/password (scripted SMTP relay, legacy line-of-business apps) can't complete MFA. Identify these before enabling and migrate them to app registrations, or exclude via a named group. Never exclude broad groups like "IT Staff" — that's the group attackers target.

Compliant Device Policy

Requires users to be on a compliant Intune-managed device to access corporate apps.

# Policy settings:
# Users: All users (same emergency exclusion)
# Cloud apps: Office 365 (or specific apps)
# Grant: Require compliant device OR Require hybrid Azure AD joined device
# Use OR between conditions — allows either to satisfy the requirement

Hybrid noteFor on-prem domain-joined devices not enrolled in Intune, use "Require Hybrid Azure AD joined device" as one of the grant options. These devices get a claim token from on-prem AD via the Hybrid Azure AD Join process.

Verify Hybrid Join is Working

Hybrid-joined devices must successfully register with Azure AD to satisfy a CA compliant device policy. If this isn't working, users on domain machines will be blocked.

# On a domain-joined machine — check hybrid join status
dsregcmd /status | findstr /i "AzureAdJoined DomainJoined WorkplaceJoined"

# Expected for a properly hybrid-joined device:
# AzureAdJoined : YES
# DomainJoined  : YES

If AzureAdJoined: NO on a domain machine:

Verify AAD Connect has Hybrid Azure AD join configured: AAD Connect → Configure → Configure device options
Check the Service Connection Point (SCP) in AD: Get-ADObject -LdapFilter "(objectClass=serviceConnectionPoint)" -SearchBase "CN=Configuration,DC=corp,DC=local"
Run dsregcmd /debug on the device for detailed join failure reasons

Named Locations

Named locations let you create exceptions or rules based on IP ranges. In Azure AD: Security → Conditional Access → Named locations → New location → IP ranges.

Add your office public IP ranges and mark as trusted. Common uses:

Skip MFA when on a trusted office network (use with caution — a compromised device on your LAN bypasses MFA)
Block access from specific countries using country/region locations
Require MFA only when outside the office, not internally

Monitor and Tune

# Review CA policy results in sign-in logs
Get-MgAuditLogSignIn -Filter "conditionalAccessStatus eq 'failure'" -Top 50 |
  Select UserPrincipalName, AppDisplayName, ConditionalAccessStatus

Review weekly for the first month after enabling. Look for:

Legitimate users blocked unexpectedly — add to an exclusion group while you investigate
Service accounts failing — migrate to app registrations
Legacy auth still succeeding — add the legacy auth block policy

TipThe Azure AD Sign-in logs → Conditional Access column shows each policy that evaluated, its result, and why. This is the fastest way to debug a specific user being blocked unexpectedly.