Entra ID Conditional Access Lockout Playbook

By Grant Sullivan (Lead Writer) | Senior Systems Engineer: Duncan Stewart | Service Desk Director: Caleb Patterson

SYSADMIN RUNBOOK & TECHNICAL SPECS
– Technical Objective: Step-by-step engineering deployment or troubleshooting fix
– Estimated Execution Time: 20 to 45 minutes
– Prerequisites & Minimum Licensing: PowerShell 7.x, Microsoft.Graph SDK, Entra ID P1 / Business Premium
– Testing Protocol: Sandbox tenant validation before production deployment
– Rollback Safety: Explicit rollback commands provided in Section 5

The Challenge: Conditional Access Lockouts & Business Disruption

Conditional Access (CA) policies in Microsoft Entra ID (formerly Azure Active Directory) are powerful security controls. They enforce multi-factor authentication (MFA), restrict access from unmanaged devices, or block legacy authentication protocols. However, misconfigured CA policies are a leading cause of user lockouts, service desk escalations, and severe business disruption.

Organizations frequently encounter these issues:
* Accidental Administrative Lockouts: A new CA policy inadvertently blocks all administrators, including the implementer, from accessing the tenant.
* Third-Party Application Breakage: CA policies block critical line-of-business applications that rely on specific authentication flows or legacy protocols.
* Emergency Access Account Exclusion: “Break-glass” or emergency access accounts are not properly excluded, rendering them unusable during a widespread outage.
* Global Outages: A misconfigured policy can trigger a tenant-wide lockout, paralyzing operations and leading to significant downtime.

This playbook provides a structured approach to troubleshoot, prevent, and remediate Entra ID Conditional Access lockouts, ensuring your administrative accounts remain accessible and your security posture remains robust.

1. Prerequisites & Environment Checklist

Before making any changes to Conditional Access policies, ensure you meet the following requirements:

Licensing: Microsoft Entra ID P1 or P2, or Microsoft 365 Business Premium. Conditional Access is not available with basic Microsoft 365 Business Standard or Enterprise E3 licenses.
Administrative Roles:
- Conditional Access Administrator
- Security Administrator
- Global Administrator (for emergency break-glass account configuration)
PowerShell Modules:
- Microsoft.Graph.Identity.Governance
- Microsoft.Graph.Authentication
Emergency Access Accounts: At least two cloud-only Global Administrator accounts (not synchronized from on-premises AD) with MFA configured, excluded from all CA policies. These accounts should be stored securely and only used in emergencies.
Test Plan: A clear plan for testing any new or modified CA policies in a staging environment or with a small pilot group before broad deployment.

2. Implementing Safe Conditional Access Policies

The safest way to implement CA policies is to target them initially at a small group of users or exclude sensitive accounts.

2.1 Exclude Emergency Access Accounts

Always exclude your break-glass accounts from all Conditional Access policies. This is a critical first step.

GUI Method:

Navigate to Microsoft Entra admin center > Protection > Conditional Access.
Select an existing policy or create a new one.
Under Users or workload identities, select Exclude.
Choose Users and groups and add your designated break-glass accounts.
Repeat for all Conditional Access policies.

PowerShell Method:

First, identify the Object IDs of your break-glass accounts.

Connect-MgGraph -Scopes "User.Read.All"
Get-MgUser -Filter "UserPrincipalName eq 'breakglassadmin01@yourdomain.com' or UserPrincipalName eq 'breakglassadmin02@yourdomain.com'" | Select-Object DisplayName, Id

Next, add these Object IDs to the exclusion list of a specific Conditional Access policy. Replace [POLICY_ID] and [BREAK_GLASS_OBJECT_ID] with your actual values.

Connect-MgGraph -Scopes "Policy.Read.All", "Policy.ReadWrite.ConditionalAccess"

# Get the Conditional Access policy you want to modify
$policyId = "[POLICY_ID]" # e.g., 'b7c8e9d0-e1f2-g3h4-i5j6-k7l8m9n0o1p2'
$caPolicy = Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyId

# Add break-glass account to exclusions
$breakGlassObjectId = "[BREAK_GLASS_OBJECT_ID]" # e.g., 'a1b2c3d4-e5f6-g7h8-i9j0-k1l2m3n4o5p6'

if ($caPolicy.Conditions.Users.ExcludeUsers -notcontains $breakGlassObjectId) {
$caPolicy.Conditions.Users.ExcludeUsers += $breakGlassObjectId
}

# Update the policy
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyId -Conditions $caPolicy.Conditions
Write-Host "Policy '$($caPolicy.DisplayName)' updated to exclude break-glass account."

2.2 Implement in Report-only Mode

