Migrate from OpenLDAP to FreeIPA with ipa migrate-ds

Migrate from OpenLDAP to FreeIPA with ipa migrate-ds: what the move involves

A team leaving a hand-maintained OpenLDAP tree for FreeIPA should start by separating what ipa migrate-ds does from everything else the move requires. The command copies users and groups from the source directory into FreeIPA. Sudo rules, HBAC rules, Kerberos keys and client enrollment are separate work that you plan, build and verify yourself. Treating the command as the whole migration is the most common reason cutovers stall after the first successful run. Effort depends on three things you can measure before any work starts. The first is schema customization: every custom attribute and object class in your OpenLDAP tree needs a decision about whether FreeIPA carries it, maps it to an existing attribute, or drops it. The second is policy volume: a few sudo rules and HBAC rules are a short manual exercise, while hundreds of them, spread across host groups, need an export, a mapping and a test plan. The third is the number of clients that must be re-pointed to the new servers, including their SSSD configuration, certificates and service principals. Ask your partner, or your own team, to produce counts for each of these before agreeing a written scope.

The inventory is the first deliverable to insist on. It should list every object class in use, every attribute outside the standard schema, every sudo and access rule with the hosts it applies to, and every application that binds to LDAP directly rather than through SSSD. Applications that bind directly will not benefit from Kerberos single sign-on and need their own testing, so they belong in scope from the start. Confirm the exact ignored attributes and object classes for your source version in the FreeIPA migration how-to, because the list determines what the inventory must cover. Plan for a copy of the source directory and a non-production FreeIPA server so that every decision can be tested before production data is touched.

Which OpenLDAP and Red Hat Directory Server objects map to FreeIPA

This table compares each common OpenLDAP or Red Hat Directory Server object with its FreeIPA destination and the migration path. Read each row as a checklist: anything marked for migrate-ds is carried by the command, anything marked manual needs LDIF work, and any version-specific behavior should be confirmed in your own test run before cutover.

Object	Migration path into FreeIPA	What to confirm before cutover
User accounts	Moved with ipa migrate-ds; the command excludes Kerberos attributes that FreeIPA regenerates	Confirm which attributes your schema uses and that each expected user appears in the migrated set
Groups	Moved with ipa migrate-ds as POSIX groups with their members	Check nested groups and any group object classes the command does not map
User private groups	Created by FreeIPA for migrated users under its default user private group behavior	Confirm the GID handling and whether existing GIDs collide with FreeIPA ID ranges
Password hashes	Not regenerated as Kerberos keys by the command; handled through the password migration path	Test a login from a migrated user and plan for users whose hashes cannot be carried over
Sudo rules	Manual: export as LDIF and recreate as FreeIPA sudo rules	Test each rule on a copy host before any host group is switched
HBAC rules	Manual: export as LDIF and recreate as FreeIPA HBAC rules	Run access tests against representative users and hosts before enforcement
Host and service entries	Not carried as policy objects by the command; recreate through FreeIPA host and service enrollment	Confirm which hosts enroll with SSSD and which service principals need new keys
Custom schema and overlays	Not mapped automatically; review each attribute and overlay against FreeIPA schema before any import	Confirm the migrate-ds version in use and its documented ignored attributes and object classes

Documented import paths for LDAP into FreeIPA

FreeIPA has one documented importer for plain LDAP directories, plus a separate path for policy objects that the importer does not carry. The cards below cover each piece of the move from OpenLDAP and how to rehearse it before cutover. ipa-migrate is listed for completeness but applies only between two FreeIPA deployments.

The migrate-ds importer

The ipa migrate-ds command reads users and groups from a source LDAP server over the network and writes them into the IPA directory. Confirm the exact option set against the installed version with ipa migrate-ds --help, because options such as the bind DN, base DN, schema mapping and whether to migrate passwords vary across releases. Record which source attributes are excluded, since Kerberos attributes are regenerated by FreeIPA rather than copied.

LDIF export for policy

Sudo rules and HBAC policies do not move with migrate-ds, so they must be exported from the source as LDIF and reshaped for FreeIPA. Review each sudo command, host reference and user group in the export, because names that resolved in OpenLDAP may point to objects that do not exist yet in IPA. Load the converted entries only after the users and groups they reference are present.

Client re-enrollment

