Open-source alternative to Okta Universal Directory

Open-source alternative to Okta Universal Directory: the short answer

If your Okta user store is under review because of a renewal, a data residency requirement or concern about lock-in, the short answer is that Keycloak's own user store is enough for small estates with few directory dependencies, while organizations that need a directory of record should put identities in an LDAP directory such as FreeIPA, OpenLDAP or LLDAP. Keycloak is licensed under the Apache License 2.0 and can federate existing LDAP and Active Directory servers, so it can hold users itself or read them from a directory you already run. FreeIPA is licensed under GPL-3.0-or-later and bundles 389 Directory Server with Kerberos and a certificate authority, and OpenLDAP is licensed under the OpenLDAP Public License. LLDAP is a lighter option, but you should confirm its license, maturity and feature set against your own needs before committing to it.

The deciding factor is which applications you run and what they expect. Apps that speak LDAP directly, systems that need Kerberos for Windows or Linux logon, and SAML services that expect a stable identity source all push you toward a directory of record that other systems can query. Okta's directory is tied to its suite: user profiles, groups and lifecycle rules live in Okta, and the Okta AD agent is the usual bridge to on-premises Active Directory. Before you choose, inventory every application that authenticates users and record whether it needs LDAP bind, Kerberos, SAML or OIDC. A short list of applications that only use SAML or OIDC usually points to Keycloak alone, while any LDAP or Kerberos dependency means you should plan a directory and decide whether Keycloak federates it or replaces it.

Which open-source directory covers which Okta Universal Directory capability

This table maps each Okta Universal Directory capability to Keycloak user federation, FreeIPA, OpenLDAP and LLDAP. Read a row to see which product covers the capability natively, which needs a companion component, and what to confirm in your own environment before you commit.

Okta capability	Keycloak (user storage and federation)	FreeIPA	OpenLDAP and LLDAP
User profiles and custom attributes	Built-in user store with custom attributes, plus LDAP or AD federation mappers for existing attributes	Native user, host and group objects in 389 Directory Server with extensible schema	OpenLDAP supports schema extensions; LLDAP offers a fixed attribute set with limited custom fields, so confirm your attributes
Groups and nested membership	Groups and sub-groups inside the realm, with mappers that pass group membership into tokens	Native groups, nested groups and user groups for access policies	OpenLDAP groups depend on schema choice (groupOfNames, posixGroup); LLDAP supports groups with simpler nesting, so test your model
LDAP interface for apps	Keycloak does not act as a general-purpose LDAP server; apps needing LDAP bind usually point at the directory behind it	Native LDAPv3 interface from 389 Directory Server	Native LDAPv3 interface in slapd; LLDAP provides a lightweight LDAP read interface, confirm which bind and search features your apps need
Active Directory agent sync	Replaced by LDAP or Active Directory user federation with scheduled sync, confirm the sync scope and password handling for your AD	Cross-forest trust with Active Directory through Samba components, with a non-overlapping DNS domain	No native AD sync; use directory sync tooling or an identity provider in front, and confirm the sync method
Kerberos or Windows logon	Not a Kerberos KDC for Windows domain logon; Kerberos needs a separate KDC or a federated design, confirm with your vendor	Native MIT Kerberos KDC for single sign-on on Linux and Windows-joined clients through trusts	OpenLDAP does not include a Kerberos KDC; pair it with MIT Kerberos or another KDC, and confirm the integration path
SCIM provisioning	SCIM support is available for provisioning into applications, confirm the supported resource types and direction for your version	Not a SCIM server; provisioning into apps typically runs through connectors or identity middleware	Not a SCIM server; LDAP sync or a provisioning tool sits between the directory and apps
Password policy	Realm password policies cover complexity, history and expiry for locally stored users	Native password policies per group with lockout and expiry settings	Password policy overlay and policy objects are available in OpenLDAP; LLDAP offers basic password rules, confirm against your standard
MFA enrollment	Built-in OTP and WebAuthn enrollment in the realm, with required actions for new users	HOTP and TOTP tokens, including hardware tokens such as YubiKeys, with RADIUS proxy for existing servers	No native MFA enrollment; use Keycloak or privacyIDEA in front of the directory and confirm the factor set

