Exclude Breakglass Accounts from Conditional Access Policies with PowerShell

Check Conditional Access Policies and Add Breakglass Accounts if Necessary

Breakglass accounts (or as Microsoft calls them, “emergency access accounts”) are intended for emergency use, such as when other administrative accounts are compromised or are locked out. Conditional access policies control inbound connection attempts and can lock everyone out if misconfigured. That’s why most experienced administrators make sure to exclude breakglass accounts from conditional access processing. Excluding the breakglass accounts means that Entra ID never imposes conditional access control on their connections. In effect, it guarantees access through breakglass accounts when all others fail. Well, if you remember the password for the breakglass accounts…

Best Laid Plans and Conditional Access Policy Exclusions

The best laid plans of mice and men often come undone and someone fails to insert the necessary exclusions into a conditional access policy. Given Microsoft’s ongoing focus on moving tenants to conditional access to enforce multi-factor authentication, the risk of being locked out due to a bad policy setting is obvious.

Automation through PowerShell offers a solution. The processing is simple:

• Find all conditional access policies in the tenant.
• Check if the necessary exclusions exist.
• If not, and the policy is active, add the exclusions and update the policy.

Alternatively, you could update all policies with a missing exclusion even if they are disabled or in report only mode.

Exclusions can be declared as individual user accounts or groups. In this scenario, something like a security group is overkill. The set of breakglass accounts should be limited to as few as possible and they don’t change over time unless necessary following the use of an account for emergency access to a tenant. In other circumstances, a group is a good way to exclude a set of user accounts from a conditional access policy.

Using the Microsoft Graph PowerShell SDK to Work with Conditional Access Policies

A script to check and update conditional access policies can use Graph API requests or cmdlets from the Microsoft Graph PowerShell SDK. This example uses the SDK. First, connect to the Graph endpoint with the necessary permissions:

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

The next step is to declare the breakglass accounts. I do this by including the object identifiers for the accounts in a simple array. I also declare the same values in a structure to pass to the Update-MgIdentityConditionalAccessPolicy cmdlet to update user account exclusions in a conditional access policy. The structure is a PowerShell representation of the body posted to the underlying Graph API request. If you want to use a group, the parameters will include the object identifier of the group in the excludeGroups section of the structure.

[array]$BreakGlassUsers = "91813a30-f048-48f1-a0f2-fd7c72020515", "b7289bc7-7e4e-44e2-ae1b-7e13e94e3749"
$Parameters = @{
    Conditions = @{
        users = @{  
            excludeUsers = @(
                "91813a30-f048-48f1-a0f2-fd7c72020515"
                "b7289bc7-7e4e-44e2-ae1b-7e13e94e3749"
            )
        }
    }
}

With everything prepared, the script runs the Get-MgIdentityConditionalAccessPolicy cmdlet to find the set of conditional access policies before looping through each policy to check the exclusions. If the breakglass accounts are not present and the policy is active, the script runs the Update-MgIdentityConditionalAccessPolicy cmdlet to add the exclusions.

[array]$Policies = Get-MgIdentityConditionalAccessPolicy | Sort-Object DisplayName
ForEach ($Policy in $Policies) {
    Write-Host ("Checking conditional access policy {0}" -f $Policy.displayName)
    [array]$ExcludedUsers = $Policy.conditions.users.excludeUsers
    ForEach ($User in $BreakGlassUsers) {
        If ($User -notin $ExcludedUsers) {
           Write-Host ("Can't find user {0} in CA policy {1}" -f (Get-MgUser -UserId $User).DisplayName, $Policy.DisplayName)
           If ($Policy.State -eq 'enabled') {
              Write-Host "Policy is enabled so updating it with break glass accounts" -ForegroundColor Red
              Update-MgIdentityConditionalAccessPolicy -BodyParameter $Parameters -ConditionalAccessPolicyId $Policy.Id
           }
        }
    }
}

If you use a group instead of user accounts, the check should be against $Policy.conditions.users.excludeGroups. Figure 1 shows the script in action. This kind of check to make sure that everything’s OK is a classic example of something that should run on a scheduled basis, preferably using Azure Automation rather than Windows Scheduler.

You can download the script from GitHub.

No Excuse for Running into Conditional Access Problems

With so much experience about configuring and using conditional access policies in production plus tools like ID PowerToys to document policy settings, lack of knowledge is no excuse for misconfiguring policies. But life is hard sometimes and we all make mistakes, and that’s why it’s good to automate checks to make sure that anticipated backstops work when needed.

---

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.