Migrating directory objects does not move Linux machines into the new realm. Each client needs its SSSD configuration pointed at the IPA servers and a fresh enrollment, and the host entries must exist before enrollment succeeds. Plan the order per host group so that a machine is never left with an SSSD configuration that points at a server it cannot authenticate against.

A test-copy setup

Rehearse the import against a copy of the source directory and a throwaway IPA server with the same domain and realm names as production. Compare user counts, group membership and login results for a sample of accounts before any cutover decision. Keep the test copy separate from production networks so that test logins and password changes cannot reach live systems.

ipa-migrate is not an OpenLDAP path

The ipa-migrate tool moves data between two FreeIPA deployments over LDAP, covering users, groups, certificates, sudo and HBAC rules, hosts, services, DNS, OTP tokens and policies. It does not read OpenLDAP or Red Hat Directory Server as a source. Teams starting from a plain LDAP directory should use migrate-ds and the manual LDIF steps instead.

How to sequence the migration with a parallel run and cutover

This sequence moves users, groups and policy from OpenLDAP into FreeIPA in controlled stages, so each stage is tested before clients depend on it and the old directory can be retired without losing access.

Inventory users, groups and policy
The team that owns the directory exports a full list of users, groups, nested memberships, service accounts, sudo rules, access controls and the host groups that rely on them. Record which attributes each application reads, because that list drives the mapping in the next step. Done when every consumer of the directory is named and each object type has an owner who signs off on the list.
Review the schema and attribute mapping
Compare the OpenLDAP schema against FreeIPA's object classes and attributes. Identify custom schema extensions, attributes FreeIPA does not store, and Kerberos attributes that migrate-ds excludes because FreeIPA regenerates them. Decide in writing where each dropped attribute goes, whether it is rebuilt by hand, or whether it is retired. Done when the mapping document is approved by the directory owner and the application owners who read those attributes.
Confirm FreeIPA topology before cutover
Before any client depends on FreeIPA, the production topology must be in place. FreeIPA's deployment recommendations advise at least two to three replicas in each datacenter, no more than four replication agreements per replica, at least one replica per datacenter running PKI or DNS if used, dedicated servers without other applications, and at least two DNS servers in each client's resolv.conf. Done when replicas are healthy, replication is verified in both directions, and DNS resolution from a sample client works through both servers.
Run migrate-ds against a copy of the directory
Load a copy of the OpenLDAP data into a non-production FreeIPA server and run ipa migrate-ds with the options chosen in the mapping review. Keep the run repeatable so the team can rerun it after each correction. Record every skipped object and ignored attribute in the run log. Done when a full run completes and the log is reviewed line by line against the inventory, with the reasons for each skip documented.
Validate migrated identities and groups
Compare counts and sample records between the source and the test FreeIPA server, including user private groups, nested groups and group memberships. Check that migrated accounts resolve through SSSD on a test client and that manual items such as sudo and HBAC rules are listed for rebuilding from LDIF. Confirm how password hashes are handled before any user is asked to log in. Done when the validation checklist has no open discrepancies and the owners of each application accept the test results.
Run a parallel period with gradual client enrollment
Keep OpenLDAP authoritative while enrolling a small set of non-critical clients into FreeIPA, then widen the group in stages. Track authentication failures, lookup errors and access decisions for each stage, and roll back any client that fails. Rebuild sudo and HBAC rules per host group as clients move, testing each rule before enabling it. Done when every host group has run on FreeIPA for an agreed period with no unresolved authentication incidents.
Cut over and retire the old directory
Freeze changes in OpenLDAP, run a final migration delta, point the remaining clients at FreeIPA, and confirm that applications which bind to the old directory have been reconfigured. Keep the OpenLDAP server read-only for a defined rollback window that the owners agree in writing. Done when no client or application queries OpenLDAP and the owners confirm the rollback window has closed.
Decommission the old directory and back up FreeIPA
Once the rollback window closes, archive a final export of the OpenLDAP data under the organization's retention policy, then shut down and remove the old server. Take an initial FreeIPA backup and record the restore procedure, since FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Done when the archive is verified, the old server is removed from inventory, and a tested backup exists for the new platform.

Running migrate-ds against OpenLDAP or Red Hat Directory Server