When Keycloak's user store is enough and when a directory should hold identities

If every application speaks OpenID Connect or SAML and no system needs to bind to a directory or obtain Kerberos tickets, Keycloak's built-in user store is usually enough. Users, groups, credentials and role assignments live in one realm, managed through the admin console. The trade-off is that Keycloak becomes the single place identities live, so its database and backup process carry the full weight of recovery.

Fit: Keycloak provides single sign-on, identity brokering and fine-grained authorization for web and API clients, which covers most cloud-first application estates.
Operating model: You run one database, such as PostgreSQL 14 to 18, and choose a high availability design that depends on a synchronously replicated database.
Backups: Realm export and import as JSON files has documented limitations as a backup method and requires all nodes to be stopped while it runs, so plan database-level backups as the primary recovery path.
Exit path: If you later leave Okta, confirm with Okta what password data can be exported, because user lists alone do not carry credentials.

Check whether any printer, VPN, Linux login or legacy app needs LDAP binds or Kerberos, because one such client changes the answer to the next tab.

A directory-of-record requirement means one system must be the authoritative source for identities, groups, hosts and certificates, usually because auditors, joiner and leaver processes or certificate issuance depend on it. FreeIPA is built for this role because it bundles the directory, Kerberos and a certificate authority under one management plane. The cost is that this system now carries every identity's recovery risk.

Authoritative store: FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory for users, groups, hosts and policies, so one platform owns the record.
Certificates: Its integrated Dogtag certificate authority issues certificates, and FreeIPA 4.13.0 made random certificate serial numbers the default.
Backups: ipa-backup supports full backups and online data-only backups. Test restores in an isolated copy of the topology before you rely on them.
Replication hazards: The first server handles certificate renewal and CRL publication by default, and restoring an outdated backup into an active replica topology can break replication, so document where those roles sit.
Security releases: FreeIPA 4.13.4 fixed two CVEs, including LDAP access control flaws, so assign someone to track releases and schedule patching.

Ask who owns the directory-of-record role in your governance model, and what recovery time and recovery point your audit commitments require.

How the Okta AD agent pattern maps to directory federation

The Okta AD agent reads Active Directory state into Okta and checks passwords against it. Self-hosted options cover the same job in different ways: Keycloak can federate an existing directory at login, FreeIPA can trust an AD forest, and some identities can live in a directory with no sync at all. The cards below cover what each option means for duplicates, attributes, password checks and ownership of the source of truth.

What the Okta AD agent does

The on-premises agent reads users and groups from Active Directory and pushes them into Okta's cloud directory, and it can validate passwords against AD during sign-in. Okta then becomes the place where applications see those users. Before moving, list every attribute Okta currently receives from AD, every group that drives app access, and every sign-in path that depends on the agent. That list defines the scope of the replacement.

Keycloak user federation with LDAP or AD

Keycloak's user federation can read users directly from an existing LDAP or Active Directory server and authenticate them there, so the directory stays the source of truth and Keycloak only holds the sessions and client configuration. Mapper settings decide which directory attributes become token claims. Confirm the bind account's permissions, the attribute mappers, and whether imported users are cached locally, since caching changes how quickly a disabled AD account stops working.

Duplicate accounts from parallel directories

The most common failure in a directory migration is the same person existing twice, once in AD and once in a new store, with different passwords and group memberships. Decide before cutover which system creates accounts and which one only reads them. Run a matching report on the usernames, email addresses and employee IDs that both sides hold, and resolve every mismatch before users sign in through the new path.

FreeIPA trusts with Active Directory

FreeIPA can establish a cross-forest trust with an Active Directory forest through Samba components, so AD users can reach Linux hosts and IPA-integrated services without copying their accounts. The IPA domain must use a DNS name that does not overlap with any AD domain. Plan the trust direction, the DNS zones, and which group mappings control access before enabling it, because a trust changes who can authenticate to IPA-hosted services.

Attribute mapping and claim contracts

