Open-source alternative to JumpCloud Cloud LDAP: the short answer
Apps, NAS devices and Linux hosts that bind to JumpCloud Cloud LDAP need a directory that answers the same bind requests after a renewal, a pricing change or a residency requirement forces a move. OpenLDAP, LLDAP, FreeIPA and authentik's LDAP outpost cover different scales and different feature sets, so the first decision is which of them matches the size of your directory and the services that depend on it. For Linux-heavy fleets, FreeIPA is the strongest fit because it combines an LDAP directory with Kerberos, host enrollment through SSSD, sudo and host-based access rules, and OTP in one product. It is the option that most closely covers what Linux hosts and SSH access need from a directory.
OpenLDAP is a full LDAPv3 server with replication options for environments where a single point of failure is not acceptable, but it leaves identity workflows, web administration and Linux enrollment to you. LLDAP is much lighter and has a simple web interface, yet its own documentation says it is not a full LDAP server, offers no commercial support, and is not recommended for the infrastructure of a large organization unless you are prepared to audit and maintain the code. authentik's LDAP outpost fits organizations that already run authentik for SSO, since the same users and groups serve web apps and LDAP binds. Each option changes how bind accounts, group filters and certificates are handled, so the choice should follow your client inventory rather than a feature list.
Before you pick a platform, inventory every client that binds to JumpCloud Cloud LDAP, including the base DN, bind account, group filter, TLS settings and the attributes each client reads. Confirm with each vendor how that client authenticates, since some NAS devices and appliances accept only simple binds and some Linux services depend on Kerberos. Plan to run old and new directories side by side during cutover so that clients can be repointed one at a time and rolled back without a password reset. Ask any implementation partner to write this inventory into the scope before work starts.
Which LDAP capabilities map to which open-source option
This table maps the LDAP-related capabilities that JumpCloud Cloud LDAP clients typically depend on to OpenLDAP, LLDAP, FreeIPA and the authentik LDAP outpost. Read each row against the attributes and bind patterns your own clients use, because JumpCloud-specific schema details must be confirmed in your tenant. The main takeaway is that no single option covers every row, so the choice depends on which clients bind and what must be managed.
| Capability | Best-fit option | Gaps and what to confirm |
|---|---|---|
| Simple bind and bind accounts | OpenLDAP, FreeIPA and the authentik LDAP outpost all accept simple binds over TLS | Confirm each client's bind DN format and whether it requires LDAPS or StartTLS. LLDAP is an authentication-oriented server, so verify it accepts the bind pattern your devices use. |
| Group and attribute lookups | OpenLDAP and FreeIPA support user, group and host objects with configurable schemas | Custom attributes in LLDAP are managed through the web UI or GraphQL API. Map each attribute your NAS or app reads before cutover. |
| Nested groups | FreeIPA and OpenLDAP with an appropriate schema and overlay | Test nested group resolution with each client. Confirm whether LLDAP or the authentik outpost expands nested membership the way your clients expect. |
| POSIX attributes for Linux login | FreeIPA, with SSSD on enrolled hosts | OpenLDAP needs manual schema work for UIDs and GIDs. LLDAP is not designed as a full POSIX directory, so confirm before using it for SSH or PAM login. |
| TLS and certificate authentication | OpenLDAP (TLS and SASL) and FreeIPA (integrated Dogtag certificate authority) | Decide who issues server certificates for clients. LLDAP and the authentik outpost depend on how TLS is terminated in your deployment, so confirm the setup. |
| Replication and high availability | OpenLDAP supports single-provider and multi-provider replication; FreeIPA uses multi-master 389 Directory Server replication | FreeIPA recommends at least two to three replicas per datacenter. LLDAP does not document multi-master replication, so plan for a single-instance design. |
| Web admin UI | LLDAP and FreeIPA provide web interfaces; FreeIPA 4.13.0 introduced a new web UI in beta | OpenLDAP has no bundled web UI and needs a separate tool such as phpLDAPadmin. Confirm that the admin tool you pick is maintained for your version. |
| SSO and OIDC | Keycloak or authentik, with LLDAP or FreeIPA as the user source | LLDAP's README suggests pairing it with Keycloak or Authelia for OAuth and OpenID. FreeIPA provides Kerberos SSO rather than OIDC, so SaaS SSO needs another component. |
| MFA and RADIUS | FreeIPA supports HOTP and TOTP and can proxy OTP checks to RADIUS; authentik provides a RADIUS outpost | OpenLDAP and LLDAP do not provide MFA on their own. Confirm which MFA method each NAS or VPN device supports before choosing the MFA path. |
| Backup and restore | FreeIPA provides ipa-backup and ipa-restore; OpenLDAP and LLDAP require their own backup procedures | Restoring an outdated FreeIPA backup into an active replica topology can break replication. Test restores on a separate environment and document the procedure for each option. |
Choosing between OpenLDAP, LLDAP, FreeIPA and authentik
Four self-hosted options can serve LDAP binds in place of JumpCloud Cloud LDAP, and they differ more in scope than in protocol. The right choice depends on how many clients bind, whether you need Kerberos, sudo and host access rules, and whether LDAP should sit beside SSO and RADIUS in one product.
OpenLDAP for large, custom directories
OpenLDAP provides slapd, a full LDAPv3 server under the OpenLDAP Public License, with the MDB backend and single-provider or multi-provider replication. It fits teams that need a complete directory and accept building their own admin tooling, schema changes and user lifecycle scripts. Choose between the long term support 2.6.15 and the feature 2.7.1 release, and confirm that your bind accounts, ACLs and overlays are covered by your own test plan. Expect the admin interface to be yours to build or buy.
LLDAP for small, simple user stores
LLDAP is a lightweight GPL-3.0 server with a web interface for users and groups, a GraphQL API and SQLite by default, with PostgreSQL or MySQL/MariaDB as options. It suits a small set of apps that bind for authentication, but it is not a full LDAP server and offers no multi-tenancy, so each virtual host needs its own instance. The project is volunteer-maintained with no commercial support, so verify that the bind features your NAS or Linux hosts need are present before cutover.
FreeIPA for Linux-heavy fleets
FreeIPA combines 389 Directory Server, MIT Kerberos, Dogtag certificates and SSSD on clients under GPL-3.0-or-later. It is the strongest fit when you also need host-based access control, sudo rules, Kerberos single sign-on and OTP, since those rules replace what JumpCloud provides for SSH and sudo. Plan for the operating effort of replicas, DNS and backups, and note that its web UI is still in transition. Confirm which apps accept Kerberos or LDAP binds before choosing it for a mixed estate.
authentik LDAP outpost for combined SSO
The authentik LDAP outpost exposes an LDAP interface backed by authentik's MIT-licensed core, so one product can serve LDAP binds alongside SSO, SCIM and RADIUS. It is the natural choice when you are also replacing JumpCloud SSO. Confirm which directory and integration features your target edition includes, because some advanced integrations and ticket-based support sit in the Enterprise edition. Test each LDAP client's bind DN and group search filter against the outpost before moving production traffic.
How LDAP clients bind and why bind accounts matter
Every LDAP client that authenticates against a directory carries three values in its configuration: a bind DN (the account the client logs in as to query the directory), a search base (the point in the directory tree where lookups start) and a filter (the rule that selects which entries count as users or group members). NAS devices, business applications and Linux hosts usually store these values in their own files or web forms, and many of them were typed in once and never revisited. Before any cutover, treat each value as a dependency that must be inventoried, because a replacement directory will not have the same tree layout, account names or group model unless you build it that way on purpose.
Group filters deserve the closest attention. A client that asks for users whose memberOf attribute includes a given group DN depends on the directory maintaining that back-reference, while a client that uses a posixGroup style filter on memberUid or gidNumber depends on POSIX schema attributes being present. These are different data models, and a directory that only offers one of them will silently deny access to members of the other. Pull the configuration files or admin screens for every NAS, application and host bound to the directory, and record for each one the bind DN, the bind password location, the search base, the user and group filters, and the attributes it reads. Confirm the exact list with each vendor's documentation, because many clients expose these settings only in advanced options.
Plan the inventory as a decision list, not just a copy job. Note which clients use a dedicated service account, which bind as the signed-in user, and which allow anonymous reads, since each pattern needs a different replacement account and password rotation plan. Record where each bind password is stored, because a service account password embedded in a device image can outlive the device's owner. The resulting inventory tells you which directory options can serve each client as is and which will need a configuration change, and it becomes your test plan for the cutover window.
Running LDAP beside the rest of the JumpCloud suite
Linux hosts usually resolve accounts, groups and SSH access through LDAP or a JumpCloud agent, so a replacement has to answer the same lookups before any host changes. FreeIPA is the most complete target here because its client component, SSSD, is designed for enrollment, and it covers host-based access control and sudo rules that a plain LDAP server does not. Access rules are the part most often lost in a move.
- Source of truth first: Decide which system owns UIDs, GIDs and group membership before enrolling any host.
- Host by host cutover: Enroll one host group at a time with SSSD and keep the existing resolution path available until logins are verified.
- Access rules: Sudo and HBAC rules need manual migration through LDIF, so inventory every rule on the hosts first.
- Stable identifiers: Keep existing UID and GID values so file ownership on local disks and network shares does not break.
- Replica count: FreeIPA's deployment recommendations call for two to three replicas in each datacenter before production hosts depend on it.
Before the first host moves, confirm which sudo, SSH key and group sources each host reads today, and record them so you can compare results after the change.
Internal applications that bind over LDAP, such as wikis, dashboards and build tools, often sit next to SaaS applications that already use JumpCloud SSO. The two groups usually move on different timelines, so the LDAP replacement can run beside JumpCloud for a period. Keep the LDAP cutover separate from any SSO change unless you have tested both together.
- Bind accounts: Service bind accounts are separate credentials. Create them in the new directory with read-only rights and keep the old ones until each client has switched.
- Dual password paths: During coexistence, users may see one password for LDAP-bound apps and another for SSO apps. Tell users which login goes where.
- Moving SSO too: If Keycloak or authentik becomes the SSO front end, each OIDC or SAML application must be re-federated, and existing sessions and MFA enrollments may need to be re-established. Confirm this with the vendor and test each app.
- Group filters: Search filters that match on group membership attributes must return the same users in the new directory. Compare results with
ldapsearchbefore switching a client. - Ordering: Move low-risk internal apps first and leave the apps that administrators use for recovery until last.
Before cutover, list every application that binds over LDAP and every SSO connection, because the two lists rarely match.
NAS devices, switches and similar appliances usually have a fixed LDAP configuration screen with limited options. They may expect specific attributes, a particular schema, or one server address with no fallback. Their behavior after an LDAP change is often less visible than on a server, so test with a non-administrator account before moving the rest of the users.
- Transport support: Confirm whether the appliance uses LDAPS, StartTLS or plain LDAP, and whether it validates certificates against a configured CA.
- Schema and attributes: Check which attributes the appliance reads for users and groups. LLDAP presents a simplified interface, while OpenLDAP offers a full LDAP server and suits appliances with unusual schema needs. Confirm the fit before you choose.
- Credential caching: Some appliances cache group lists or logins. Plan a cache flush and a test login for each device.
- Certificate trust: Install the internal certificate authority on each appliance before the cutover so that secure binds do not fail during the change.
- Break-glass access: Keep a local administrator account on each appliance so that a bad directory setting does not lock out every operator.
For each appliance model, check the vendor documentation for LDAP field requirements and record the firmware version you tested.
During coexistence, passwords and group memberships can exist in two places. Drift between them causes the most confusing failures: a user is removed from a group in one system but still has access in the other, or a password reset succeeds in one directory and fails in the other. Assign one system as the writer for each attribute and make the other read-only for that attribute.
- One writer per attribute: Pick JumpCloud or the new directory as the owner of group membership, and disable edits in the other system for those groups.
- Password source: Ask JumpCloud which fields its export includes and whether password material can be exported. If it cannot, plan a staged reset path for users and tell them before it starts.
- Sync method: Scheduled exports or scripts create gaps between runs. After each sync, compare user and group counts and spot-check sample accounts.
- Suspended and deleted users: Disable the same accounts in both systems before cutover, or a removed employee may still authenticate somewhere.
- Rollback path: Keep the old source readable until the last LDAP client has moved. FreeIPA's migration tooling can import users and groups from another LDAP server with
ipa migrate-ds, but Kerberos attributes are regenerated and sudo and HBAC rules need manual work, so treat it as one step in the plan.
Before starting, write down the owner of each attribute and agree on who can approve an emergency change in either system.
How the LDAP replacement fits with SSO, MFA and device management
LDAP is only one of several JumpCloud services. Before you move bind accounts, plan how the new directory connects to single sign-on, one-time passwords, RADIUS and device management, since each of these may stay on a different component. The cards below separate those pieces so that no service is switched off by accident.
Keep SSO running while LDAP moves
JumpCloud may still issue SSO logins to SaaS and web apps while its LDAP service is replaced. Decide whether the new directory will be the source of truth for every app or only for LDAP clients during a transition. Check which apps hold a JumpCloud SSO connection and which only bind over LDAP, because the two groups move on different dates. Confirm that user identifiers match in both systems so a login does not create a duplicate account.
An IdP reads the new directory
Keycloak supports user federation with existing LDAP and Active Directory servers, so it can authenticate users stored in a new LDAP directory and issue OpenID Connect or SAML logins. Map the directory attributes and group membership the apps rely on before you switch the federation source. Be aware that LLDAP suggests pairing it with Keycloak or Authelia for OAuth and reverse proxy features, so that combination needs its own test plan.
RADIUS and MFA need their own component
A directory answers password checks for LDAP clients, but it does not answer RADIUS requests from Wi-Fi controllers or VPN concentrators, and it does not provide one-time passwords by itself. FreeIPA can proxy OTP checks to an existing RADIUS server, which keeps a token-based second factor in place during the move. Identify every RADIUS client and MFA prompt in use, then confirm which component will answer each one after cutover.
Device management stays outside the directory
An LDAP directory stores accounts and groups for hosts, but it does not manage laptop configuration, patch state or device enrollment. Plan a separate path for Windows, macOS and Linux endpoints that JumpCloud currently controls, such as configuration profiles and software policy. Ask your team to list which device policies depend on JumpCloud groups, since those groups must be rebuilt somewhere else before the directory is retired.
Moving bind accounts and group filters without breaking clients
This sequence moves LDAP bind accounts, search bases and group filters from JumpCloud to a new directory in an order that lets each client be tested and switched over without losing sign-in for users or services.
Inventory every LDAP client and its bindings
Someone on the platform team lists every application, NAS device, router and Linux host that binds to JumpCloud Cloud LDAP. For each one, record the bind DN, the search base, the user and group filters, the attributes it reads (such as uid, gidNumber or memberOf), whether it uses StartTLS or LDAPS, and who owns it. Keep the list in a shared register. The step is done when every client has a row and the owner has confirmed the entry, because any client missing from the list will break at cutover.
Export users and groups from the Admin Portal
An administrator exports users and groups from the JumpCloud Admin Portal as CSV or JSON and stores the files in a controlled location. Passwords are not available as plain data, so plan to reset them or have users re-bind through a sign-in flow in the new directory, and check which attributes the export omits, such as POSIX identifiers or custom attributes. The step is complete when the export row count matches the active user and group counts in the Admin Portal and the gaps are written down.
Recreate groups and custom attributes in the target
The directory team builds the same groups, POSIX identifiers and custom attributes in the target directory. For FreeIPA, the ipa migrate-ds command can bring over users and groups from another LDAP server, but it excludes Kerberos attributes that FreeIPA regenerates, and sudo and HBAC rules need manual LDIF migration. For OpenLDAP or LLDAP, the schema and group model must be defined by hand. Compare group membership counts against the export. The step is done when a sample of groups returns the same members in both directories.
Create least-privilege service accounts
The directory team creates one read-only bind account for each client or client group, placed in a dedicated organizational unit, with access limited to the search base and attributes that client needs. Avoid reusing an administrator account for binds. Record each account, its scope and the client that uses it. The step is complete when each account can authenticate and read only the entries it should, and a bind attempt to a restricted area is refused.
Test binds and filters from each client in staging
Each client owner points one test instance of the client at the new directory on a staging network and runs the sign-in and group checks the client relies on, including search filters, group-based access and certificate or TLS validation. Record the results per client, including any change to filter syntax, attribute names or case sensitivity. The step is done when every client passes its test cases and each fix is logged against the register from the first step.
Cut over clients in batches
The platform team repoints clients to the new directory in small batches, starting with low-risk systems such as test hosts and then moving to production NAS devices, Linux hosts and applications. Change one batch at a time, confirm sign-in from a sample of real users after each batch, and keep a documented rollback path that restores the previous bind DN and server address. The step is complete when every batch shows successful authentication and the register marks each client as cut over.
Keep the old directory read-only until verified
After the last batch, the team switches JumpCloud Cloud LDAP bind accounts to read-only or disables them where the client allows, and leaves the old directory in place as a reference for a period the organization sets in its own change policy. Confirm with the owners that no client still queries the old endpoint by reviewing directory logs or network traffic. The step is done when the log review shows no remaining binds to JumpCloud and the owners sign off on the decommission.
What do buyers ask about replacing JumpCloud Cloud LDAP?
How much effort does moving off JumpCloud Cloud LDAP take?
The effort depends mostly on how many LDAP clients bind to the directory, how complex their group filters and search bases are, and how passwords are handled during the cutover. Each client needs its bind DN, search base, filter and TLS settings checked against the new server, and every app that stores or validates credentials needs a test login before users are moved. Clients that bind with a service account need that account recreated with the same distinguished name or updated in configuration. Passwords are the hardest part because standard JumpCloud exports do not include them, so the plan needs a decision on forced resets, staged logins or a bridge period. Ask any partner to inventory clients and filters first, since that inventory is what the quote should price.
Can our own team migrate JumpCloud LDAP clients without a partner?
A capable directory or Linux team can often do the work in-house if the client count is small, the filters are simple and there is time to test each application. The risk sits in the details: an unexpected bind DN, a case-sensitive attribute or a group filter that behaves differently on the new server can lock users out of a NAS or host. Teams without prior LDAP experience usually benefit from an outside review of the schema, TLS setup and replication design before go-live. Whichever route you choose, keep a rollback path for each client and test with real user accounts rather than only admin accounts.
Which open-source LDAP option fits a small or a large organization?
The right option follows from scale and features rather than brand preference. For a small estate that needs only a simple user and group store for NAS devices or a few apps, LLDAP is lightweight and has a web front end, though it has a narrower feature set and no commercial support. For Linux-heavy fleets that also need Kerberos, sudo rules, host-based access control and certificates, FreeIPA covers more ground and runs as a multi-master replicated service. OpenLDAP gives full control over schema, overlays and replication for teams that accept building their own management tooling. authentik's LDAP outpost suits organizations already running authentik for SSO. Compare each option against your client list and the features you actually use.
Is LLDAP safe to run for an organization?
LLDAP is free software under GPL-3.0 and is suitable for some small deployments, but its own FAQ says it is not recommended for the infrastructure of a big organization unless you are prepared to audit and maintain the code. The project is volunteer-run, offers no commercial support and describes itself as having a bus factor of one. Before using it for anything critical, confirm your own patching process, review its security history and decide who would fix a defect. If you need an enterprise-grade directory with documented replication and a vendor-independent support path, look at OpenLDAP or FreeIPA instead.
Can we export passwords from JumpCloud for the new LDAP directory?
Standard JumpCloud user exports do not include password hashes or the MFA enrollments tied to each user, so plan for users to set or confirm credentials in the new directory. Confirm with JumpCloud whether your plan and contract allow any password-related export before you rely on it, because the answer varies by account and is not something to assume. Where a credential must carry over, it should travel through a controlled, documented process and never through an ad hoc file. Many teams reduce the problem by using a short parallel period or forced resets scheduled per application group.
How do backups and replicas differ across the LDAP options?
The options protect data in different ways, and the difference matters during recovery. OpenLDAP supports single-provider with multiple consumers and multi-provider replication, so you design the topology and test failover yourself. FreeIPA uses 389 Directory Server multi-master replication and recommends at least two to three replicas in each datacenter, with ipa-backup and ipa-restore for backups. Its documentation warns that restoring an outdated backup into an active replica topology can break replication, and that the first server handles certificate renewal and CRL publication by default. LLDAP stores data in SQLite by default and can use MySQL, MariaDB or PostgreSQL, so backup depends on that database choice. Ask any partner to document the backup schedule, restore test and replica placement for your chosen option.
What should we ask a partner to include in a fixed-scope quote?
Ask for a written scope that lists each LDAP client, its bind method, filter, TLS mode and owner, along with the chosen directory option and the environments it will run in. The quote should separate one-time work, such as design, migration, testing and documentation, from recurring work, such as patching, backups and upgrades, and say which of those is covered by a retainer. Request the acceptance criteria for each client, the rollback plan, the test evidence you will receive and who performs the cutover. Confirm what is excluded, including password resets, application-side changes and any RADIUS or SSO migration handled elsewhere. DeployOpen scopes and delivers these engagements in writing before work begins, so the quote will follow from the agreed inventory.
What the cost of an open-source LDAP replacement includes
The software line is the smallest part of this cost. OpenLDAP, LLDAP, FreeIPA and authentik's LDAP outpost are all open source, so no license fee recurs for the directory itself. What you pay for is the servers and database behind it, the replicas that keep bind requests answered during an outage, and the people who run it. LLDAP stores its data in SQLite by default and can move to MySQL, MariaDB or PostgreSQL, so ask the vendor or integrator which database tier they expect and who licenses or supports it. FreeIPA's deployment recommendations call for two to three replicas in each datacenter and dedicated servers, which multiplies the hardware and operations line. Confirm the replica count and hosting model in your own environment before comparing totals. Most of the recurring cost is staff time. Someone has to patch the directory, track security releases, test upgrades against your NAS, Linux and application clients, and restore from backup when needed. FreeIPA 4.13.4 fixed two CVEs, including LDAP access control flaws that could let unauthenticated clients obtain credentials, so a quote should state how fast security releases are applied and who signs off. LLDAP's FAQ says it has no commercial support and a bus factor of one, so an LLDAP estimate that omits maintenance staff or a support contract understates the risk. Ask whether the scope includes ongoing upgrades, monitoring and a retainer. One-time work includes migration, testing and client reconfiguration. Each bind account, service account and group filter must be recreated or re-pointed, and each client (NAS, Linux host, application) needs a test window before cutover. Request the following in a written quote: the component chosen and why, server and database sizing, replica topology, backup and restore testing, a per-client reconfiguration list, the upgrade and security patch process, and whether support is included or billed separately. Ask for each recurring item to be shown as a monthly or annual line so it can be compared with your current renewal.
How DeployOpen scopes and delivers an LDAP replacement
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, so LDAP replacement work starts from your bind accounts, group filters and client inventory. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory every application, NAS device and Linux host that binds to JumpCloud Cloud LDAP, with its bind account and search base.
- Decide between OpenLDAP, LLDAP, FreeIPA and authentik's LDAP outpost against your user count, group model and required features.
- Agree the written scope, deliverables and timeline before work starts, with ongoing support available as a retainer.
How we build
- Deploy the chosen directory in your own cloud accounts, data centers or air-gapped network, with replication designed for your availability needs.
- Recreate bind accounts and group filters in the target directory, then test each client against a non-production copy first.
- Harden TLS, access controls and backups, and confirm restore procedures in a test before the production cutover.
How we hand over
- Provide documentation of the directory layout, client configuration, bind account ownership and rollback steps for your operators.
- Run a staged cutover that moves clients in groups, with a defined fallback path until each client authenticates successfully.
- Prepare control evidence for your compliance assessment, while independent auditors and certification bodies issue any attestations.
How we support
- Maintain the directory through upgrades, patch cycles and client changes under a retainer if you want continuous support.
- Run security testing against the LDAP service and its exposed endpoints on a recurring basis if your risk model requires it.
- Confirm with us during scoping which support tiers, response expectations and upgrade windows the retainer covers.
