Break-Glass Accounts Blocked After Conditional Access Enforcement
Fabrikam has 6,200 users in a single Microsoft Entra tenant, synchronized from on-premises AD with Entra Connect. Twelve standing Global Administrators use synchronized accounts. A consultant built three Conditional Access policies in report-only mode: block legacy authentication, require MFA for all users, and require a compliant or hybrid-joined device for Exchange Online and SharePoint Online. Two cloud-only break-glass accounts are members of a group named CA-BreakGlass, and that group is nested inside the group that each policy excludes. Last Tuesday all three policies were switched to On. Within an hour the break-glass accounts were blocked at sign-in, 60 field laptops that are Entra-registered but not Intune-enrolled lost mail, and the service desk queue passed 300 tickets.
1. Why were the break-glass accounts blocked even though they are excluded through a group, and what is the corrected configuration?
Read the worked answer
Cause: Conditional Access does not expand nested group membership. CA-BreakGlass is a member of the excluded group, but the two accounts are not direct members of the excluded group, so in the policy engine they are simply in scope for every control.
Corrected configuration:
- Add both break-glass accounts as direct members of the group that is assigned as an exclusion on each policy (or exclude the account objects directly).
- Do not rely on nested groups anywhere in an exclusion path - audit every policy for this pattern.
- Validate with What If for each account against each policy, then confirm against the Conditional Access tab of a real sign-in log entry.
- Keep the two accounts cloud-only, permanently assigned Global Administrator, excluded from every policy, credentials stored offline, and monitored by an alert on any sign-in.
Two additional controls:
- An analytics/monitoring rule that fires on any successful sign-in by either break-glass account - these accounts should be silent.
- A documented, tested recovery procedure with a scheduled quarterly sign-in test, so the exclusion path is proven rather than assumed.
2. The 60 field laptops are Entra-registered but not Intune-enrolled. What do you do in the first 24 hours, and what is the durable fix?
Read the worked answer
First 24 hours - scope the outage before you exclude anything:
- Break down the failing sign-ins by policy name in the sign-in log. Some of the 60 may be failing only the device requirement; some may be failing MFA or the legacy-auth block for unrelated reasons.
- Create a security group containing only the affected device objects/users, add it as an exclusion only on the device-requirement policy, leave the MFA and legacy-auth blocks intact, and record an expiry date plus an owner. Blanket-excluding a subsidiary or re-enabling report-only reverses the protection you just deployed.
- If the tenant is federated or hybrid-joined capable, a narrower alternative is to change that policy's grant control to Require hybrid Microsoft Entra joined device for the domain-joined population instead of excluding them.
Durable fix: enroll the devices in Intune and deploy a compliance policy (encryption, OS version, Defender antivirus), then remove the exclusion. Roll out in waves with the new policy in report-only first to quantify impact before enforcement.
3. Twelve standing Global Administrators all sign in with synchronized on-premises accounts. What risk does this create and how do you remediate it?
Read the worked answer
Risk: a synchronized Global Administrator is an on-premises identity first. Anyone who compromises the on-premises AD (Kerberoasting, DCSync, a compromised tier-0 server) gets an identity that already holds tenant-wide control, with no second barrier in the cloud. The Entra Connect server itself becomes a tier-0 asset.
Remediation:
- Move all administrative identities to cloud-only accounts; synchronized accounts keep user workloads only.
- Make administrative roles eligible through PIM rather than permanent, with approval, justification, MFA on activation, and a short maximum duration.
- Run access reviews on privileged role assignments on a recurring schedule and alert on out-of-band role assignments (Entra audit log, Sentinel/Defender XDR detection).
- Keep exactly two permanent cloud-only break-glass Global Administrators excluded from Conditional Access and from PIM.
- Treat the Entra Connect servers as tier 0: hardened, restricted admin, monitored.