Applications depend on specific attributes such as the login name, email, department and manager, and Okta often maps these under its own names. Each mapping must be rebuilt in the new identity provider and tested against every relying application. Keep a table that maps the source attribute, the target claim or LDAP attribute, and the application that reads it. Missing or renamed claims are a frequent cause of access failures after cutover.

Password validation and ownership

When the directory validates passwords, the identity provider does not store a copy, and password changes, lockouts and expiry stay with AD. When the new system stores passwords, users must re-enroll, and the migration needs a plan for hashes. Confirm whether the source directory exports password hashes at all, since many do not, and decide who owns the source of truth for each attribute: the directory, the identity provider or an HR system.

Running the new directory alongside the rest of the Okta suite

The first decision is which system owns the user record and which owns sign-in. You can move identities into Keycloak or an LDAP directory and let Okta keep serving its existing apps by pointing Okta at the new store, or you can keep Okta as the directory and move only the SSO role to Keycloak or authentik. Each choice changes where passwords are checked, where MFA is enforced and which system must be up for a user to log in. Confirm with Okta support whether your suite edition can use an external directory as a source of users in this way, because Okta's import and delegated authentication options differ by product and plan. Ask each application vendor whether its SAML or OIDC integration will accept tokens from a new issuer, since changing the issuer URL usually means re-registering the app and can change the claims and group names it receives.

Provisioning is where a split estate most often breaks. If Okta still provisions accounts into SaaS apps over SCIM, the new directory must be the authoritative source for the user attributes Okta reads, and group membership must be synchronized in one direction only. Two systems writing the same group will produce membership drift that is hard to trace. Keycloak's LDAP or Active Directory federation can import users and map group membership, and authentik can act as a SCIM source or client, but in each case confirm which attributes are writable from which side and how deprovisioning reaches downstream apps when a user is disabled in the directory. Check that the group identifiers used in app role mappings have not changed during the move.

Authentication location decides what happens during an outage. When Keycloak validates passwords against FreeIPA, OpenLDAP or Active Directory through federation, every login depends on that directory and on the network path to it, while Okta-hosted authentication does not depend on your internal LDAP server. Plan for the directory, the identity provider and the MFA service to fail independently, and test a sign-in with the directory unreachable. Confirm with each Okta-managed app whether it caches sessions or tokens, how long those tokens last, and whether a forced sign-out from one system reaches the other. Record these answers in a dependency map before any user is moved.

How users and groups move out of Okta Universal Directory

The sequence turns Okta's user store into a verified, tested identity set in the target directory, with known gaps in passwords and MFA documented before any application is switched over.

