One source of truth, two directories.

The first half of this lab pushes people from Okta into an app I wrote. This half points Okta at two directories whose shape I don't control — Microsoft Entra ID and Google Cloud Identity — and then checks, twice a day, that all three still agree.

Built and verified 09–12 Oct 2026 · Okta Integrator Free, Entra ID Free, Google Cloud Identity Free

Two arms, four mechanisms, one checker. Solid lines are provisioning and sign-in; dashed lines are the reconciler's read-only pass.

What it does

Okta owns the account lifecycle and every mapped attribute. Each directory gets two separate mechanisms: provisioning out of Okta over that vendor's API, and sign-in into the directory with Okta as the identity provider. They're configured separately and they fail separately — a working app tile tells you nothing about whether federation is on, which is the first thing I got wrong.

one join key: The same lowercase address in all three directories, set before anyone was assigned. No rewriting, which is what makes reconciliation an equality check rather than a matching algorithm.
assignment: Each app's sign-on policy denies everyone outside its group outright, so being assigned to the app is what grants access to the directory behind it. Both require a phishing-resistant second factor.
the OU tree: Google scopes the SSO profile and the post-SSO challenge by organizational unit, which makes the tree infrastructure rather than filing.
break-glass: One account per tenant, cloud-only, outside every federated path, on a different second factor from everything else. Tested before and after each federation change.
in Terraform: Policies and groups, in okta-as-code, with plan-on-PR and a daily drift job. The vendor connectors deliberately are not: they carry authenticated tokens and provisioning state no provider models.

Three findings worth the build

connector privilege

Both connectors can grant admin

RoleManagement.ReadWrite.Directory in Entra and admin.directory.rolemanagement in Google are the same privilege under two names, and both vendors ask for it in a four-click setup. A compromise of the IdP is a compromise of the directory behind it — on the documented path, not through a mistake.

opposite defaults

One re-challenges, one doesn't

Entra stops challenging a federated user once the domain is federated. Google keeps challenging unless an admin turns it off per OU — and since a provisioned user has no Google password, phone or 2-step, that challenge can't be satisfied. Same intent, and one of them is a lockout.

rollback

Removing SSO strands everyone

Accounts the IdP created carry a password it generated and disclosed to nobody. Remove the SSO assignment and those users can't authenticate at all. The real rollback is two steps, and the second is an admin password reset per user, distributed out of band.

Why there's a reconciler

Everything above is a point-in-time finding. I verified that deactivation propagated to both directories on one afternoon, with five users. That's a demo, not a system.

So the last piece reads all three directories on a schedule and checks every account. It knows the subtle cases: that some Okta statuses, like PASSWORD_EXPIRED, describe the password rather than whether someone can sign in, that an Entra account missing its anchor looks healthy and cannot be signed into, that break-glass accounts are meant to have no Okta identity. If any one of the three reads fails it publishes nothing at all, because a partial read would make every account look like it had vanished.

See the last reconciliation — read-only, people shown as pseudonyms.