Migrate from JumpCloud to FreeIPA

Migrate from JumpCloud to FreeIPA: what the move involves

For a Linux-heavy team that pays for JumpCloud user accounts and SSH access, the move to FreeIPA is mainly a directory rebuild. Users, groups, host enrollment and access rules have to be recreated on your own servers, and web SSO for SaaS and internal apps is a separate workstream that can run on a different timeline. Most teams do the core work with their internal platform or identity engineers, who already run Linux fleets and know SSSD, Kerberos and DNS. An implementation partner is usually brought in for the design of the topology, the replica layout and the cutover plan, not for daily operation. FreeIPA is licensed under GPL-3.0-or-later and has no paid edition of its own, so the software cost is zero and the recurring spend shifts to servers, staff time and any support contract you choose to buy from a third party.

The effort is driven less by the software than by how many access rules JumpCloud enforces today. Users and groups can be moved with the ipa migrate-ds command, which skips Kerberos attributes that FreeIPA regenerates, but sudo and HBAC rules need to be translated by hand through LDIF. Each enrolled host also needs its SSSD configuration checked, and the deployment guidance calls for at least two to three replicas in each datacenter with dedicated servers. Plan a staged cutover in which a pilot group of hosts authenticates against FreeIPA while the rest stay on JumpCloud, and confirm before you start that your DNS, certificate and backup design matches the FreeIPA deployment recommendations. Ask any partner to show the rule translation and rollback steps in writing before work begins.

Which JumpCloud capabilities map cleanly to FreeIPA

This table maps each JumpCloud capability used in a Linux-focused estate to its FreeIPA equivalent and marks it as clean, needs rework or gap. Read the rows for user, LDAP, SSH and sudo first, since those drive most of the migration effort. SaaS SSO and Windows or macOS device management are gaps, so confirm which JumpCloud features your tenant actually uses before planning.

Capability	FreeIPA equivalent	Status
User and group directory	389 Directory Server as a multi-master LDAPv3 store for users, groups and hosts	Clean
LDAP binds for apps and NAS devices	LDAP directory served by 389 Directory Server; bind accounts and group filters must be re-created and tested	Needs rework
Linux login and SSH keys	SSSD on each client resolves users and groups; SSH public keys are stored on the user entry and distributed by SSSD	Needs rework
Sudo and host access rules	Sudo rules and HBAC rules must be translated by hand from JumpCloud policies, typically through LDIF	Needs rework
MFA and OTP	HOTP and TOTP tokens, including YubiKeys, with OTP checks proxied to an existing RADIUS server if needed	Needs rework
Certificates	Dogtag certificate authority issues host and service certificates, so internal PKI moves into FreeIPA	Clean
SaaS SSO and app federation	No SAML or OIDC application gateway for SaaS apps; web SSO needs Keycloak or authentik alongside FreeIPA	Gap
Windows and macOS device management	FreeIPA manages Linux and UNIX hosts; Windows and macOS device policy needs a separate tool	Gap

Which exports and integrations to move, and how

JumpCloud's export covers identity records, but not everything an FreeIPA deployment needs. Each card below separates what the export carries, what must be re-created by hand, and what needs a separate component so that Linux logins and SSH access keep working through the cutover.

User and group records

Export users and groups from the JumpCloud Admin Portal as CSV or JSON, then check which attributes come with them, such as usernames, UID and GID values, home directories, shells and group membership. For LDAP-sourced data, FreeIPA's ipa migrate-ds command imports users and groups from an existing LDAP server and regenerates Kerberos attributes instead of copying them. Confirm in your own tenant whether the JumpCloud export preserves UID and GID numbers, because Linux file ownership depends on them.

Passwords and credential handling

Plan for password re-entry. The JumpCloud export is documented to exclude passwords, so users will not carry their existing credentials into FreeIPA unless you obtain hashes through a supported route. Ask JumpCloud in writing whether hashes can be provided and in what format, and confirm that FreeIPA can use them before you plan the cutover. Otherwise, set a first-login reset flow and communicate the change to users in advance.

SSH public keys