Inventory users, groups and attributes
Before exporting anything, the identity owner and the directory administrator list every user population, group that drives application access, and attribute that applications read, such as userPrincipalName-style login names, email, department and manager. Map each Okta attribute to a target attribute in FreeIPA, OpenLDAP or the Keycloak user model, and record which groups grant access to which applications. The step is done when this mapping is signed off and each attribute has an owner.
Export active users from Okta
The Okta administrator exports the active user list using one of the three documented routes: the Password Health report CSV in the Admin Console, the community Rockstar browser extension, or the List Users API with a filter. The API route is the most repeatable for a migration because the filter can be recorded and rerun for a final delta. Store the exports in a restricted location, since they contain personal data, and confirm the row count against the Okta Admin Console. The step is done when a complete export is checked against the count of active accounts.
Load identities into the target directory
For FreeIPA, the team migrates users and groups from an existing LDAP source with the ipa migrate-ds command, which excludes Kerberos attributes that FreeIPA regenerates. Sudo and HBAC rules need manual migration through LDIF. For OpenLDAP, the team writes LDIF files from the mapped attributes and loads them with the standard LDAP tools. Okta's export does not carry the directory structure, so the team builds the organizational units and group objects first and treats the import as a test load in a non-production replica. The step is done when a sample of imported accounts can authenticate through a test client.
Connect the target directory to Keycloak
If Keycloak sits in front of the directory, the team configures LDAP or Active Directory user federation in the realm and maps the imported groups to Keycloak roles. This replaces the Okta AD agent pattern, where Okta reads an on-premises directory through an agent. Where Keycloak's own user store is enough, the team imports users into the realm instead. The team confirms that group membership and attribute mappings produce the same claims that each application expects. The step is done when a test login returns the expected token claims for each application.
Re-link applications to the new identity source
Each application registered in Okta is re-created as a client in Keycloak or as a directory-backed login in its own configuration, using the redirect URIs, SAML entity IDs and scopes recorded in the inventory. The application owner tests sign-in, sign-out and role-based access in a staging environment before cutover. Applications that cannot change identity provider stay on Okta until a later stage, and the team records them as exceptions. The step is done when each application passes a sign-in test against the new source.
Plan password and MFA re-enrollment
Okta does not export password hashes in a form that can be loaded directly, so the team should confirm with Okta what password material, if any, can be moved and under which conditions. In most migrations, users set new passwords at first sign-in, and the team decides how identity is verified for that reset. MFA factors enrolled in Okta are not carried over, so each user re-enrolls in the target MFA, and the help desk process for lost devices is written before cutover. The step is done when the re-enrollment method and help desk procedure are approved by the security owner.
Back up and test the restore path
The team takes a backup of the target store before the cutover and tests a restore into an isolated environment. For Keycloak, realm export to JSON requires stopping all nodes while it runs and has limitations as a backup mechanism, so the team uses it alongside the database backup and confirms the restore procedure documented for that deployment. For FreeIPA, the team uses ipa-backup and confirms that restores are not made into an active replica topology with an outdated backup. The step is done when a restore has been completed and its result recorded.
Run a delta sync and cut over
Shortly before cutover, the team reruns the Okta export with the same filter to capture users created, changed or disabled since the first pass, and applies those changes to the target directory. Disabled Okta accounts are disabled in the target before access is switched. The team then moves production sign-in to the new source and keeps Okta available for rollback until the owners confirm sign-in is stable. The step is done when reconciliation shows matching counts of enabled accounts in both systems and each application has a confirmed owner.

What do buyers ask before replacing Okta Universal Directory?

How much does it cost to replace Okta Universal Directory with a self-hosted directory?

The software itself is free for Keycloak, FreeIPA and OpenLDAP, so the cost sits in infrastructure, people and support. Plan for servers or virtual machines for at least two directory replicas per site, a supported database for Keycloak, monitoring, backups, and the staff time to run and patch them. Okta's cost is per user and per suite, so compare your own user count and the suite you actually license against the component costs below. Ask any implementation partner for a quote built from a written scope that lists each component, the one-time migration work and the recurring operations. FreeIPA is a community project with no paid edition, while Keycloak has an optional commercial distribution from Red Hat, so confirm which support model you need before you price it.

How long does a directory migration off Okta take?

The duration depends on the number of users, the number of connected applications, how many groups and attributes you keep, and whether you use Keycloak's own user store or an LDAP directory. Exporting users is the quick step, since Okta documents a Password Health report CSV, the List Users API with a filter and a community browser extension. Reconnecting applications, rebuilding group mappings and testing each login flow usually take the most time. Ask for a timeline in the written scope, and ask which parts depend on your application owners, because their testing calendars often set the pace.

What does my team need to provide before the work starts?

You need named owners for identity, networking, the database, and each business application that signs in through Okta. Your team should supply an inventory of applications, their protocols (OIDC, SAML or LDAP), the attributes each one reads, and the groups that control access. You also need hosting that meets your data location rules, DNS names, TLS certificates and a change window. Confirm with your security team whether the directory will sit inside your existing authorization boundary, since that affects where logs and backups are stored.

Can our own IT team run the migration without an outside partner?

Yes, a capable internal team can run it, especially if it already operates Linux, DNS, Kerberos or LDAP. The hard parts are not the installation but the decisions and testing: deciding whether Keycloak's user store is enough or an LDAP directory should hold identities, mapping the Okta AD agent pattern to directory federation, and confirming every application still gets the claims it needs. Ask yourself whether anyone on the team has operated a replicated directory before, and whether there is time to practice a restore. If not, a fixed-scope engagement can cover the parts your team cannot staff in the window.