Custom schema is the main risk on OpenLDAP. Attributes and object classes defined in your own schema files have no equivalent in the FreeIPA schema, so migrate-ds cannot carry them across as they are. Before the run, export the schema definitions from your slapd configuration and list every attribute that user and group entries actually use.

Locally defined attributes: list each attribute that comes from your own schema and decide whether FreeIPA needs it. Anything your applications read must be mapped to a supported attribute or stored elsewhere.
Kerberos attributes: expect the tool to exclude Kerberos attributes, because FreeIPA regenerates them for migrated users.
Sudo and HBAC data: expect these rules to be absent from the output. The migration how-to says they need a manual LDIF migration.
Group membership storage: check how your groups store members and whether nested groups exist, so you can confirm the migrated memberships match what your applications expect.

Compare the ignored attribute list from the run output with your schema inventory line by line before you accept the result.

What drives the effort and cost of an LDAP to FreeIPA migration

This table lists the factors that change how much work an OpenLDAP or Red Hat Directory Server to FreeIPA move takes, and whether each factor is paid once or recurs. Use it to read a written quote: each driver should map to a line item, an assumption or an exclusion. The main takeaway is that schema mapping, password handling and access policy rebuilds usually weigh more than the user count alone.

Driver	Why it changes effort or cost	What to ask for in a quote
Number of users and groups	Every user and group must be mapped, de-duplicated and checked after the run, and group nesting in the source adds review work. Mostly one-time.	Object counts from an LDIF export, the mapping of source groups to FreeIPA groups, and how verification is sampled.
Custom schema and attributes	Local object classes and attributes that migrate-ds does not map need custom handling or a decision to drop them. One-time, and it grows with each undocumented attribute.	A list of custom object classes and attributes, which are carried over, transformed or ignored, and who signs off on that list.
Ignored attributes and object classes	Attributes that migrate-ds skips, such as Kerberos attributes that FreeIPA regenerates, can leave gaps that someone must fill. One-time.	A written mapping table for each ignored attribute and the replacement or regeneration step.
Sudo and HBAC rules	These rules need manual export to LDIF and rebuild in FreeIPA, then testing by host group. One-time for the migration, with ongoing review as policy changes.	The count of sudo and HBAC rules, the target host groups, and whether hbactest-based testing is included.
Password handling and forced resets	Migrated hashes may not be usable for FreeIPA Kerberos keys, so the approach decides whether users need resets and support load. One-time for the cutover, with help desk time during the first logins.	Whether password hashes will move or users will reset, the expected support window and who runs it.
Number of client hosts	Each enrolled or re-pointed client needs SSSD configuration and testing. Effort rises with host variety and with the number of distributions.	The client inventory by operating system, enrollment method and any hosts that stay on the old directory during transition.
DNS and certificate dependencies	Hostnames, SRV records, service certificates and CA trust must match the new realm before clients can authenticate. One-time setup, with renewal responsibility that recurs.	Confirmation of DNS ownership, the realm and domain names, and the certificate chain each service will use after cutover.
Test environment availability	A copy of the source directory and a non-production FreeIPA server are needed to rehearse the run. Without them, the production run carries the testing effort.	Whether the provider builds the test copy, who supplies its hardware or virtual machines, and how long it is kept for retests.
Backup and rollback planning	Restore procedures and a tested rollback path add work before cutover. Restoring an outdated backup into an active topology can break replication, so this step is not optional. One-time, with backups recurring after go-live.	Backup and restore steps, rollback criteria and who owns the backup schedule after handover.

What usually goes wrong in an OpenLDAP to FreeIPA move

Most failed directory moves are not caused by the migration command itself. They come from data that was never mapped, identifiers that clash, and systems that keep talking to the old directory. Each card below names one of these failure points and the check that prevents it.

Unmapped attributes dropped silently

The migration copies users and groups through a fixed mapping, and attributes outside that mapping do not arrive in FreeIPA. Custom schema attributes, office locations, or application-specific flags on your OpenLDAP entries can disappear without an error. Before the move, export a full inventory of attributes and object classes in use, compare it with what ipa migrate-ds carries, and list every gap that needs a manual LDIF load or a schema decision.

User private group GID conflicts