Export SSH public keys if the JumpCloud export includes them, and confirm the field names and key formats in your tenant. Keys attached to users in FreeIPA are served to hosts enrolled with SSSD, so every key must be re-attached and tested before access from JumpCloud is removed. Keep the private keys with their owners, and never copy them into the export or migration files.

Host enrollment with SSSD

Each Linux host that JumpCloud manages needs to be enrolled as a FreeIPA client, which configures SSSD to resolve users, groups and Kerberos tickets from the FreeIPA servers. Remove the JumpCloud agent only after a test login succeeds through SSSD on a pilot host. Record which hosts are enrolled, which still depend on JumpCloud, and which local accounts must remain as break-glass access.

Access rules as HBAC and sudo

Translate JumpCloud access policies into FreeIPA host-based access control (HBAC) rules and sudo rules. The migration how-to states that these rules need manual migration through LDIF, so the work is a rule-by-rule review rather than a bulk import. Map each JumpCloud policy to a named HBAC rule, document who can reach which host, and test denial as well as allowance on each host group.

LDAP bind accounts and RADIUS

Applications, NAS devices and Wi-Fi or VPN gear that bind to JumpCloud over LDAP or authenticate over RADIUS will not move with the Linux accounts. Inventory each bind account, its search base and its group filters, then decide whether FreeIPA's LDAP interface or a separate RADIUS component serves that client. FreeIPA covers OTP checks and can proxy them to an existing RADIUS server, but confirm the RADIUS and client protocol needs before cutover.

Migration sequence from inventory to decommission

This sequence moves Linux accounts, groups and SSH access from JumpCloud to FreeIPA in stages, so each stage proves a step before JumpCloud stops being the source of truth. The result is a documented, reversible cutover and a decommission that only happens after a verified backup.

Inventory users, groups, hosts and access rules
Export the user and group lists from the JumpCloud Admin Portal and record every host bound to JumpCloud, the SSH and sudo rules applied to each, and any LDAP bind accounts that services use. Confirm with JumpCloud which attributes the export includes, because passwords and MFA enrollments are not carried over and users will need to re-enroll. The output is a spreadsheet that maps each host group to the users, sudo privileges and login rights it grants. The step is done when every JumpCloud-bound host appears in the map and an owner has signed off on each access rule.
Build a lab FreeIPA deployment and pilot
Stand up a lab FreeIPA deployment with a replica so that you can test enrollment and rule translation without touching production. Import the exported users and groups using the migration tooling described in the FreeIPA migration how-to, then recreate sudo and host-based access control rules manually with LDIF, since those rules do not migrate automatically. Enroll a small set of non-critical hosts with SSSD and test SSH logins with users who are members of the translated rules. The output is a pilot record listing which logins, sudo commands and denied attempts behaved as the inventory expected. The step is done when every pilot test matches the map from the first step.
Understand ipa-backup and the replica topology
Before any production change, the team must understand how the FreeIPA topology behaves. Review the deployment recommendations for replica count, replication agreement limits and the placement of certificate and DNS services, and confirm which server handles certificate renewal and CRL publication by default. Rehearse ipa-backup and ipa-restore in the lab, and note the warning that restoring an outdated backup into an active replica topology can break replication. The output is a written runbook that names the primary server, the backup schedule and the restore procedure. The step is done when the team can restore the lab from a backup and explain the topology without referring to notes.
Run SSSD in parallel while JumpCloud stays authoritative
Enroll the pilot hosts as FreeIPA clients with SSSD while JumpCloud remains the authoritative directory for logins and password changes. Keep both directories aligned by repeating the inventory for any user or group that changes during the run, and record each discrepancy in an issue log. Monitor authentication logs on the pilot hosts for failed logins and sudo denials for several working cycles chosen by your change board. The output is an issue log with every discrepancy classified as fixed, accepted or blocking. The step is done when no blocking issues remain open and the change board approves the cutover.
Cut over hosts in groups
Move production hosts to FreeIPA in small groups, starting with the least critical systems and ending with those that carry privileged access. For each group, switch the SSSD configuration, verify that a test user can log in with the same rights as in JumpCloud, and keep a documented rollback path to the JumpCloud binding. Tell users that their passwords and MFA enrollments must be set up again in FreeIPA, and provide the re-enrollment steps before the cutover date. The output is a cutover record for each group with the verification results and any rollback events. The step is done when every planned group runs on FreeIPA and the JumpCloud bindings are removed from those hosts.
Decommission JumpCloud after a verified backup
Once all hosts authenticate against FreeIPA, take a full ipa-backup and confirm that a restore works in the lab. Remove the remaining JumpCloud bindings, revoke JumpCloud API keys and LDAP bind accounts, and disable the directory. Before the contract ends, confirm with JumpCloud how long your data remains available and what deletion it performs, and keep the final JumpCloud export in your records according to your retention policy. The output is a decommission record with the backup identifier, the list of revoked credentials and the date each JumpCloud resource was removed. The step is done when no host or service still depends on JumpCloud and the backup restore has been tested.

