Why Entra ID cannot serve an air-gapped network and what replaces it
Microsoft Entra ID is a cloud identity service, so on a network with no route to the internet it cannot issue tokens, evaluate sign-in policy or act as the directory for SSO, LDAP and Kerberos clients. The replacement is an identity stack the organization runs itself: Keycloak for web SSO and OpenID Connect or SAML 2.0 applications, with FreeIPA or Samba AD as the directory for LDAP, Kerberos and Linux or Windows hosts. Both the identity provider and the directory run on servers inside the isolated boundary, and no sign-in step depends on an external endpoint. The facts available for this page do not establish a fully offline mode for Entra ID, so confirm with Microsoft in writing whether any Entra ID component can operate without connectivity before you rule it in or out for a specific workload.
The split between web SSO and directory matters for the design. Keycloak can federate existing LDAP and Active Directory servers, and FreeIPA combines 389 Directory Server, MIT Kerberos, the Dogtag certificate authority and SSSD on clients. Kerberos-dependent services such as file shares and Linux login typically need the directory layer, not only a web broker. Check which of your applications speak LDAP bind, Kerberos, SAML or OIDC, because that inventory decides whether you need one directory or two. Plan for the offline lifecycle too: packages, Keycloak releases and FreeIPA security fixes such as those in 4.13.4 must be validated on a staging copy and carried across the boundary with hash verification, and the upgrade path for each component should be written down before go-live.
What an air-gapped identity requirement actually demands
An isolated network that still needs single sign-on, LDAP and Kerberos cannot send logins to a cloud identity service. The cards below set out the requirements that a self-run identity stack has to meet, and the checks to make before choosing components.
Identity services inside the boundary
Every sign-in path, including the login page, token endpoint and admin console, has to run on hosts inside the isolated network. Keycloak can serve OpenID Connect, OAuth 2.0 and SAML 2.0 from your own servers, so no authentication request leaves the boundary. Check that every application you need can reach the Keycloak endpoints without an outbound dependency, including email for recovery and any external certificate or metadata lookup.
Local directory and Kerberos service
Applications that expect LDAP binds or Kerberos tickets need a directory the isolated network controls. FreeIPA combines 389 Directory Server, an MIT Kerberos KDC and SSSD on clients, so users, groups and tickets are issued locally. Keycloak can federate an existing LDAP or Active Directory server, so you can keep the directory you already run and point Keycloak at it. Confirm which protocol each application uses before choosing the directory.
Controlled intermediate access
Interactive remote access into an isolated network is typically limited to a single intermediate system that enforces encryption and multi-factor authentication, and the operator must be able to detect and end active remote sessions. This is the theme of NERC CIP-005-7 for high and medium impact systems. Your identity design should decide which accounts can reach that gateway, where their second factor is verified, and how a session is terminated without waiting for a password change to take effect.
Verified import of software and patches
Identity components cannot be patched from the internet, so every package, container image and signature crosses the boundary on physical or controlled media. NERC CIP-013-2 addresses this in its supply chain theme: procurement should cover verifying the integrity and authenticity of vendor software and patches. Record the checksums and signatures of each Keycloak, FreeIPA and operating system update, and confirm that your staging host verifies them before they reach production identity servers.
Tested backup and restore
A self-run identity stack is only recoverable if you can restore it inside the boundary. FreeIPA provides ipa-backup and ipa-restore, and its documentation warns that restoring an outdated backup into an active replica topology can break replication. Keycloak realm export and import has documented limitations as a backup mechanism and requires all nodes to be stopped during the process. Plan a restore test that covers both the directory and the Keycloak database.
Auditable record of access
Auditors and operators need to see who signed in, from which system, and what was changed. Keycloak exposes metrics for observability, and FreeIPA records administrative changes in its directory. Decide where these logs are stored inside the boundary, how long they are kept, and who can read them, since a log store that depends on an external service will break the isolation the design depends on. Ask your assessor which events they expect to see before you set up logging.
Which open-source identity stacks fit an isolated network
This table compares Keycloak, FreeIPA, Samba AD, authentik and ZITADEL on offline operation, protocols, directory role, licensing and support. Read it by matching your required protocols and directory dependency first, then checking the licence and support model. The main takeaway is that web SSO and the Kerberos or LDAP directory usually need separate components, so most isolated networks will combine two stacks.
| Criterion | Keycloak | FreeIPA | Samba AD | authentik | ZITADEL |
|---|---|---|---|---|---|
| Primary role | Web SSO and identity broker | Directory with Kerberos, certificates and DNS | Active Directory compatible domain controller | Web SSO with LDAP and RADIUS outposts | Multi-tenant web and API identity |
| Protocols | OIDC, OAuth 2.0, SAML 2.0 | Kerberos, LDAP, certificates, OTP | Kerberos, LDAP, NTLM, AD services | OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos, proxy | OIDC, SAML 2.0, SCIM 2.0, LDAP |
| Directory relationship | Federates existing LDAP or AD servers | Is the directory (389 Directory Server) | Is the directory | Federates or serves LDAP | Federates, including Entra ID for sign-in |
| Offline operation | Self-hosted, runs without internet if images and packages are staged; confirm with your build process | Self-hosted on your servers; confirm package and repository mirroring | Self-hosted; confirm package mirroring with your distribution | Self-hosted; confirm offline image and dependency handling | Self-hosted with Docker Compose or Kubernetes on PostgreSQL 14 or later; confirm offline images |
| Licence | Apache 2.0 | GPL-3.0-or-later | Confirm with the Samba project before you deploy | MIT core; enterprise directory under authentik EE License | AGPL-3.0 with Apache 2.0 and MIT exceptions for some directories |
| Support model | Community, plus Red Hat build of Keycloak as a supported distribution | Community project, no paid edition of its own | Community, plus commercial support from third parties; confirm vendors | Community support in the free edition; ticket and SLA support in Enterprise tiers | Confirm the vendor support options for your edition |
| Paid edition for isolated use | Not required for the open-source server; confirm subscription needs with Red Hat if you want one | None; plan for in-house or partner support | Confirm with the vendor | Kerberos and LDAP are in the free edition, but support is community only | Confirm the commercial options with the vendor |
| Offline patching fit | Plan staged upgrades and check release notes before each minor update | Use internal package mirrors and review each security release | Plan staged patching and test replication | Test each release in a staging network first | Test each release in a staging network first |
How Keycloak brokers SSO over FreeIPA or Samba AD
The key design choice is to separate the directory from the sign-in front end. FreeIPA or Samba AD holds the users, groups, host records and Kerberos principals, while Keycloak federates to that directory over LDAP and presents OIDC or SAML to the applications. FreeIPA is the more complete choice for a Linux-only estate, since 389 Directory Server, MIT Kerberos and SSSD on clients come as one integrated package. Keycloak's user federation then reads accounts from the directory without copying passwords into a second store, so the identity source stays inside the enclave. Confirm during design which attributes Keycloak needs to read and which group memberships drive application roles, because those mappings are what applications will depend on.
Sites that keep Active Directory for Windows workloads can use FreeIPA's cross-forest trust instead of replacing AD. The trust is built through Samba components, and the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest. Plan the DNS namespace before installation, because renaming an IPA domain later is far harder than choosing a non-overlapping name at the start. Keycloak then sits in front of the trusted realm for browser and API sign-in, while Windows clients keep their existing Kerberos path. Confirm with the directory team which AD groups must map to IPA groups and how privileged accounts are handled across the trust.
For moving existing accounts, the FreeIPA migration tooling covers users and groups through the ipa migrate-ds command, which excludes Kerberos attributes that FreeIPA regenerates. Sudo and HBAC rules need a manual LDIF migration, so budget review time for them and test access on a non-production host before cutover. Passwords and Kerberos keys do not move as ordinary attributes, so plan a forced reset or a supervised transition for accounts that must keep signing in during the change.
How to deploy Keycloak and FreeIPA with no outbound internet access
This sequence builds an identity stack that runs entirely inside an isolated network, with a directory that holds users and Kerberos, a Keycloak front end for web SSO, and a patch routine that moves verified packages across the boundary by hand.
Inventory dependencies and the isolated boundary
The platform team lists every component the identity stack needs: Keycloak, FreeIPA packages, the operating system repositories, the container images, the database, the TLS certificates and the DNS and NTP sources. The security team records which applications will use SSO, LDAP or Kerberos and which need RADIUS or OTP. The output is a written bill of materials with a version and a checksum for each item, plus a list of the network paths that will stay closed. Ask any vendor you rely on which of these items it publishes as offline bundles, and confirm the licensing terms for redistribution inside your enclave before you copy anything across.
Build an internal mirror for images and packages
Staff on the connected side pull the operating system packages, the FreeIPA packages and the Keycloak container image, then verify their signatures and hashes before transfer through your approved media process. Inside the enclave, the team stands up a private registry and package repository that serve only the verified content. For Kubernetes hosts, the cluster can be built without internet access: run kubeadm config images list and kubeadm config images pull on the connected side, then point kubeadm init at the private registry with the --image-repository flag. The check is that a clean host installs every component with its outbound route blocked.
Deploy FreeIPA replicas on dedicated servers
The directory team installs FreeIPA on dedicated servers, with at least two to three replicas in each datacenter and no more than four replication agreements per replica, following the FreeIPA deployment recommendations. Place at least one replica per datacenter running PKI or DNS if you use those services, and configure at least two DNS servers in each client's resolv.conf. FreeIPA provides the 389 Directory Server, MIT Kerberos, Dogtag certificate authority and SSSD clients. The step is complete when each replica answers Kerberos and LDAP queries, replication reports no errors, and a test user can authenticate from a client machine.
Federate Keycloak to the directory
Deploy Keycloak with a supported production database. The documented options include PostgreSQL 14 to 18, so confirm which of those versions your database team supports and set the database as a synchronously replicated service, which Keycloak's high availability designs require. Configure a user federation provider that points at FreeIPA over LDAP, map the user attributes that applications need, and register the OIDC and SAML clients for each application. Keycloak's Operator, installed through Operator Lifecycle Manager, can manage realms and clients as custom resources. The check is a successful login from a test application using a directory account, with the group membership claims arriving as expected.
Set up backups and realm exports
Schedule ipa-backup on the FreeIPA servers and test that a full backup can be restored into a separate lab copy. The FreeIPA documentation warns that restoring an outdated backup into an active replica topology can break replication, so restores belong in a documented procedure that the team rehearses. For Keycloak, use the database backup as the primary recovery path. A realm export with kc.sh export is useful for configuration history, but the Keycloak documentation states its limitations as a backup and restore mechanism and requires all nodes to be stopped while the export runs. The check is a recorded restore test that rebuilds one realm and one FreeIPA user from the backups alone.
Control Keycloak updates with manual approval
Keycloak publishes minor releases several times a year and says breaking changes in a minor release are opt-in, but each upgrade still changes the running system. Set the Keycloak Operator's update approval to manual, as the Operator documentation strongly recommends, so that an operator update is never applied without review. Decide whether schema migration runs automatically at startup, which is the default, or whether the database team applies the SQL by hand, which the upgrading guide suggests for large deployments. The output is a written change record that names the target version, the reviewer and the rollback path.
Run the offline patch and verification routine
Every update follows the same cycle: the connected side collects the new packages, images and advisories for the versions in the bill of materials, checks their signatures and hashes, and records the results. Staff move the verified bundle across the boundary through your controlled media process, load it into the internal mirror, and apply it to a staging copy of FreeIPA and Keycloak. The team runs the login and replication tests from the first step against staging, then schedules production. Subscribe to the FreeIPA release notes and Keycloak release announcements so the team knows which fixes matter. The step closes when staging passes, the change record is signed off, and production returns the same test results.
Patching and updating without a live connection
An air-gapped identity stack is only as current as the packages, images and release bundles you carry across the boundary. The four decisions below connect the transfer process, the release staging path, the protection of the first FreeIPA server and the backup discipline that keeps a live replica topology intact.
Verify every item crossing the boundary
Every package, container image, Keycloak release archive and FreeIPA update moves through a transfer host that you control. Record a checksum and signature for each item at the source, verify them again inside the isolated network, and keep a log of who approved each transfer. NERC CIP-013-2 expects procurement processes to address verification of software integrity and authenticity for vendor software and patches, so ask your auditor which evidence they will accept. Confirm the signing keys each vendor publishes before you trust them.
Stage Keycloak minor releases first
Keycloak plans four minor releases a year, and since Keycloak 26.0 breaking changes in a minor release are opt-in. Mirror each new release into a non-production realm copy, run your OIDC and SAML client tests and your LDAP federation sync, then promote it. Keep the Keycloak Operator on manual approval so an update never starts without a review. Check the upgrading guide for the database migration mode you use before you schedule the change.
Stage FreeIPA point releases in a test replica
FreeIPA point releases such as 4.13.4, a stabilization release dated July 9, 2026, can fix security defects in the LDAP access control and authentication paths. Apply them to a test replica built from a recent backup, confirm replication agreements and Kerberos ticket issuance, then update the production replicas one at a time. Read the release notes for each version before you start, because a security fix can change client behavior.
Protect the first server's CA duties
By default the first FreeIPA server handles certificate renewal and CRL publication. If it is patched without a plan, certificates can expire or revocation data can go stale across the estate. Before maintenance, confirm which server holds the CA role, schedule its update in a window of its own, and check that CRL publication and certificate renewal resume on the other PKI-capable replica. Keep the replica that holds these duties in a documented runbook.
Avoid restoring outdated backups into live replicas
FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Use ipa-backup on a schedule and label each archive with its date and the server it came from. When you recover, rebuild from a backup that matches the current topology rather than bringing an old replica back into service. Test a restore in an isolated lab before you need one, and record how long it took.
Questions teams ask before moving SSO into an air-gapped network
Can Microsoft Entra ID run inside an air-gapped network?
Entra ID is a cloud service that Microsoft operates, so it cannot be installed on your own servers or run without internet access. Confirm this directly with Microsoft and your account team, including whether any sovereign or disconnected offering applies to your tenant and licensing. If the requirement is SSO, LDAP and Kerberos inside an isolated boundary, the practical question is which identity stack you can run yourself. Keycloak can handle web SSO through OpenID Connect and SAML 2.0, with FreeIPA or Samba AD as the directory for LDAP and Kerberos. Your architects should document which applications and devices depend on each protocol before choosing the design.
What does an air-gapped identity deployment cost, and what drives it?
Costs fall into four groups: software, infrastructure, implementation labor and ongoing operations. Keycloak and FreeIPA are open source and carry no license fee of their own, so spending goes to servers or virtual machines, a supported PostgreSQL or other production database, the people who build and run the platform, and any paid support you choose. Drivers include the number of applications to integrate, the number of directory users, high availability requirements, the number of sites, and how much custom work each application needs. Ask any provider for a quote that lists each component, the work hours by role, what is one-time and what recurs, and which items are excluded, such as offline patch media and staff training.
How long does an air-gapped SSO deployment take?
Duration depends on scope, so no single figure applies to every network. The main variables are how many applications need SAML or OIDC integration, whether FreeIPA or Samba AD must be built from scratch or populated from existing LDAP, how many replicas and sites are involved, and how quickly the isolated environment can receive approved installation media. Keycloak releases ship on a schedule of four minor releases a year, so plan for a version that stays inside your patching window. Agree a timeline in writing against a defined scope, and ask the provider which milestones depend on your own approvals or hardware.
What does our internal team need to provide?
Your team supplies the environment and the knowledge of your estate. Typical needs include virtual machines or hardware in the isolated network, DNS and time sources that the directory can use, a database platform, certificate authority decisions, and an approved process for moving software packages across the air gap. Your application owners must confirm claims, redirect URIs, and which users and groups each application needs. Named staff should own identity administration, approve changes and test sign-in before cutover. Confirm these responsibilities in the written scope so that gaps are visible before work starts.
Can we run an air-gapped identity platform without an implementation partner?
Yes, if your team has the skills and capacity to install, harden, back up and upgrade the platforms. Keycloak documents production configuration, high availability options and a Kubernetes operator, and FreeIPA publishes deployment recommendations and backup procedures. The harder parts are usually the offline supply chain, replication across sites and the migration of applications. A partner can plan, implement, document and support the work inside your infrastructure, and offers fixed-scope engagements or ongoing retainers. Whichever route you choose, make sure a trained person can restore the directory from backup, because FreeIPA warns that restoring an outdated backup into an active replica topology can break replication.
Should a site that only needs Active Directory use Keycloak plus FreeIPA?
Not necessarily. A site whose needs are limited to Windows domain services, Group Policy and Windows clients may be better served by keeping Active Directory and adding only what it lacks. Keycloak plus FreeIPA suits sites that need web SSO for many applications, Linux and UNIX hosts, Kerberos and certificate issuance under their own control. FreeIPA can form a cross-forest trust with Active Directory, provided the IPA domain uses a DNS name that does not overlap with any AD forest domain. Map each application and device to the protocol it needs first, then decide whether one directory, two directories, or a federated pair fits best.
Is air-gapped deployment a paid feature in other vendors' products?
Often, yes. Vendor pricing pages show that air-gapped deployment is frequently tied to higher editions. Mattermost lists air-gapped deployment in its Enterprise Advanced plan, Rocket.Chat excludes it from its free Starter plan, and Metabase offers it only on its Enterprise plan. Element offers a separate Sovereign edition for air-gapped deployments alongside its free AGPL Community edition. Plane distinguishes its Airgapped edition from its open-source Community edition, which is AGPL-3.0. Check each vendor's current pricing page and written terms, because edition names and entitlements change, and confirm what offline updates are included.
How do offline patches reach an isolated identity stack?
Patches reach an isolated network as verified media carried across the boundary, not through live updates. Your process should download packages on an connected staging system, verify their integrity and authenticity, record what was transferred, and apply them in a test environment before production. For Keycloak, plan for minor releases, read the upgrading guide, and consider manual schema migration for large deployments. For FreeIPA, the 4.13.4 release fixed two CVEs, including LDAP access control flaws, which shows why a predictable patch cycle matters. NERC CIP-013-2 is one example of a supply chain control that asks for software integrity verification, so document the steps for your auditors.
Evidence an assessor will ask for in an isolated environment
An assessor reviewing an isolated identity stack will want to see what sits inside the boundary, what was brought in, and whether the stack can be restored and administered without outside help. The cards below cover the records that answer those questions. DeployOpen prepares this evidence, but independent auditors issue any opinion on it.
Architecture and trust boundary diagram
Show every identity component inside the isolated network: Keycloak, the directory (FreeIPA or Samba AD), DNS, time sources and the admin workstations. Mark each path that crosses the boundary, including the transfer media used for updates. For CIP-005-7 style reviews, the diagram should also show where interactive remote access enters, which intermediate system handles it, and where multi-factor authentication is enforced. Confirm that the diagram matches the running configuration, not the design document.
Imported package and integrity records
Keep a manifest for every package, container image, realm file and offline vulnerability feed carried across the boundary. Each entry should record the source, the checksum or signature checked, who approved the import and the date it entered the enclave. This is the working record behind the supply chain control in CIP-013-2, which asks how vendor software and patches are verified for integrity and authenticity. Ask the vendor to confirm which signatures and checksums they publish for each artifact.
Patch and release records
Record which Keycloak, FreeIPA and operating system versions run in the enclave, when each was applied and what each release fixed. FreeIPA 4.13.4, dated July 9, 2026, fixed two CVEs, including LDAP access control flaws, so an assessor will expect to see when that release was evaluated and applied. Keycloak recommends manual approval for operator updates, so keep the approval record that shows a person reviewed each upgrade before it ran.
Backup and restore test results
A backup that has never been restored is not evidence. Run ipa-backup and ipa-restore into a test enclave, then record the restore time, the replication state afterward and which services came back. FreeIPA warns that restoring an outdated backup into an active replica topology can break replication, so document the restore order. Keycloak's realm export is limited as a backup method and needs all nodes stopped, so note how the database backup and restore were tested alongside it.
Administrator and directory change logs
Assessors will ask who changed a privileged group, reset a password, issued a certificate or altered an authentication flow, and when. Collect the Keycloak admin events, FreeIPA audit logs and directory change records, then forward them to a log store inside the enclave. Confirm retention periods with your own policy, since the supplied material does not set a default. Test one sample change end to end so the log entry, the actor and the approval can be traced.
Control mapping to CIP-005-7 and CIP-013-2
Build a table that maps each control theme to the artifact that proves it: the boundary diagram for electronic perimeter controls, the manifest for supply chain verification, and the MFA configuration for remote access. Mark gaps honestly, such as remote access detection that the identity stack does not provide on its own. Where your regulator uses a different framework, map to that framework's control IDs instead. Have the mapping reviewed by your compliance lead before the assessor receives it.
When Active Directory alone is enough and when Keycloak is needed
An air-gapped network needs Keycloak only if it has applications that speak OpenID Connect, OAuth 2.0 or SAML 2.0. If the site only signs in Windows workstations, file shares, printers and Linux hosts with Kerberos and LDAP, a Windows domain controller or a Samba AD or FreeIPA directory may cover everything. Start by inventorying the authentication methods each application uses. Many internal tools, monitoring consoles and vendor appliances still rely on LDAP bind or Kerberos integrated sign-in, and those can stay on the directory alone. The Microsoft Active Directory hub covers how to shrink or replace Domain Services, which is the right starting point when the only gap is domain sign-in.
Keycloak adds protocol coverage. It does not replace the directory. Keycloak provides single sign-on for modern web applications, identity brokering and an admin console, and it can federate existing LDAP and Active Directory servers as its user source. In practice, the directory keeps users, groups and passwords, Kerberos keeps issuing tickets for Windows and Linux clients, and Keycloak sits in front of web applications that need OIDC or SAML. Confirm in your own environment whether each target application can use LDAP federation, Kerberos or only a SAML or OIDC connection, because that answer decides whether Keycloak is needed at all.
Plan the decision as a checklist for the isolated network. Count the applications that need browser-based SSO, check whether they accept SAML or OIDC from a self-hosted provider, and confirm that the directory can serve their attributes and group memberships. If the answer is no for a material share of applications, you are running two identity services, and each one needs offline patching, backups and access reviews. Keycloak's own backup mechanism is limited, so plan separate backups for its database and realm configuration alongside the directory.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source identity platforms inside the client's own infrastructure, including air-gapped networks. For an isolated Entra ID replacement, that means a written scope covering Keycloak, the directory behind it, and the offline process for updating both.
How we scope
- Inventory every application, LDAP, Kerberos and RADIUS consumer that currently depends on Entra ID or Active Directory.
- Agree in writing which protocols, user sources and MFA methods the isolated network must support.
- Confirm the offline update path, package verification and backup targets before any build work starts.
How we build
- Deploy Keycloak with a supported production database and federate it to the chosen directory, such as FreeIPA or Samba AD.
- Build the offline patch bundles and verify package integrity before they cross the isolated boundary.
- Test SSO, federation and MFA flows against each application in scope, and document the results.
How we hand over
- Deliver runbooks for realm export, directory backup and restore, and the Keycloak upgrade procedure.
- Document controls and evidence for your compliance assessor, without issuing any audit report or certification.
- Walk your operations team through daily administration, offline updates and incident steps before handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Review new Keycloak and directory releases and prepare offline update bundles on your schedule.
- Re-run application and access tests after significant changes to the identity stack or its network paths.
