FreeIPA migration from OpenLDAP or NIS

What a FreeIPA migration involves

A FreeIPA migration moves identities from a source directory into a new FreeIPA domain, and the source type determines how much of the work the tooling does for you. The three common sources are OpenLDAP or another LDAP server, NIS, and another FreeIPA domain. Teams usually start because of one of four triggers: consolidating several directories into one, retiring an aging LDAP server, moving off NIS, or merging or splitting FreeIPA domains. Each trigger implies a different scope for users, groups, hosts and policy, so name the trigger in writing before choosing a method.

What the tooling moves automatically. For LDAP sources, the ipa migrate-ds command imports users and groups, and it leaves out Kerberos attributes because FreeIPA regenerates them. Between two FreeIPA deployments, ipa-migrate moves users, groups, certificates, hosts, services, DNS records, OTP tokens and policies over LDAP. Confirm the exact object list for your FreeIPA version against the migration documentation before you plan cutover, since object coverage is the first thing to check against your inventory.

What needs manual migration. Sudo and HBAC rules are not carried over by migrate-ds and must be exported from the source and rebuilt through LDIF. Treat this as a rule-by-rule review, not a file copy: each rule's host scope, user scope and command list should be re-tested on a non-production host. NIS sources add a further step, because netgroups and automount maps must be mapped to FreeIPA objects by hand.

The plain answer. Teams with strong LDAP and Kerberos skills and a small, well-documented source can often migrate in-house, provided they run a full test migration first. Multi-site estates, sources with heavy custom policy, and cutovers with no tolerance for login failures usually go to a partner, because the risk sits in rule translation and in the password and Kerberos behavior during the switch, not in the import command itself.

What the work includes

A fixed-scope migration into FreeIPA usually breaks into the packages below. Each one ends in a named deliverable you keep, so you can check progress and decide whether to run the next phase yourself or hand it to a partner.

Source inventory and attribute mapping

We catalog the source directory, NIS maps or existing FreeIPA domain: users, groups, hosts, service principals, sudo rules and HBAC rules, and record where each attribute lands in the FreeIPA schema. Check that every login name, UID and GID range is accounted for before any data moves. The attribute mapping document is the deliverable you keep.

Test realm build

We stand up a non-production FreeIPA realm on the same FreeIPA version and OS family planned for production, then load a copy of the source data into it. This exposes naming conflicts, DNS domain problems and ID range overlaps while they are still cheap to fix. The test realm build record and its configuration are delivered to you.

Identity and group migration

Users and groups are moved with ipa migrate-ds from LDAP sources or with ipa-migrate from another FreeIPA deployment, with Kerberos attributes left for FreeIPA to regenerate. We confirm object counts, group membership and UID preservation against the source. The reconciliation report lists every object that moved, changed or was skipped, with the reason.

Manual sudo and HBAC rule moves

Sudo and HBAC rules do not migrate automatically from LDAP sources, so they are exported as LDIF, rewritten against FreeIPA host and group objects, and reloaded. Each rule is tested against representative hosts before production. The rule translation worksheet, showing source rule to FreeIPA rule and any rule that was retired, is delivered to you.

Password migration on first login

Passwords stored in the source system cannot always be transferred in a usable form, so users set or confirm credentials on first login and the old hashes are retired. The rollout plan must cover users who never log in during the window, service accounts and any tokens that need reissue. The password cutover plan and the user communication template are delivered to you.

Client re-enrollment and SSSD changes

Each client is moved from its old LDAP, NIS or client configuration to FreeIPA enrollment with SSSD, and its DNS resolver settings are checked against the FreeIPA servers. Hosts are grouped by OS version and role so that a failed batch is easy to isolate. The client enrollment runbook and per-host status list are delivered to you.

Cutover and rollback

The production cutover sequence covers the freeze window, final incremental data load, DNS and client switch, and verification of login paths. A rollback procedure defines the point of no return and how to restore the source directory or prior clients if a check fails. The cutover checklist and the rollback procedure are delivered to you before the window opens.

Handover and operations documentation

The engagement ends with a handover to your operations team covering replica layout, backup and restore steps, certificate renewal checks and the list of open items. Ask for a walkthrough of each runbook and a named list of what is in scope for post-go-live support. The handover pack, including the migration runbook and open items register, is the final deliverable.

What drives cost and duration

This table lists the factors that change cost and effort in a FreeIPA migration and how to limit each one, and because no fixed durations are published, ask for estimates tied to your written scope.