How SSSD, HBAC and sudo rules replace JumpCloud host policy

Each enrolled Linux host resolves users and groups through SSSD, which queries FreeIPA rather than a local password file or JumpCloud's agent. Once a host is enrolled, SSSD answers identity lookups from the 389 Directory Server behind FreeIPA and authenticates Kerberos tickets against the MIT Kerberos KDC, so getent passwd and SSH logins use the same directory record. Your JumpCloud-managed hosts will need their existing local accounts, PAM and NSS entries reviewed before enrollment, because a user who exists both locally and in FreeIPA can log in as two different identities. Confirm which SSSD domain settings each host needs with the FreeIPA client enrollment documentation for your distribution.

HBAC (host-based access control) rules decide which users or groups may log in to which hosts or host groups, and FreeIPA evaluates them on the server side. Most JumpCloud host policies translate into a small set of HBAC rules: one per host group and service, such as sshd or login, pointing at the user groups that were previously bound to those devices. Sudo rules are stored in the directory as well, so a single rule can apply to a host group and be read by every enrolled client through SSSD. The FreeIPA migration how-to states that sudo and HBAC rules need manual migration through LDIF, so you should write each rule out from your JumpCloud policy export, map its users, hosts and commands explicitly, and load it into a staging FreeIPA instance first. Test every HBAC and sudo rule on a pilot host with a non-privileged test account and a break-glass administrator before any production cutover, and record which rule allowed or denied each attempt.

How the move differs by fleet size and starting point

A single-site Linux fleet is the simplest starting point. FreeIPA's deployment guidance recommends at least two to three replicas in each datacenter, so even a small estate should not run a lone IdM server for production. The replicas can sit on separate hosts within the same site, and the guidance asks for dedicated servers that run no other applications.

Replica count: Plan two or three IdM servers in the one site, each on a dedicated host, rather than one server that also runs other workloads.
DNS layout: Point every client's resolv.conf at at least two DNS servers, and run DNS on the IdM servers only if you intend to use the integrated BIND service.
Backups: Use ipa-backup on a schedule and test ipa-restore on a separate host. Restoring an outdated backup into a live replica topology can break replication, so restore into a rebuilt environment first.
Cutover: Import users and groups with ipa migrate-ds, enroll a few non-critical hosts with SSSD, and move SSH and sudo rules before enrolling production hosts.
Operating effort: One site still needs someone who can manage Kerberos, certificates and replication, so confirm that your team has that skill before you retire JumpCloud.

Confirm with DeployOpen or your own staff how many hosts you have and which services bind to them, because these decide the replica count and rollback plan.

What drives the cost and duration of the move

This table lists the components that change how much design, migration, testing and ongoing work a JumpCloud to FreeIPA move requires. Read each row as a driver: what raises effort, and what you can do before the quote to keep it down. Ask for a fixed-scope quote with the host list, rule inventory and consumer list written into the scope.

