KubeQuest

Appearance

Lab 03: Conditional Access Policies ​

Time: 45 minutes
Difficulty: Advanced
License Required: Entra ID P1 or P2
Portal Location: Entra ID → Security → Conditional Access

Lab Overview ​

You are implementing Zero Trust security for Contoso Ltd. Management requires that access to company resources be controlled based on user identity, device state, location, and risk level. You must configure Conditional Access policies while ensuring you don't lock out administrators.

⚠️ CRITICAL WARNING ​

╔═══════════════════════════════════════════════════════════════════════╗
║  A BAD CONDITIONAL ACCESS POLICY CAN LOCK OUT YOUR ENTIRE TENANT!     ║
║                                                                       ║
║  ALWAYS:                                                              ║
║  1. Create exclusion group FIRST with break-glass accounts           ║
║  2. Test in Report-only mode before enabling                         ║
║  3. Verify sign-in logs show expected behavior                       ║
║  4. Never target "All users" + "All apps" + "Block" without exclude  ║
╚═══════════════════════════════════════════════════════════════════════╝

Pre-Lab Setup ​

Before creating any policies:

  1. Create Break-Glass Account:

    • Username: breakglass1@yourdomain.onmicrosoft.com
    • Role: Global Administrator
    • Password: Complex, 20+ characters, stored securely offline
    • NO MFA configured (or FIDO2 key stored in safe)

  2. Create Exclusion Group:

    • Name: CA-Exclude-BreakGlass
    • Type: Security, Assigned
    • Members: Add break-glass account(s)

  3. Create Pilot Group:

    • Name: CA-Pilot-Users
    • Type: Security, Assigned
    • Members: Add 2-3 test users (NOT your main admin)

  4. Enable P1 Trial (if needed):

    • Entra ID → Licenses → Try Premium features

Task 1: Explore Conditional Access Components ​

Objective ​

Understand the structure of Conditional Access before creating policies.

Requirements ​

Navigate through the Conditional Access blade and identify:

  1. Named Locations:

    • How many named locations exist?
    • What types can you create? (IP ranges, Countries)

  2. Authentication Strengths:

    • What built-in strengths exist?
    • What's the difference between MFA and Phishing-resistant MFA?

  3. Policy Templates:

    • Review Microsoft's recommended templates
    • Which templates would apply to your scenario?

Validation ​

  • [ ] You can access Conditional Access blade
  • [ ] You understand: Signals (IF) → Decisions (THEN)
  • [ ] You identified Named Locations, Auth Strengths, Templates sections

Task 2: Create Named Locations ​

Objective ​

Define trusted and blocked locations for use in policies.

Requirements ​

Create the following named locations:

Location 1: Corporate Network

  • Type: IP ranges
  • Name: Corporate-Office-IPs
  • Mark as trusted location: YES
  • IP ranges: Use your current public IP (find it at whatismyip.com)
    • Add as: YOUR.IP.ADDRESS.HERE/32

Location 2: Blocked Countries

  • Type: Countries/Regions
  • Name: Blocked-High-Risk-Countries
  • Select 3-5 countries your organization would never have legitimate access from
  • Include unknown countries/regions: YES

Validation ​

  • [ ] Corporate-Office-IPs appears as trusted location
  • [ ] Blocked-High-Risk-Countries shows selected countries
  • [ ] Both locations appear in dropdown when creating policies

Task 3: Create Policy - Block High-Risk Locations ​

Objective ​

Block sign-ins from countries where your organization has no business presence.

Requirements ​

Create a Conditional Access policy:

Basic Configuration:

  • Name: BLOCK - High Risk Countries
  • State: Report-only (initially)

Assignments:

  • Users: Include → All users
  • Users: Exclude → Select CA-Exclude-BreakGlass group

Target Resources:

  • Cloud apps: Include → All cloud apps

Conditions:

  • Locations: Configure → Yes
    • Include: Selected locations → Blocked-High-Risk-Countries

Access Controls:

  • Grant: Block access

Validation ​

  • [ ] Policy is in Report-only mode
  • [ ] Break-glass group is excluded
  • [ ] Only blocked countries are targeted (not all locations)
  • [ ] Sign-in logs show "Report-only: Not applied" or "Report-only: Success/Failure"

Task 4: Create Policy - Require MFA for All Users ​

Objective ​

Enforce MFA for all users accessing any cloud application.

Requirements ​

Create a Conditional Access policy:

Basic Configuration:

  • Name: GRANT - Require MFA for All Users
  • State: Report-only

Assignments:

  • Users: Include → All users
  • Users: Exclude → CA-Exclude-BreakGlass

Target Resources:

  • Cloud apps: Include → All cloud apps

Conditions:

  • Leave all conditions as "Not configured"

Access Controls:

  • Grant: Grant access
    • Require multifactor authentication: CHECKED

Validation ​

  • [ ] Policy is in Report-only mode
  • [ ] Break-glass excluded
  • [ ] Check sign-in logs to see who WOULD be affected
  • [ ] Estimate impact before enabling

Task 5: Create Policy - Require MFA from Untrusted Locations Only ​

Objective ​

Allow seamless access from corporate network, require MFA elsewhere.

Requirements ​

Modify your approach: Instead of MFA for everyone everywhere, only require MFA when NOT in the office.

Create a Conditional Access policy:

