Entra ID - Skills - Bill Gernert

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 - not just who you are, but from where, on what, and with what 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

Diagram coming On-prem AD -> sync bridge -> Entra ID -> Conditional Access gate on access, with the break-glass account excluded from lock-out-capable policies. Scrubbed of tenant, domain, and account detail.

In action

Screenshot coming A Conditional Access policy with its exclusions, and a sign-in being evaluated against it. Captured per the publishing checklist - tenant, domain, usernames, and addresses redacted.

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.
Exclusions are security-relevant, not just convenience. 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.

Code & further reading

Policy notes (link coming) Conditional Access

Any published policy notes are scrubbed of tenant, domain, usernames, and addresses before they go public.