1. Architecture & Core Concepts

  • The CA Engine: Conditional Access is the zero-trust policy engine of Entra ID. It evaluates Signals (Who, What, Where, Risk), makes a Decision (Block, Grant, Require MFA/Compliance), and applies Enforcement.
  • Evaluation Logic:
    • Policies are evaluated simultaneously, not hierarchically.
    • Block trumps all. If Policy A grants access and Policy B blocks access, the user is blocked.
  • Licensing: Requires Entra ID P1 (minimum) or P2 (for risk-based policies like Identity Protection).

2. Enterprise Baseline Policies (The “Must-Haves”)

  • Block Legacy Authentication: Blocks protocols that cannot prompt for MFA (e.g., POP, IMAP, older Office clients). This is the single most critical security policy.
  • Require MFA for All Users: Targets “All Users” and “All Cloud Apps.” (Always utilize exclusions for break-glass accounts).
  • Require MFA for Azure Management: Specifically targets the “Microsoft Azure Management” app to protect the Azure Portal and PowerShell interfaces.
  • Device Compliance / Hybrid Joined: For accessing sensitive apps (or all of M365), require the device to be marked as compliant in Intune OR be Hybrid Entra ID Joined.
  • Risk-Based Policies (If Entra ID P2 is active): Require MFA or password change when User Risk or Sign-in Risk is detected as Medium/High.

3. Governance, Exclusions & Safety Nets

  • Emergency Access (“Break-Glass”) Accounts:
    • Create at least two cloud-only, highly privileged accounts (e.g., bg-admin1@tenant.onmicrosoft.com).
    • Exclude these accounts from all Conditional Access policies to prevent tenant-wide lockouts if MFA or federation fails.
    • Monitor these accounts aggressively via Log Analytics / Sentinel alerts.
  • Service Accounts & Exclusions:
    • Never use “All Users” without a dedicated exclusion group (e.g., CA-Exclusions-MFA).
    • Service accounts that cannot perform MFA must be excluded but should be locked down via other signals (e.g., Named Locations / Trusted IPs).
  • Report-Only Mode:
    • Always deploy new CA policies in Report-Only mode first.
    • Let it run for 7-14 days to monitor the Sign-in logs and ensure it doesn’t break legitimate business processes before flipping to “On.”

4. Session Controls & Granular Security

  • Sign-in Frequency: Forces a user to re-authenticate after a specified period (e.g., 90 days for standard users, 1 hour for risky sign-ins or specific portal access).
  • Persistent Browser Session: Controls whether users can remain signed in after closing and reopening their browser. Often set to “Never persistent” for shared devices.
  • App Enforced Restrictions: Integrates with SharePoint Online and Exchange Online to provide limited, web-only access (blocking downloads) when users log in from unmanaged (BYOD) devices.

5. Troubleshooting & Diagnostics

  • The “What If” Tool: Your primary testing sandbox. Input a specific user, app, IP address, and device state to see exactly which policies would apply and why.
  • Entra ID Sign-in Logs:
    • Navigate to the specific failed sign-in event, click the Conditional Access tab.
    • Look for the policy marked Failure.
    • Drill down into the “Show Details” pane to see exactly which signal (e.g., missing MFA, non-compliant device, blocked location) triggered the failure.
  • Continuous Access Evaluation (CAE): Understand that CAE allows Entra ID to revoke access tokens in near real-time (e.g., within minutes of a password reset or location change) rather than waiting for the standard 1-hour token expiration.

6. Essential PowerShell Cmdlets (Microsoft Graph)

  • Connection: Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
  • Policy Management:
    • Get-MgIdentityConditionalAccessPolicy (Lists all CA policies and their states)
    • Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId <ObjectID> (View specific policy configurations, useful for backing up policy JSONs)