Driver	Why it matters	How to keep it down
User and group objects	Each object must be mapped, loaded and checked, and duplicate or orphaned accounts and empty groups add review work.	Clean up stale accounts and unused groups in the source, and agree the in-scope object set in writing.
Source schema and custom attributes	Custom object classes and attributes must be mapped to FreeIPA schema, and each extra attribute adds design, testing and documentation.	Inventory attributes early, drop unused ones and document a mapping for each attribute you keep.
Sudo and HBAC rules	migrate-ds does not move these rules, so each one is converted by hand through LDIF and tested against target hosts.	Count rules first, merge duplicates and retire rules that no longer match how access is granted.
Hosts and SSSD clients	Every enrolled host must be re-pointed to the new domain, with its SSSD settings and DNS resolver checked.	Group hosts by OS and role so one change set covers each group, and confirm each client has at least two DNS servers.
Password storage and first login	The source password format and any login-on-first-use requirement decide how many users must reset credentials and need support.	Confirm the source hash format early, then plan the first-login window and a help path for users who miss it.
FreeIPA domains in an ipa-migrate move	Each source domain adds its own realm, DNS, policy and trust mapping, and ipa-migrate moves objects between two deployments over LDAP.	Limit each run to one source domain, and document which objects each domain owns before starting.
NIS maps in use	Each map in use, such as passwd, group or netgroup, is a separate source to extract and reconcile, and netgroups must be re-expressed as FreeIPA policy.	List every map in use before scoping, and confirm which maps the business still depends on.
Environments (test, staging, production)	Each environment needs its own dry run, sign-off and rollback check, so effort grows with each environment added.	Run the full migration in test first, then reuse the same scripts and LDIF in each later environment.
Datacenters in the target topology	Each datacenter adds replicas, replication agreements and client re-pointing, and deployment guidance advises two to three replicas per datacenter.	Confirm the target replica count per site early, and align the migrated server set with the topology design.

Migration phases and outputs

The sequence moves identities into a tested FreeIPA realm in stages, so each phase produces a checkpoint before any production user or host depends on the new domain.

Audit the source directory
Inventory users, groups, nested memberships, password hashes or bind methods, sudo rules, access rules, NIS maps and host entries in OpenLDAP, NIS or the source FreeIPA domain. The output is a source audit that lists each object class, its volume and the attributes that FreeIPA will regenerate, such as Kerberos keys, so the team knows what migrates and what is rebuilt.
Design the target realm
Define the realm name, the DNS domain, the replica topology per the deployment recommendations, the certificate authority and DNS choices, and the ID ranges. The output is a signed-off design document that a reviewer can check against the recommended replica count and the rule that the IPA domain must not overlap with any AD domain if a trust is planned.
Run a pilot migration into a test realm
Build a test realm on the agreed design and run ipa migrate-ds against a copy of the source data, or ipa-migrate between FreeIPA deployments where that is the source. The output is a migration log with per-object results, plus a list of failed or skipped entries that is reviewed line by line before the next phase.
Reconcile users, groups and rules
Compare the pilot results with the source audit and move sudo and HBAC rules by hand from LDIF, since these are not carried by the user and group migration. The output is a reconciliation sheet showing each user, group and rule as migrated, changed or retired, with sign-off from the owners of the access policy.
Pilot clients against the test realm
Enroll a small set of Linux clients with SSSD, test logins, password behavior on first login, sudo and access rules, and DNS resolution through the planned resolver list. The output is a client test record that confirms each login path works and documents any client change needed before production.
Cut over to production with a backup first
Take a full ipa-backup on the current production servers before any change, store it off the servers, and then switch the agreed users, hosts and clients to the new realm in a planned window. The output is a verified backup and a dated cutover record. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so rollback steps must be written and rehearsed in the test realm before this phase starts.
Support the realm through hypercare
Watch authentication failures, replication status, certificate renewal on the first server and client enrollment after cutover, and fix defects against the reconciliation sheet. The output is a closed issue list and a handover to the operations team that states the rollback position for each replica.

What stays in-house and what to outsource

The table splits the migration into work parts and shows who usually owns each part and which skills it needs, so you can see where a partner adds the most value and where your own staff must stay in control.

Work part	Usual owner	Skills needed
Source directory ownership and data sign-off	In-house: directory owners confirm which users, groups and hosts move and approve the data	LDAP schema and ACL knowledge, knowledge of your HR and account lifecycle
Application owners testing logins	In-house: application owners test sign-in, service accounts and group-based access	Application authentication knowledge, test plans for each service
Migration scripting and LDIF conversion of sudo and HBAC rules	Often outsourced: a partner writes the conversion and runs test imports, with in-house review	LDAP schema and ACL knowledge, Linux configuration management, FreeIPA rule model
Kerberos and certificate authority decisions	Shared: in-house sets policy and realm naming, partner recommends and configures the KDC and CA	Kerberos and SSSD, PKI basics, DNS for the realm
Cutover execution across many clients	Shared: partner plans waves and rollback, in-house owns change windows and client access	SSSD client configuration, Linux configuration management, change management
Password migration on first login	Shared: in-house confirms the password policy and user communication, partner tests the first-login flow	Kerberos and SSSD, change management, directory knowledge
Post-cutover operations	In-house: operations staff run replicas, backups, renewals and access reviews after go-live	Kerberos and SSSD, PKI basics, change management, backup and restore practice