Driver	Why it moves effort	How to reduce it
Host count and configuration drift	Each Linux host must be enrolled with SSSD and its PAM, NSS and sudo settings checked. Hosts built by hand or from different images need individual handling, and drift multiplies test cases.	Inventory hosts by OS release and configuration management source before the move. Group them into a small number of enrollment profiles and retire unused hosts first.
Number of HBAC and sudo rules	JumpCloud access policies do not map one to one to FreeIPA. The FreeIPA migration guide says sudo and HBAC rules need manual migration through LDIF, so every rule is translated and tested by hand.	Export the JumpCloud policy list and remove stale or duplicate rules. Agree the target rule model (who, which hosts, which commands) before translation starts.
SSH key and account hygiene	Keys copied from JumpCloud may belong to departed staff, shared accounts or old service identities. Each one must be verified, and the export does not carry every credential type, so some users must re-enroll.	Audit SSH keys and local accounts against the HR list before import. Decide which accounts become FreeIPA users, which become service accounts and which are removed.
Replica topology and DNS design	The FreeIPA deployment recommendations advise two to three replicas in each datacenter, no more than four replication agreements per replica and at least two DNS servers in each client's resolv.conf. Each site adds design and testing work.	Confirm the number of sites and network paths early. Decide where CA and DNS roles sit, since the recommendations place PKI or DNS on at least one replica per datacenter when used.
Number of LDAP and RADIUS consumers	Every application, NAS device or network appliance that binds to JumpCloud LDAP or RADIUS needs its bind account, base DN and group filter repointed. Breaking one consumer can stop logins that have nothing to do with Linux.	Build a consumer register with owner, protocol, bind method and change window. Test each consumer against a non-production FreeIPA tree before cutover.
Web SSO apps that need a separate broker	FreeIPA provides Kerberos single sign-on and OTP but is not a SAML or OIDC provider for SaaS. Each web app that used JumpCloud SSO needs a separate broker such as Keycloak or authentik, with its own federation, testing and support.	List every SSO-protected web app and its protocol. Decide early which apps stay on another identity service and which are retired, so the broker scope is fixed before quoting.
Testing and cutover sequencing	Devices must keep authenticating while accounts move. Pilot groups, rollback steps and a parallel run period add test cycles and coordination with change control.	Define pilot hosts, success criteria and a rollback path in writing. Schedule cutover by site or host group rather than all at once.
Operating team training	Running FreeIPA means understanding replication, Kerberos ticket issues, certificate renewal on the first server and restore order. Staff who have only run cloud directories need time and documentation to operate it.	Ask for runbooks, a restore rehearsal and hands-on handover as part of the scope. Name the internal owners who will take patching and backup duties.
Recurring operation, patching and backups	After cutover, the team carries patching of the directory, DNS and CA roles, FreeIPA release upgrades, backup testing and host enrollment for new machines. These costs recur every year, not once.	Document the backup schedule with ipa-backup and test restores on a schedule. Ask for an estimate of ongoing hours and a retainer option in the quote.

What usually goes wrong and how to prevent it

Most FreeIPA migration failures come from treating the new directory as a simple import rather than a service that other systems depend on. The six risks below cover replication, network placement, Active Directory coexistence, host cutover and web applications, and each one has a check you can run before the JumpCloud contract ends.

Restoring an outdated backup

A backup restored into a live replica topology can break replication, because the restored server no longer matches the data its peers already hold. Treat ipa-restore as a recovery step for a rebuilt environment, not a routine rollback. Before any restore, confirm which server is the current source of truth, and schedule full backups along with online data-only backups so you have a recent copy to rebuild from. Review the backup documentation before you plan any recovery drill.

Too many replication agreements

Every additional replication agreement adds load and complexity to the topology, and FreeIPA's deployment guidance caps each replica at no more than four agreements. During migration, teams often add replicas for every site or every test host, then struggle to keep the mesh consistent. Draw the topology before you build it, check each replica against the limit, and keep at least two to three replicas in each datacenter as the guidance recommends.

Sharing servers with other applications

FreeIPA servers hold the Kerberos KDC, directory and often certificate authority and DNS roles, so an unrelated application running on the same host competes for resources and widens the attack surface. The deployment recommendations call for dedicated servers. Ask the team that owns the JumpCloud replacement whether any web app, build agent or monitoring stack is scheduled onto the IdM hosts, and move it off before cutover.