Basic Configuration:

  • Name: GRANT - MFA When Not in Office
  • State: Report-only

Assignments:

  • Users: Include → All users
  • Users: Exclude → CA-Exclude-BreakGlass

Target Resources:

  • Cloud apps: Include → All cloud apps

Conditions:

  • Locations: Configure → Yes
    • Include: Any location
    • Exclude: Selected locations → Corporate-Office-IPs

Access Controls:

  • Grant: Require multifactor authentication

Validation ​

  • [ ] Policy only applies when OUTSIDE corporate network
  • [ ] Users in office should NOT trigger MFA requirement
  • [ ] Test by checking sign-in logs for users at known IPs

Task 6: Create Policy - Protect Azure Management ​

Objective ​

Require strong authentication for accessing Azure portal and management tools.

Requirements ​

Create a Conditional Access policy:

Basic Configuration:

  • Name: GRANT - Strong Auth for Azure Management
  • State: Report-only

Assignments:

  • Users: Include → Directory roles
    • Select: Global Administrator, User Administrator, Application Administrator
    • (Add other admin roles as appropriate)
  • Users: Exclude → CA-Exclude-BreakGlass

Target Resources:

  • Cloud apps: Include → Select apps
    • Select: Microsoft Azure Management
    • (This covers Azure Portal, CLI, PowerShell, ARM)

Conditions:

  • None (applies everywhere)

Access Controls:

  • Grant: Require authentication strength
    • Select: Phishing-resistant MFA (or create custom if needed)

Validation ​

  • [ ] Policy targets admin roles only
  • [ ] Microsoft Azure Management app is selected
  • [ ] Requires strong authentication (not just regular MFA)

Task 7: Create Policy - Block Legacy Authentication ​

Objective ​

Prevent use of legacy authentication protocols that don't support MFA.

Requirements ​

Create a Conditional Access policy:

Basic Configuration:

  • Name: BLOCK - Legacy Authentication
  • State: Report-only

Assignments:

  • Users: Include → All users
  • Users: Exclude → CA-Exclude-BreakGlass

Target Resources:

  • Cloud apps: Include → All cloud apps

Conditions:

  • Client apps: Configure → Yes
    • Modern authentication clients: UNCHECKED
    • Exchange ActiveSync clients: CHECKED
    • Other clients: CHECKED

Access Controls:

  • Grant: Block access

Validation ​

  • [ ] Only legacy client apps are blocked
  • [ ] Modern authentication (browser, mobile apps) NOT affected
  • [ ] Check sign-in logs for any legacy auth attempts

Task 8: Test Policies in Report-Only Mode ​

Objective ​

Verify policy behavior before enforcement using sign-in logs.

Requirements ​

  1. Generate Test Sign-ins:

    • Sign in with a test user from the pilot group
    • Sign in from different locations if possible (VPN, mobile data)
    • Use different apps (Azure portal, Office.com)

  2. Analyze Sign-in Logs:

    • Navigate to Entra ID → Sign-in logs
    • Filter by user or time range
    • For each sign-in, check the Conditional Access tab

  3. Interpret Results:

    • Report-only: Not applied = Policy conditions not met
    • Report-only: Success = Would have been allowed
    • Report-only: Failure = Would have been blocked

  4. Document Findings:

    • Which policies would affect each sign-in?
    • Are there unexpected impacts?
    • Any false positives (legitimate access would be blocked)?

Validation ​

  • [ ] You can find and interpret sign-in logs
  • [ ] You understand the Conditional Access tab in sign-in details
  • [ ] No unexpected users would be blocked
  • [ ] Policies behave as designed

Task 9: Enable Policies Safely ​

Objective ​

Move policies from Report-only to On following a safe rollout.

Requirements ​

Sequence matters! Enable in this order:

  1. First: BLOCK - Legacy Authentication

    • Usually lowest impact
    • Modern apps unaffected

  2. Second: BLOCK - High Risk Countries

    • Legitimate users shouldn't be in those countries

  3. Third: GRANT - MFA When Not in Office

    • Users may need to register MFA first
    • Consider sending communication beforehand

  4. Last: GRANT - Strong Auth for Azure Management

    • Verify all admins have phishing-resistant methods registered

For each policy:

  • Change State from "Report-only" to "On"
  • Monitor sign-in logs for 24-48 hours
  • Have break-glass credentials ready
  • Be prepared to switch back to Report-only if issues

Validation ​

  • [ ] Policies are enabled in safe sequence
  • [ ] No users are unexpectedly locked out
  • [ ] Sign-in logs show policies applying correctly
  • [ ] Break-glass account can still sign in

Cleanup Instructions ​

If this is a test environment:

  1. Set all policies back to Report-only or Off
  2. Delete the policies
  3. Delete named locations
  4. Delete break-glass account and groups

If keeping for production:

  1. Review and adjust based on monitoring
  2. Document all policies
  3. Set up alerts for break-glass account usage
  4. Schedule quarterly policy reviews

Key Concepts Tested ​

  • Named Locations (IP-based and Country-based)
  • Policy structure: Assignments + Conditions + Controls
  • Report-only mode for safe testing
  • Sign-in logs for troubleshooting
  • Legacy authentication blocking
  • Authentication Strengths
  • Exclusion groups for emergency access
  • Policy evaluation order (all policies evaluated, most restrictive wins)

Released under the MIT License.

Copyright © 2026 OpsAlchemy