What usually goes wrong

Most FreeIPA migrations stall at the same few points, usually after the data has already moved. Each card names a failure, the check that catches it early, and the step that keeps it from reaching users.

Undocumented schema extensions

Custom object classes and attributes in the source directory often have no owner and no written definition, so the import fails or drops them partway through. Diff the source schema against what FreeIPA expects before the first ipa migrate-ds run, and decide per attribute whether it is mapped, moved to a custom attribute in FreeIPA, or retired.

Kerberos attributes that must regenerate

Kerberos keys and related attributes are excluded from migrate-ds because FreeIPA regenerates them, so migrated users have no working Kerberos identity until that step runs. Agree with stakeholders that Kerberos-dependent logins will not work on day one, and confirm the regeneration and first-login steps in your own test environment.

Password migration timing

Passwords move on first successful login rather than at import, so accounts that have not signed in yet can look broken after cutover. Build a login test matrix covering new, dormant and service accounts, and confirm how each password path behaves with your source directory and client OS versions before users are moved.

Sudo and HBAC rules dropped

Sudo and HBAC rules are not carried over by migrate-ds and need manual LDIF moves, so rules can be silently absent or replaced by a broad allow_all. Export every source rule into a reviewed inventory, recreate them in FreeIPA, and test each host group against the rule set before removing the old policy.

Clients still pointing at the old source

Hosts, services and applications that still bind to the legacy LDAP server or NIS maps keep authenticating against stale data after the cutover. Roll out SSSD enrollment in stages by host group, track which clients still use the old source, and disable the old source only after the last group is confirmed.

Outdated backup restored into replicas

Restoring an older ipa-backup into a live replica topology can break replication and reintroduce stale identities. Keep the restore procedure rehearsed on a copy of the topology, and take a fresh backup of the migrated state before any cutover so a rollback point exists.

DNS and resolv.conf left unchanged

Clients that resolve the old server names or hold a single DNS entry keep failing to find the FreeIPA servers, even when the directory itself is healthy. Confirm that records for each replica and service exist, that clients list at least two DNS servers in resolv.conf, and that the change is part of the staged client rollout.

How the work differs by starting point

Migrating from OpenLDAP or another LDAP server uses the ipa migrate-ds command, which copies users and groups but excludes Kerberos attributes that FreeIPA regenerates. Sudo and HBAC rules move by hand through LDIF, so their volume drives much of the effort.

Schema mapping: Compare your source object classes and attributes with the FreeIPA schema and list every custom attribute that needs a target.
Password timing: Confirm how passwords are carried over and when users must authenticate against the new Kerberos keys, since first-login behavior affects the cutover plan.
Rule inventory: Count the sudo and HBAC rules in the source and confirm who will rewrite them in LDIF.
Group and ID handling: Confirm how UID and GID values will be preserved so file ownership on existing hosts does not break.
Cutover window: Confirm which clients still authenticate against the old directory during the transition.

What you need to provide

Before scoping starts, the client confirms the inputs below, each with a named owner. Read access to the source directory and a schema export comes from the directory team that runs OpenLDAP or the other LDAP server, or the NIS administrators. Without the schema, the migration team cannot map attributes such as uid, gidNumber and sshPublicKey to FreeIPA objects, and the ipa migrate-ds mapping is guesswork. The sudo and HBAC rule list comes from the security or platform owner of each rule set, along with the people who approve changes to them. These rules are not moved by the users and groups migration, so someone must name every rule that matters and confirm which hosts it covers. Rules nobody owns are usually the ones that stop logins after cutover.

Host and client inventory with OS versions comes from the server team, covering every enrolled Linux and UNIX host, its operating system release and the SSSD version it runs. Hosts that will not enroll, and hosts still on NIS, must be flagged early. The DNS and time plan is owned by the network team and the infrastructure lead, who decide the realm's DNS zone, the resolvers each client uses and the NTP sources, because Kerberos fails when clocks drift. The named business owner for login sign-off should be an accountable person in the business who can confirm that the migrated users, groups and access rules match policy. The change window and rollback authority belong to the change advisory board and an engineer with authority to stop the cutover. The test environment is owned by the platform team and must mirror the production client mix.