Overlapping DNS domains with Active Directory

If you plan a cross-forest trust with Active Directory, the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest. Teams that reuse the corporate parent domain for the IPA realm discover this only when the trust setup fails. Confirm the DNS namespace for both directories before you install, and document the name choice in the migration plan.

Losing SSH access during cutover

Moving hosts from JumpCloud to SSSD can lock administrators out if sudo rules, HBAC rules or the enrolled host entry are incomplete when the JumpCloud agent is removed. Keep an existing local administrator account and a tested key path on every host until SSH logins from FreeIPA users succeed. Translate sudo and HBAC rules first, test them on a non-production host, and only then remove the JumpCloud agent.

Web SSO apps left without a broker

FreeIPA provides Kerberos single sign-on for Linux services, but it does not give browser-based SaaS or internal web apps the SAML or OIDC login that JumpCloud SSO handled. Inventory every app that used JumpCloud SSO before cutover, and decide for each one whether it needs a separate broker such as Keycloak or authentik. Confirm the broker supports the protocol each app expects, or the apps will stop signing users in on the cutover date.

Questions teams ask before moving from JumpCloud to FreeIPA

How long does a JumpCloud to FreeIPA migration take?

No single duration applies, because the timeline depends on the number of hosts, the number of users and groups, and how many access rules must be rebuilt by hand. The biggest drivers are the number of Linux hosts that must be enrolled with SSSD, the number of sudo and host-based access control rules to translate, and how many services still bind to JumpCloud's LDAP or RADIUS endpoints. Replica planning and a tested rollback also add time. Ask JumpCloud for the export date you need and confirm the current contract end date, then build a host inventory before asking for a written timeline from any implementation partner.

Can JumpCloud passwords and MFA enrollments be exported to FreeIPA?

Plan on not exporting them. Users and groups can be exported and then imported into FreeIPA, but credentials and MFA enrollments should be treated as things you will have to reset or re-enroll. Confirm with JumpCloud exactly what its admin export includes and what it leaves out, and whether password hashes can be obtained at all under your plan. If hashes are unavailable, plan a controlled password reset and a token re-enrollment window for each user. FreeIPA supports HOTP and TOTP software and hardware tokens, so re-enrollment is a scheduled task, not a blocker, but it must be communicated and supported.

Can our own team migrate from JumpCloud to FreeIPA without outside help?

A team with strong Linux, Kerberos and LDAP skills can do the work in-house, but the risk concentrates in a few places: the replica topology, DNS, host enrollment and the translation of access rules. FreeIPA's documentation warns that restoring an outdated backup into an active replica topology can break replication, so operators need practice with ipa-backup and ipa-restore before production. Many teams combine internal ownership with a fixed-scope engagement for the design and cutover. DeployOpen plans, implements, hardens and documents self-hosted platforms in the client's own infrastructure, with scope and deliverables agreed in writing before work starts.

What does our team have to provide during the migration?

Expect to supply access and decisions, not just time. The usual inputs are an inventory of Linux hosts and their operating systems, a list of groups and the systems each one controls, the sudo and SSH access rules in use, the DNS domain for the IPA realm (which must not overlap with any Active Directory forest domain if you plan a trust), and named owners for cutover windows. You will also need a test host, a rollback plan and someone who can approve the password and MFA reset communication. Ask any partner to list these inputs in the written scope so that gaps are visible before work starts.

Does FreeIPA replace JumpCloud SSO for SaaS applications?

FreeIPA is not a replacement for SaaS single sign-on on its own. Its single sign-on is built on MIT Kerberos, which suits Linux hosts, SSH and applications that accept Kerberos or LDAP, but most SaaS products expect SAML or OpenID Connect. Teams usually keep SaaS federation in a separate component such as Keycloak or authentik, with FreeIPA as the user store behind it. Make an inventory of every web application that uses JumpCloud SSO, note its protocol, and confirm with each vendor whether it supports the federation method you plan to use before you commit to a design.

What does running FreeIPA involve after the migration?