Before enforcing a new policy, always enable it in “Report-only” mode. This allows you to see the impact of the policy without actually enforcing it.

GUI Method:

When creating or editing a Conditional Access policy, set the Enable policy toggle to Report-only.
Monitor the Conditional Access insights and reporting workbook in the Entra admin center for several days to identify any unintended blocks.

PowerShell Method:

When creating a new policy, set the State to reportOnly.

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

$conditions = @{
users = @{
    includeUsers = @("All")
    excludeUsers = @($breakGlassObjectId) # Always exclude break-glass
}
applications = @{
    includeApplications = @("All")
}
clientAppTypes = @("all")
platforms = @{
    includePlatforms = @("all")
}
locations = @{
    includeLocations = @("All")
    excludeLocations = @("AllTrustedLocations") # Example: Exclude trusted locations
}
}

$grantControls = @{
operator = "OR"
builtInControls = @("mfa")
}

New-MgIdentityConditionalAccessPolicy -DisplayName "Require MFA for All Users (Report-only)" `
-Conditions $conditions `
-GrantControls $grantControls `
-State "reportOnly"

3. Resolving Active Conditional Access Lockouts

If an accidental lockout occurs, the primary goal is to regain administrative access as quickly as possible.

3.1 Using Emergency Access Accounts

Access the Entra admin center using one of your pre-configured emergency access accounts.
Navigate to Protection > Conditional Access.
Identify the policy causing the lockout. Look at recent sign-in logs for “Conditional Access failure” details.
Set the problematic policy’s Enable policy toggle to Off.
Test access with a regular administrator account.
Once access is restored, re-evaluate the policy in “Report-only” mode before re-enabling.

3.2 Targeted Policy Disablement with PowerShell

If you know the DisplayName or Id of the problematic policy, you can disable it directly using PowerShell.

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

# Option 1: Disable by Policy Display Name
$policyName = "Block Legacy Authentication"
$policy = Get-MgIdentityConditionalAccessPolicy | Where-Object {$_.DisplayName -eq $policyName}

if ($policy) {
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policy.Id -State "disabled"
Write-Host "Policy '$policyName' has been disabled."
} else {
Write-Host "Policy '$policyName' not found."
}

# Option 2: Disable by Policy ID (more precise)
# $policyId = "b7c8e9d0-e1f2-g3h4-i5j6-k7l8m9n0o1p2"
# Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyId -State "disabled"
# Write-Host "Policy with ID '$policyId' has been disabled."

4. Verification & Functional Testing

After making changes, verify that the policies are behaving as expected.

Sign-in Logs: In the Entra admin center, navigate to Identity > Monitoring & health > Sign-in logs. Filter by user, application, or Conditional Access status. Look for “Success” entries where the expected CA policy was applied.
Conditional Access What If Tool: Use the “What If” tool in the Conditional Access blade to simulate sign-ins for specific users from various locations and devices. This is invaluable for predicting policy outcomes.
Pilot Group Testing: Always roll out new or modified policies to a small group of test users before applying them broadly.

5. Common Troubleshooting Pitfalls & Rollback

5.1 Common Pitfalls

Forgetting Break-Glass Exclusions: The most common mistake. Always double-check that your emergency accounts are excluded.
Overlapping Policies: Multiple policies can apply to a single sign-in. Understand the “AND” logic (all grant controls must be satisfied) and “OR” logic (any session control can be satisfied).
Device State Ambiguity: Policies requiring “compliant” or “hybrid joined” devices can block users if device registration or compliance policies are not fully functional.
Location Misconfiguration: IP address ranges for trusted locations must be accurate. VPNs, proxies, and dynamic IPs can interfere.
Legacy Authentication: Policies blocking legacy authentication can break older clients or applications that haven’t been updated to modern authentication.

5.2 Rollback Procedures

If a policy causes unforeseen issues, the quickest rollback is to disable it.

GUI Rollback:

Navigate to Microsoft Entra admin center > Protection > Conditional Access.
Locate the problematic policy.
Set the Enable policy toggle to Off.

PowerShell Rollback (Disable Policy):

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"

# Replace with the ID of the policy you need to roll back
$policyToRollbackId = "b7c8e9d0-e1f2-g3h4-i5j6-k7l8m9n0o1p2" 
Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyToRollbackId -State "disabled"
Write-Host "Policy with ID '$policyToRollbackId' has been disabled as a rollback measure."

Sources & References

Microsoft Learn: What is Conditional Access?
Microsoft Learn: Manage emergency access accounts in Microsoft Entra ID
Microsoft Learn: Plan a Conditional Access deployment
PowerShell Gallery: Microsoft.Graph Module