FreeIPA → Microsoft Entra ID + Intune

FreeIPA ↔ Entra + Intune: integration to migration path.

This is a deliberately partial migration. FreeIPA goes live alongside Entra to take over the Linux directory plane — Kerberos SSO, sudo, HBAC, and host certificates — while Entra and Intune keep owning users-of-record, Windows endpoints, M365 sign-on, Conditional Access, Identity Protection, PIM, and MDM. Linux host auth moves onto IPA in waves with rollback at every step.

We are honest up front: there is no realistic full replacement of Entra and Intune by FreeIPA. The SaaS-only planes stay, and we get that in writing before Phase 0 — because anything broader is a re-architecture, not a migration.

Map my migration with an engineer →

The idea

Own the Linux directory. Leave the SaaS plane on Entra.

The topology that makes this zero-outage is a bridged two-plane model: FreeIPA runs its own Kerberos realm for Linux, and the two identity planes share users through one of two bridges — a one-way Kerberos cross-realm trust to the on-prem AD that Entra Connect already syncs, or a Graph-driven provisioning automation where there is no AD. FreeIPA cannot trust Entra directly, so AD is the bridge when it exists. Linux auth never traverses Entra, and Entra issues to cloud apps exactly as before, so nothing about M365 sign-on, Conditional Access, or Intune changes. We enrol Linux hosts in waves, each independently, each reversible — and the planes stay distinct by design.

The phases

Seven steps. Each one reversible.

Baseline, inventory & break-glass

We inventory every Linux host by current directory, sudo source, SSH model, and host-cert source, cross-referenced against the AD groups granting Linux access. Two break-glass local accounts land on every host with a hardware-key credential held by on-call, stored in a vault outside the IPA realm being built. Read-only fact-gather.

Users see: No user impact.

Rollback: N/A

Stand up FreeIPA HA; no enrolments yet

The realm goes live on at least two replicas in separate availability zones — CA, KDC, DNS, and 389-DS — with encrypted backups to S3 and a drilled restore. The admin UI is reachable over the tailnet/VPN only. No Linux host trusts IPA yet.

Users see: None — no host trusts IPA.

Rollback: Tear down the replicas.

Bridge to the Entra-side identity plane

We choose one bridge. If an on-prem AD exists, a one-way Kerberos cross-realm trust is established to the AD forest that Entra Connect already syncs. If there is no AD, a scheduled job reads Microsoft Graph for the Linux-Eligible group and reconciles users into IPA on a sub-hour interval. Never both.

Users see: None — no host enrolled.

Rollback: Delete the trust, or disable the provisioning cron. Under 15 minutes.

Enrol canary Linux hosts

Three to five non-critical hosts are IPA-enrolled while still accepting their old AD or local auth in parallel for rollback. Canary engineers get Kerberos SSO across hosts (kinit once, then ssh -K), gated by HBAC and IPA-managed sudo rules.

Users see: Canary engineers see no change with old creds; Kerberos SSO is a new capability they gain.

Rollback: Uninstall the IPA client on the host. Under 15 minutes, scripted.

Wave Linux host enrolment

Hosts are enrolled in waves — dev, staging, prod-readonly, prod-write — via Ansible or Salt, never by hand. Each host keeps its AD/local fallback for a seven-day bake while we watch auth failures, HBAC denials, and sudo denials in the SIEM, then the fallback is removed.

Users see: One-time IPA password set (or hardware-token enrol) on first IPA login. Existing authorized_keys keep working; IPA-issued SSH certs are a separate project.

Rollback: During the bake, revert SSSD and uninstall — under 15 minutes. After the bake the fallback is gone, so rollback becomes a re-install.

Optional: cut IPA's dependency on AD

Only if the end-state is an IPA-only Linux plane: Linux service accounts move into IPA, AD-user HBAC rules are disabled, and the cross-realm trust can be deleted. This runs only when AD is to remain solely for Windows. AD-only users lose Linux access, so explicit comms and confirmed IPA enrolment come first.

Users see: None for engineers already authenticating as IPA users; AD-only users must be enrolled first.

Rollback: Re-add the trust. 15 to 30 minutes — honestly slower than the earlier phases, the first non-instant rollback gate.

Steady-state — Entra and Intune stay

Entra and Intune keep all non-Linux identity, MDM, Conditional Access, Identity Protection, PIM, and M365 sign-on. The two planes stay bridged by the Kerberos trust or the provisioning automation. Ongoing: monthly backup-restore drills, quarterly break-glass drills, semi-annual HBAC and sudo reviews.

Users see: None. Entra and Intune are verifiably untouched.

Rollback: N/A — this is the deliberate end-state, not a cutover.

Feature parity

What FreeIPA owns, and what stays on Entra.