Ongoing operation is mostly directory, replication and certificate work. 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. The first server handles certificate renewal and CRL publication by default, so backup and monitoring of that server need explicit attention. Security maintenance also matters: FreeIPA 4.13.4 fixed two CVEs, including LDAP access control flaws, so you need a patching process. Ask whether a support retainer for upgrades, testing and continuous review is part of the proposal.

Is FreeIPA free to use, and what does it cost to run?

FreeIPA is licensed under GPL-3.0-or-later and has no paid edition of its own, so the software license itself carries no fee. The costs are the servers and network for at least the recommended replicas, staff time for operations and patching, the migration effort, and any implementation or support contract you choose. Those costs recur or are one-time in different ways: hardware and hosting recur, while migration and design are usually one-time. Ask any vendor for a written quote that separates these components, and compare it against your current JumpCloud invoices, including any suspended users that are still billed.

What changes for administrators and end users on cutover day

Administrators move from the JumpCloud Admin Portal to two separate control points: the FreeIPA web UI for users, groups, host enrollment, HBAC rules and sudo rules, and the ipa command line on the IdM servers for bulk changes and scripted work. Nobody should expect one console for everything. Device management, SaaS SSO and any Windows or macOS policy that lived in JumpCloud will not appear in FreeIPA at all, so those responsibilities need a named owner before the window opens. Before cutover, have each administrator run a short rehearsal in a test realm: create a user, add a group, enroll a test host with SSSD, and confirm a sudo rule and an HBAC rule take effect. Confirm with the FreeIPA release notes for your chosen version which web UI features are still in beta before relying on them for routine work.

End users notice that their credentials and keys are the first thing that changes. Passwords are not carried over from JumpCloud, so each user must set a new password through the FreeIPA enrollment or reset flow, and SSH access depends on the public key that the user uploads to their FreeIPA entry, so anyone who logged in with a key stored only in JumpCloud has to re-register it before the first login. If your organization uses OTP, tokens must be enrolled again: FreeIPA supports TOTP and HOTP software and hardware tokens, and users need to scan a new seed rather than keep their JumpCloud authenticator entry. Publish the exact steps, the URL users must visit, and a help contact at least a week before the window, and tell users that a missed step means a locked account until an administrator resets it.

Communicate the change window in writing with a clear fallback. State which systems are affected, when the JumpCloud login path stops, when FreeIPA login starts, and who to call if a host still refuses a login. Do not promise zero downtime: identity cutovers that involve host enrollment and key re-registration usually produce a period where some logins fail, so tell users to expect that and keep the old JumpCloud path available until the agreed exit point. Record the decision on rollback criteria in advance, including who can authorize reverting clients, and confirm your backup of the FreeIPA topology exists, since the FreeIPA backup documentation warns that restoring an outdated backup into an active replica topology can break replication.

How DeployOpen scopes and runs the FreeIPA migration

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so a JumpCloud to FreeIPA move is run as a fixed-scope engagement with written deliverables. We agree the user, host and access inventory first, then build and test the FreeIPA topology in your environment before any cutover.

How we scope

We inventory JumpCloud users, groups, Linux host bindings, SSH access and sudo entitlements before agreeing scope.
The written scope lists which hosts, LDAP clients and web SSO applications move in each phase.
We confirm with you which applications need Kerberos, LDAP binds or web SSO, since each needs a different integration path.

How we build

We deploy FreeIPA servers and replicas in your datacenters or cloud accounts, following FreeIPA deployment recommendations.
We enroll test hosts with SSSD, then translate access rules into HBAC and sudo rules and test them against real login paths.
We set up ipa-backup schedules and test ipa-restore in a non-production topology before go-live.

How we hand over

You receive runbooks for enrollment, rule changes, certificate renewal and replica recovery, with the configuration kept in your repositories.
Each access rule is documented with its source group in JumpCloud, its HBAC or sudo equivalent and the test that proved it.
We walk your operations and security teams through cutover, rollback steps and the decommissioning checklist for JumpCloud.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover FreeIPA upgrades, security patch review and periodic backup restore tests.
Security testing of the new identity services can be scoped separately from the migration itself.

Migrate from JumpCloud to FreeIPA