Bill Gernert
Security & Identity

Entra ID

The cloud side of hybrid identity, synced up from on-prem through 2 dedicated provision/deprovision scripts, then gated by Conditional Access - with one hard rule: never write a policy that can lock out the break-glass account.

What it is and whyHow I use it inArchitectureLessons learned and gotchasImpactFurther reading

What it is & why I use it

Entra ID is the cloud identity plane for AutomationLab. On-prem Active Directory is the source of authority; an identity-sync bridge projects those accounts into Entra so cloud services can authenticate against the same identities. On top of that, Conditional Access decides the terms under which access is actually granted, based on identity, request location, device posture, and authentication assurance.

I use it because modern access is not a binary "authenticated or not" - it is policy. Conditional Access is where "require a second factor," "only from a compliant device," and "block risky sign-ins" get expressed and enforced for cloud-facing identity.

How I use it in the lab

  • Synced from on-prem. Accounts originate in on-prem AD and flow up through the sync bridge, so the same identity works across both worlds and authority stays on one side.
  • Conditional Access as the gate. Policies express the conditions for access - factor requirements, device posture, blocking risky patterns - rather than trusting a password alone.
  • Layered with the other controls. Conditional Access sits alongside the second factor and the zero-trust edge, so cloud access requires identity and conditions and the factors below it.
  • A protected break-glass account. An emergency account is deliberately excluded from the policies that could lock everyone out, and is monitored precisely because it is exempt (see the gotcha).

Architecture

Entra ID architecture: Hybrid identity access path On-premises Active Directory synchronizes through the identity bridge to Entra ID, where Conditional Access evaluates the sign-in before the application receives it. ARCHITECTURE FLOW HYBRID IDENTITY ACCESS PATH Active Directory: Source identity on premises ACTIVE DIRECTORY Source identity on premises Sync bridge: Moves approved identity changes SYNC BRIDGE Moves approved identity changes Entra ID: Cloud identity and sign-in state ENTRA ID Cloud identity and sign-in state Conditional Access: Evaluate policy and exclusions CONDITIONAL ACCESS Evaluate policy and exclusions Application: Receives the allowed sign-in APPLICATION Receives the allowed sign-in Access record: Keep the evaluated result ACCESS RECORD Keep the evaluated result Cyan. Automated step or path. Amber. Operator or policy gate. Green. Recorded or healthy outcome. Dashed box. Stored state or record. Rounded box. Actor or process. Arrow. Direction of work or data.
The access path runs from on-premises Active Directory through synchronization and Entra ID to Conditional Access. Tenant, domain, and account details are omitted.

Lessons learned & gotchas

Gotcha - a Conditional Access policy can lock you out of your own tenant The self-inflicted outage that Conditional Access is famous for: you write a well-meaning "require compliant device" or "block legacy auth" policy scoped to all users, it applies to the administrators too - including you - and now no one can get in to fix it, because fixing it requires the access the policy just denied. The guard is a break-glass account excluded from the policy, created before you need it and tested, so there is always one identity that can reach the tenant when a policy goes wrong. And exclusions cut both ways: an exempt account is a standing hole, so it gets a long unique credential and its sign-ins are watched closely. Never roll out an all-users policy without first confirming the emergency door is carved out.
  • Test policies on a scoped group first. Rolling a new Conditional Access policy straight to all users is how tenant-wide lockouts happen. Pilot it on a small group, confirm the behaviour, then widen - the blast radius of an identity policy is everyone.
  • Treat exclusions as security exceptions. Every account excluded from a protective policy is an exception to your own rules - so exclusions are kept few, deliberate, and monitored, never quietly accumulated.
  • Authority on one side, enforcement on the other. Accounts are authoritative on-prem while access conditions are enforced in the cloud - keeping that split clear avoids "why did my change not take?" confusion about which system owns what.

Impact

Hybrid
identity, one authority
Policy
gated cloud access
1
break-glass, always excluded

Entra ID extends the lab's identity into the cloud and lets access be governed by conditions instead of a bare password. The lesson that outranks the rest is operational humility: the same policy that protects the tenant can lock you out of it, so you build the escape hatch first, test it, and only then turn the policy on for everyone.

Further reading

Conditional Access