FreeIPA creates a user private group for each migrated user by default, and that group needs a GID. If a GID in your source directory already belongs to a group that FreeIPA also creates or manages, the group objects collide or the user ends up in the wrong primary group. Map every source GID against the target ID range, decide which groups keep their GIDs, and test the primary group membership of a sample of users on a copy before cutover.

UID collisions with existing accounts

Two source users can share a UID, or a migrated UID can match a local account already enrolled on a client. The result is ownership of files and processes passing to the wrong person, and SSSD resolving one name to another identity. Run a duplicate report on uid and uidNumber across the source directory and the target ID range, resolve duplicates before migration, and check existing client /etc/passwd entries on a sample of hosts.

Sudo and HBAC rules left behind

The migration tool excludes sudo and host-based access control rules, so access policy does not arrive with the users. Hosts can end up with no sudo rights or with HBAC rules that allow everyone, or nobody, to log in. Export every sudo and access rule from the old directory as LDIF, map each one to a FreeIPA rule, and run the access tests against each host group before any user is moved.

Clients still pointing at old LDAP

Servers and workstations with SSSD or PAM configured against the old LDAP keep authenticating users there, so password changes and account lockouts split across two directories. Accounts can look migrated while logins still succeed against stale data. Inventory every client's SSSD configuration, change the LDAP URI and base DN as part of enrollment, and confirm the active domain on a test host before retiring the old server.

Outdated backup restored into replicas

If a backup taken before the migration is restored onto a live replica topology, the restored data can conflict with changes already replicated from other servers, which can break replication. The FreeIPA backup documentation also notes that the first server handles certificate renewal and CRL publication by default. Keep a fresh backup taken just before cutover, restore only into a test environment for rehearsal, and confirm replication health with a full topology check after any restore.

Questions teams ask before migrating OpenLDAP to FreeIPA

Can our own team run ipa migrate-ds without outside help?

Yes, a team with Linux and directory experience can run ipa migrate-ds itself, because the command is part of the FreeIPA toolset and is documented in the FreeIPA migration how-to. The harder part is the work around the command: mapping your OpenLDAP schema, deciding which attributes to drop, moving sudo rules and HBAC policies by hand, and re-enrolling clients. Teams that already run FreeIPA and have staff who understand both the source directory and the target realm usually handle this in-house. Teams without that mix often bring in a partner for the scope and testing. Ask any partner for a written scope that names each manual step.

What skills does the migration need from our staff?

The work needs people who know four areas: the current OpenLDAP tree and its schema, Kerberos basics, FreeIPA server administration, and SSSD on your Linux clients. Someone must own the source directory's data model, because migrate-ds does not carry every object class or attribute into FreeIPA. A second person should own the target realm, including DNS, certificates and replication. Application owners need to be available to confirm which LDAP binds and group lookups still work after cutover. If these roles are thin, the schedule risk grows, and the cost of outside help rises with it.

Do users keep their passwords after the migration?

Not automatically in every case. The FreeIPA migration how-to explains that migrate-ds excludes Kerberos attributes, which FreeIPA regenerates in the new realm, so users may need a password path after the move. Whether existing hashes can be used depends on the hash type stored in your OpenLDAP directory and on how you configure password migration. Confirm this with a test copy before you promise users anything. Plan for a support path for users whose credentials cannot be carried over, since that group is the usual source of help-desk volume at cutover.

How does testing on a copy of the directory work?

Testing on a copy means exporting a snapshot of the OpenLDAP users, groups and relevant attributes, loading them into a non-production FreeIPA server, and running migrate-ds against that copy. You then compare what arrived with what you expected, check group membership, and test logins from a few representative clients through SSSD. Run each migrate-ds option you plan to use, record which attributes and object classes were ignored, and repeat the run until the output is stable. Keep the test realm on separate hosts so no production client points at it. Document every manual step, such as LDIF work for sudo and HBAC rules, so the cutover runbook can follow it exactly.

What changes for Linux clients and applications at cutover?

Clients must be enrolled in the new FreeIPA realm and use SSSD, so their identity lookups and Kerberos logins point to the new servers. Applications that bind directly to OpenLDAP need new bind DNs, search bases and credentials, and any that expect the old group schema may need changes. Sudo and HBAC rules do not follow automatically, so access on each host group must be rebuilt and tested before the old directory is switched off. Keep a rollback path for clients until each host group has passed its login and access checks. Ask your team to list every system that reads from the directory before scheduling cutover.