Finally, the client decides the target realm name and DNS domain. The realm should be decided before scoping, because it is hard to change once hosts and services are enrolled, and the DNS domain must not overlap any Active Directory domain if a trust is planned later. If any item is late, scope moves. Late directory access or a missing schema delays the mapping work. Missing sudo and HBAC owners push rule migration into a later phase. Unknown hosts extend client enrollment and the cutover plan. Confirm each owner and date in writing before the fixed-scope quote is finalized, since the quote follows directly from these inputs.

Frequently asked questions

Can ipa migrate-ds move all our users, groups and access rules?

No. ipa migrate-ds moves users and groups from other LDAP servers, but it excludes Kerberos attributes that FreeIPA regenerates. Sudo and HBAC rules need a manual move through LDIF, so plan that work as a separate step. Each rule has to be checked against FreeIPA's model and the hosts it applies to. Ask the partner to inventory your sudo and access rules first, so the migration scope is written down before any data moves.

Do user passwords migrate directly into FreeIPA on first login?

Passwords are handled on first login, and the migration plan has to account for that step. Whether a given password carries over depends on your source directory and how it stores credentials, so the behavior must be confirmed for your source. Test it with a few accounts in a non-production environment before cutover. Also plan a reset path for any users whose credentials do not carry over, and ask for the test results in the written plan.

How long does an OpenLDAP or NIS migration into FreeIPA take?

No duration can be given without reviewing your environment. The main drivers are the number of users, groups and hosts, how many sudo and HBAC rules must be moved by hand, how clean the source data is, and how many clients must be re-pointed to FreeIPA. Ask for a written estimate that lists each phase, the test passes, the cutover window and the assumptions behind them. A fixed-scope agreement should state these in writing before work begins.

Can our own team run a FreeIPA migration without outside help?

Yes, if your team has Linux identity skills and time to test. FreeIPA is licensed under GPL-3.0-or-later and has no license fee, so the decision turns on skills, staff time and risk. The work covers LDAP data mapping, Kerberos, SSSD client changes and tested backups. Your team will also need to provide owners for identity data and access policy, access to the source directory, and approval for change windows. Compare that internal effort against a written scope before deciding.

How does a NIS to FreeIPA migration differ from an LDAP migration?

NIS stores passwd, group and map data in a different structure from an LDAP directory, so the work starts with extracting and mapping those maps into FreeIPA objects. Ask the partner to confirm which NIS maps you use, including netgroups and automount data, and how each will be represented. Confirm whether the LDAP migration tooling applies to your NIS data or whether those steps are manual. Expect extra validation of UID and GID collisions across hosts before estimating effort.

What happens to Linux clients during a FreeIPA cutover?

Clients keep working only if SSSD configuration, DNS settings and Kerberos domain settings change together. Hosts enrolled with the old directory must be re-pointed to FreeIPA, which usually means a planned change window for each host group. Keep at least two DNS servers in each client's resolv.conf, and test logins, sudo and service accounts on a pilot group first. Confirm the rollback path for hosts that fail enrollment, since restoring an outdated backup into an active replica topology can break replication.

How DeployOpen runs FreeIPA migrations

DeployOpen plans and builds FreeIPA migrations inside your own infrastructure, moving identities from OpenLDAP, NIS or another FreeIPA domain under a fixed-scope plan agreed in writing. Each migration is scoped, built, tested, documented and handed over, with ongoing support available as a retainer.

How we scope

We inventory source users, groups, hosts, sudo and HBAC rules before choosing a migration path.
We confirm which source attributes FreeIPA regenerates, such as Kerberos attributes, so nothing is copied blindly.
Engagements are fixed-scope, so deliverables, cutover approach and acceptance tests are agreed in writing first.

How we build

We run ipa migrate-ds against OpenLDAP or other LDAP sources, then review every imported user and group.
Sudo and HBAC rules are moved by hand from LDIF, then tested against login paths on staging hosts.
For FreeIPA-to-FreeIPA moves, ipa-migrate carries users, certificates, OTP tokens and policies over LDAP.

How we hand over

Handover includes migration runbooks, mapping tables from source objects to FreeIPA objects, and a reconciliation report.
Before cutover, we take a backup with ipa-backup and confirm restore steps with your operators.
Your team receives documentation of decisions, rollback points and the open items that remain after cutover.

How we support

Ongoing support, upgrades and testing are available as retainers after cutover, scoped separately from the migration.
Post-cutover checks cover replication health, certificate renewal on the first server, and client authentication.
Release notes such as 4.13.4 are reviewed against your deployment to plan upgrade windows.

FreeIPA migration from OpenLDAP, NIS or another FreeIPA domain