Capability	FreeIPA	Entra ID + Intune	Parity
OIDC / SAML IdP for cloud apps	None — FreeIPA is not an OIDC / SAML IdP for SaaS	Entra OIDC / SAML IdP for M365 plus SaaS	SaaS only
Kerberos SSO between Linux hosts	First-class KDC (kinit then ssh -K)	No Kerberos-to-Linux story	OSS only
User directory	389-DS LDAP with native nested memberOf	Entra cloud directory (flat groups in tokens)	Partial
LDAP / AD integration	One-way Kerberos cross-realm trust to AD	Entra Connect sync from AD	Partial
RBAC / host access control	HBAC rules (user/group to host to service) plus sudo rules	Entra roles; no Linux-shaped host ACL	Partial
Host certificates	Dogtag CA plus certmonger auto-renewal	Intune SCEP / PKCS (Linux endpoint support partial)	Partial
Integrated DNS	BIND for the IPA zone, secure dynamic updates	Entra DNS = verified domains only, not a host zone	OSS only
MFA / passkeys	OTP / HOTP / TOTP / Yubikey OTP; WebAuthn version-dependent	Entra WebAuthn / Windows Hello / passkeys	Partial
Conditional access / policy engine	None (HBAC is not policy-composition)	Conditional Access (device plus risk plus location plus session)	SaaS only
Risk / identity protection	None	Entra Identity Protection (sign-in / user risk, leaked creds)	SaaS only
Privileged access	Static sudo / HBAC grants	Entra PIM (time-bound JIT, approval, MFA gate)	SaaS only
Device management (MDM / MAM)	None — FreeIPA does not manage devices	Intune MDM / MAM, compliance, wipe	SaaS only
SCIM provisioning	None (bespoke Graph to ipa user-add bridge)	Entra SCIM provisioning to SaaS	SaaS only
Cost (Linux-only user)	Compute on 2–3 small VMs	Entra P1 / P2 plus Intune per device	Partial
Compliance (SOC 2 / FedRAMP / ISO)	You operate and evidence the IPA boundary	Vendor-operated, vendor-attested boundary	SaaS only

What we're honest about

The caveats most vendors leave out.

This is a partial migration — Entra and Intune are not retired

FreeIPA replaces the Linux directory plane only: Kerberos SSO, sudo, HBAC, and host certs. Conditional Access, Identity Protection, PIM, and Intune MDM are SaaS-only and stay on Entra by design. We get written agreement up front that any future 'retire Entra' ambition is a separate engagement — reading 'migration' as 'Entra retirement' is the most expensive expectation mismatch in this pair.

There is no Conditional Access analog in FreeIPA

Conditional Access composes device-state, sign-in and user risk, location, app sensitivity, and session controls. The nearest IPA primitive is HBAC, which gates user/group to host to service — and nothing else. No device signals, no risk, no geolocation. If Conditional Access gates your access today, it stays on Entra; we do not weaken it to 'match' what IPA can do.

FreeIPA cannot trust Entra directly

The supported path is FreeIPA trusting your on-prem AD, which Entra Connect already syncs — AD is the bridge, not Entra. If there is no AD, engineers carry two account records (Entra for M365, IPA for Linux) reconciled by a provisioning bridge. That bridge's correctness is a Tier-1 control: a missed disable means an offboarded engineer keeps Linux access, so we run a monitored sub-hour disable SLA.

No SCIM, no PIM, no WebAuthn parity on Linux

FreeIPA has no SCIM server or client — downstream SaaS provisioning stays on Entra. It has no PIM-style time-bound JIT elevation; sudo and HBAC are static grants. And WebAuthn in the IPA core is version-dependent, so IPA principals typically get a hardware OTP token while passkeys keep working on Entra. We name each gap rather than imply parity.

The IPA master becomes a Tier-1 critical path

Once Linux auth runs through IPA, the master being down means no Linux logins fleet-wide — and there is no managed-service backstop. That is why we run it: at least two replicas in separate AZs, monitored certmonger renewal, drilled encrypted-backup restore, and break-glass accounts on every host. Managed, not just installed.

Why this beats a flag day

Reversible per wave, soaked before the fallback is cut.

Every host enrolment rolls back in under 15 minutes while the AD or local fallback is left in place, so a bad wave is a single SSSD revert, not a fleet-wide lockout. And we never cut a host's fallback on a hunch: each wave bakes at least 7 days at full host count with an auth-failure rate that meets or beats the pre-IPA baseline before the fallback is removed, and the optional AD-trust cut only runs after at least 30 consecutive days with zero AD-resolved Linux logins. The one honest exception is that the Phase 5 trust removal takes 15 to 30 minutes to reverse — slower than the earlier phases, and we say so.

See whether your Linux plane migrates cleanly.

A call with a senior identity engineer. We confirm whether you have an on-prem AD (which decides the bridge), inventory your hosts by directory and sudo source, and tell you honestly which Linux functions move to FreeIPA and which Entra and Intune capabilities stay SaaS — before you commit to anything.

Map my migration →