Do we need to consider user private groups during the migration?

Yes, because FreeIPA creates a user private group for each user by default, which can differ from how your OpenLDAP groups were built. Group IDs, primary groups and file ownership on existing systems can change if the mapping is not planned. Decide early whether migrated users keep their current primary groups or move to FreeIPA's default model, and check the effect on shared directories and application configuration. Test this on the copy with real file permissions, not only with group listings.

What drives the cost and timeline of this migration?

The main drivers are the size and shape of your OpenLDAP schema, how many custom object classes and attributes need mapping, the number of sudo and HBAC rules to rebuild by hand, how many clients and applications depend on the directory, and how many password paths your users need. Compliance evidence, such as documented change records and test results, adds effort when auditors will review the cutover. Costs are one-time for the migration itself and recurring only if you retain support or testing services afterward. No public figures are supplied for this work, so request a quote based on a written scope that lists each of these drivers and the test cycles you expect.

Does DeployOpen provide compliance certification for the migrated directory?

No. DeployOpen can prepare systems, controls and evidence for compliance assessments, such as documented access rules, test records and change logs from the migration. Independent auditors and certification bodies issue any audit report or certification. Ask your assessor early which evidence they expect, so the migration records are captured during the work rather than rebuilt afterward.

What changes for users and administrators after cutover

After cutover, users no longer authenticate by binding to LDAP with a DN and password. On enrolled Linux hosts, SSSD talks to the FreeIPA server, the user obtains a Kerberos ticket from the MIT Kerberos KDC, and single sign-on works from that ticket. Applications that bound directly to the old OpenLDAP tree will need either a Kerberos or LDAP reconfiguration pointed at FreeIPA, or a hard look at whether they still need LDAP at all. Make an inventory of every service that performs simple binds, SASL binds or LDAP searches against the old directory, because those are the systems that break silently when the bind DN, base DN or attribute names change. Users will also see a changed login name pattern if your old uid scheme differed from the one imported.

Group membership moves in a different model. In FreeIPA, every user gets a user private group by default, and the groups you imported keep their membership, but administrators now manage access through FreeIPA groups, host-based access control and sudo rules rather than through LDAP group attributes that applications read directly. Administrators will need to learn the ipa command line and the web UI for user, group and host changes, and they should stop editing the migrated entries with ldapmodify, since that bypasses the plugins that keep FreeIPA consistent. Confirm with your own team which tools they use today for provisioning, because scripts that write to the old tree must be rewritten against the ipa commands or the API.

Migrated passwords are handled separately from the directory import, so do not promise users that their existing password works on the first login until the password migration path has been tested. Client re-enrollment is a planned step, not something that happens automatically: each Linux host needs SSSD configured against the new realm, and the cutover plan should schedule that per host group with a rollback path. Administrators should also expect that sudo rules and HBAC policies do not arrive through migrate-ds and must be re-established by hand, so access checks should be tested with real accounts before users are moved. Record the expected user-visible changes in your change notice, and confirm them on a copy of the directory first.

How DeployOpen scopes and delivers an OpenLDAP to FreeIPA migration

DeployOpen plans, builds and hands over OpenLDAP to FreeIPA migrations inside your own infrastructure, starting from a written scope. We inventory what the directory holds, run ipa migrate-ds against a copy first, and document what has to be moved by hand.

How we scope

Inventory the OpenLDAP schema, object classes and attributes to find what migrate-ds will skip.
List sudo rules and HBAC policies that need manual LDIF migration and assign them to the written scope.
Agree in writing how user private groups, password handling and client re-enrollment will be treated.

How we build

Stand up a FreeIPA test realm and run ipa migrate-ds on a copy of the source directory.
Compare migrated users, groups and memberships against the source and record every difference found.
Script the manual sudo and HBAC steps so they can be repeated before the production cutover.

How we hand over

Deliver the written migration runbook, mapping tables, test results and the list of items moved by hand.
Walk your administrators through the cutover steps, rollback plan and post-migration checks.
Document the ignored attributes and object classes so your team can explain each gap later.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask for the scope, the copy-based test plan and the manual migration list in any quote you receive.

Migrate from OpenLDAP to FreeIPA with ipa migrate-ds