How do replication and backups change the operating load?

A replicated directory adds work that Okta currently absorbs. FreeIPA's deployment recommendations advise at least two to three replicas in each datacenter, no more than four replication agreements per replica, and dedicated servers without other applications. Its backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restores must be rehearsed and planned. Keycloak's export and import of realms has limits as a backup mechanism and requires all nodes to be stopped while it runs, so you need a database backup plan as well. OpenLDAP's slapd supports single-provider replication and multi-provider replication when a single point of failure is not acceptable. Ask any partner to show the backup, restore and failover runbooks as deliverables.

How are passwords and MFA handled when users move off Okta?

Okta does not give you a clean password export, so plan for re-enrollment rather than assuming credentials will carry over. The Password Health CSV and List Users API export user profiles, not usable password hashes, which means most users will set a new password through a controlled reset flow. For MFA, Okta factors do not transfer to a new provider, so each user re-enrolls TOTP or WebAuthn in Keycloak or another chosen factor. FreeIPA supports HOTP and TOTP tokens, including hardware tokens such as YubiKeys. Decide in advance how help desk will verify identity during the reset period, and confirm with your security team which factors meet your policy.

What does a fixed-scope DeployOpen engagement cover for this migration?

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. A fixed-scope engagement sets out the directory design, the chosen platform (Keycloak, FreeIPA or OpenLDAP), the application integrations, the replication and backup setup, the migration of users and groups, the re-enrollment plan and the handover documentation before work starts. Deliverables and timelines are agreed in writing, and a quote follows from that written scope. DeployOpen does not issue audit reports or certifications, so any compliance evidence it prepares is for your independent auditor to assess. Ongoing support, upgrades and testing are available as retainers.

Which directory platform should we pick if Keycloak's own user store is not enough?

Choose based on how many systems depend on LDAP or Kerberos and whether Linux clients need central identity. Keycloak's built-in user federation can connect to existing LDAP and Active Directory servers, so an existing directory can stay as the source of truth while Keycloak handles protocols. FreeIPA combines 389 Directory Server, MIT Kerberos, Dogtag and SSSD for Linux and can form a trust with Active Directory, but its IPA domain must not overlap with an AD forest domain. OpenLDAP is a standalone directory server with LDAPv3, SASL and TLS authentication, which suits teams that want a lean LDAP service and will build the surrounding tooling themselves. Ask which platform your applications already speak, and test one application against each candidate before you decide.

How DeployOpen scopes and delivers a directory replacement

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure, so a directory replacement is scoped against your user counts, sources and applications before any work starts. Most engagements are fixed-scope, with deliverables and timelines agreed in writing first.

How we scope

The written scope lists every identity source, from Okta users and groups to any Active Directory or LDAP trees that stay in place.
We confirm which applications authenticate through the directory and which need LDAP binds, Kerberos or SAML attributes.
The scope states whether Keycloak's own user store, FreeIPA, OpenLDAP or LLDAP will hold identities, with the reasons recorded.

How we build

We install the directory and identity server in your cloud accounts, data centers or air-gapped network, using your chosen database.
Federation, attribute mapping and group sync are configured and tested against a representative set of accounts before cutover.
We set up backup and restore procedures, then test a restore on a copy, since FreeIPA and Keycloak each carry specific backup cautions.

How we hand over

Deliverables include architecture notes, configuration records, runbooks for replication, backup and certificate tasks, and the migration log.
Your administrators receive hands-on sessions covering user, group and client administration as defined in the written scope.
Compliance preparation material maps controls and evidence to your assessment, while independent auditors issue any formal conclusions.

How we support

After handover, ongoing support, upgrades and continuous testing of the directory are available as a retainer.
Upgrade planning covers Keycloak release cadence and FreeIPA security releases, with changes applied in a staged, documented way.
Quotes follow from the written scope, so ask us to itemize setup, migration, testing and retainer work separately.

Open-source alternative to Okta Universal Directory