Migrate from Microsoft AD to FreeIPA for Linux

How to migrate from Microsoft Active Directory to FreeIPA for Linux hosts

The move from Microsoft Active Directory to FreeIPA for Linux hosts is staged. Most teams keep Linux servers joined to AD while they build the FreeIPA topology, set up a cross-forest trust so both directories can authenticate users during the transition, and then move hosts one group at a time. The work is driven by host policy and client configuration more than by user data, because the hard part is reproducing who can log in to which machine, who can run which commands with sudo, and how SSSD on each client resolves identities. FreeIPA is a Linux identity service built from 389 Directory Server, MIT Kerberos, Dogtag and SSSD on clients. It is not a Windows domain replacement, so Windows clients, Group Policy and Windows-side file access stay with AD unless you plan those separately. The work is usually done by platform or identity engineers who already understand Linux PAM, Kerberos keytabs, DNS and SSSD configuration. Start by inventorying which hosts are joined to AD, which HBAC and sudo rules they depend on, and which service accounts they use. FreeIPA's ipa migrate-ds command can move users and groups from an LDAP source, but it excludes Kerberos attributes that FreeIPA regenerates, and sudo and HBAC rules need manual migration through LDIF. Confirm that step against the current FreeIPA migration how-to before you plan the cutover.

Plan effort around three areas. First, the FreeIPA deployment itself: the project's deployment recommendations call for at least two to three replicas in each datacenter and dedicated servers, and the cost of those servers, DNS design and PKI scope is largely one-time build work followed by recurring patching and monitoring. Second, client changes on every migrated host, which recur for each new server you onboard. Third, the trust, which you must set up with a DNS domain that does not overlap any AD domain. Ask any partner to confirm in writing how many hosts, applications and sudo rule sets are in scope, which AD services remain, and how rollback works on each host group. Do not cut the trust until every Linux host authenticates against FreeIPA, every sudo and HBAC rule has been tested, and you have a verified backup. FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so rehearse restores in a lab before relying on them. Treat the final trust removal as a deliberate decision, with a documented owner for any remaining Windows dependency.

Which Active Directory capabilities map to FreeIPA, and which need rework

This table maps the AD capabilities that Linux estates depend on to their FreeIPA equivalents, with each row marked clean, needs rework or gap. Read the status column first, then the notes, to see what must be rebuilt during the move. The main takeaway is that Linux login, sudo and host access move well, while Group Policy and Windows client management stay outside FreeIPA.

Capability	FreeIPA equivalent	Status	What to check during migration
Kerberos single sign-on	MIT Kerberos KDC inside FreeIPA	Clean	Confirm that Linux clients obtain tickets from the IPA realm and that service principals are recreated, since Kerberos attributes are regenerated rather than copied.
LDAP user and group lookup	389 Directory Server, read through SSSD on clients	Clean	Repoint SSSD domains and confirm that UID and GID values stay stable for file ownership on existing servers.
Host accounts and enrollment	FreeIPA host objects enrolled with the client installer	Needs rework	Rejoin each Linux host to FreeIPA instead of the AD domain, and retire the old computer objects once the host is verified.
Sudo rules	FreeIPA sudo rules managed centrally	Needs rework	Sudo rules are not migrated automatically, so export them from AD and recreate or convert them through LDIF before cutover.
Host-based access control	FreeIPA HBAC rules	Needs rework	HBAC rules also need manual migration through LDIF. Test each login path, including SSH, console and service accounts, before removing AD rules.
Certificates	Dogtag certificate authority inside FreeIPA	Needs rework	Plan how existing AD-issued certificates, auto-enrollment and CRL distribution will be replaced. Confirm the first server's role in renewal and CRL publication.
Two-factor authentication	HOTP and TOTP tokens, with OTP checks proxied to an existing RADIUS server	Needs rework	Confirm which MFA products sit in front of Linux logins today and whether they accept FreeIPA OTP or RADIUS proxy flows.
DNS and service discovery	Optional ISC BIND DNS integrated with FreeIPA	Needs rework	Decide whether AD DNS records move, and set at least two DNS servers in each client resolv.conf as the deployment recommendations advise.
Windows domain trust	Cross-forest trust with AD through Samba components	Needs rework	The IPA DNS domain must not overlap any AD forest domain. Run the trust during transition, then decide when to cut it.
Group Policy and Windows client management	Not provided by FreeIPA	Gap	Keep these with AD or move them to another tool. FreeIPA does not manage Windows clients or Group Policy objects.

What data moves, what FreeIPA regenerates, and what you rebuild by hand

Moving Linux identity to FreeIPA is not a single export and import. Some objects migrate with a command, some must be rewritten by hand, and some are regenerated by FreeIPA on install. Use the cards below to inventory each object class before you cut any host over, and test every user path, because passwords and Kerberos keys do not move as ordinary attributes.

Users and groups with migrate-ds

The ipa migrate-ds command imports users and groups from an LDAP source into FreeIPA and excludes Kerberos attributes, which FreeIPA regenerates for its own realm. Run it against a copy of the directory first and compare user counts, group membership and attribute values with the source. Expect that a migrated account does not authenticate until its credentials are reset or otherwise re-established, so plan that step with the help desk and check each login path separately.

Sudo and HBAC rules by hand

Sudo rules and host-based access control (HBAC) rules do not come across through the user migration and must be exported from the source and rewritten as LDIF for FreeIPA. Inventory every sudoers entry and access rule that gates a server, including emergency and service accounts. Recreate them as rules scoped to host groups, then test each rule on a non-production host to confirm that the intended users are allowed and everyone else is denied.

Host entries and SSSD enrollment

Each Linux server needs a host entry in FreeIPA and an enrolled SSSD client that uses the FreeIPA domain for identity and authentication. Decide which hosts are enrolled first, and note that a host still joined to AD through its own SSSD or Winbind configuration must be unjoined before its identity source changes. Verify name resolution, Kerberos ticket issuance and group lookups on a canary host before enrolling the rest of the fleet.

OTP tokens and RADIUS proxying

FreeIPA supports HOTP and TOTP tokens, including software tokens and hardware tokens such as YubiKeys, and can proxy one-time password checks to an existing RADIUS server. Tokens do not transfer from an AD-side or third-party MFA system as usable seeds unless the source vendor supports an export, so confirm that with the vendor. Keep the RADIUS proxy path during transition for services that still depend on it, and re-enroll users whose tokens cannot move.

Certificates from the Dogtag authority

FreeIPA's integrated Dogtag certificate authority issues host and service certificates, and by default the first server handles renewal and certificate revocation list publication. Inventory the certificates that existing Linux services use, decide which ones FreeIPA will reissue, and plan how clients trust the new CA chain. Restoring an outdated backup into an active replica topology can break replication, so do not treat certificate state as something to recover from an old snapshot.

DNS zones and resolver settings

FreeIPA can serve DNS zones through its optional integrated DNS, and clients should list at least two DNS servers in resolv.conf. Decide which zones FreeIPA authoritatively serves and which remain on AD DNS during coexistence, because overlapping namespaces cause resolution faults that look like authentication failures. Check service records and reverse zones before you change the resolver settings on any server.

The migration sequence from inventory to decommissioning AD for Linux

This sequence moves Linux authentication, sudo and host access off direct Active Directory joins and onto FreeIPA in controlled stages, so each host is verified before the next one moves and the AD dependency ends only when nothing Linux still needs it.

Inventory every Linux host and its dependencies
The identity team, working with system owners, lists every Linux and UNIX host that is joined to AD, including its join method (SSSD, Winbind, Centrify-style agents or PAM and LDAP configurations), the sudoers entries and access rules that depend on AD groups, the service accounts that authenticate with Kerberos keytabs, and each application that binds to LDAP or expects Kerberos tickets. Each entry records the owner, the business function and the access path. The output is a host inventory and a dependency map. The step is done when system owners have confirmed the list for their estates and no host is left without an owner or an identified access path.
Build and test a FreeIPA pilot topology
Engineers build a FreeIPA topology to the vendor's deployment recommendations: at least two to three replicas in each datacenter, no more than four replication agreements per replica, dedicated servers without other applications, and at least two DNS servers in each client's resolv.conf. Because the IPA domain must use a DNS name that does not overlap with any AD forest domain, the team confirms the naming before installation. A test host group is enrolled, and logins, Kerberos ticket issuance, sudo and host-based access rules are exercised. The output is a tested pilot with documented results and a rollback procedure for the test group. Confirm the sizing and any PKI or DNS placement with the FreeIPA documentation before commissioning servers.
Establish the trust and move hosts in parallel
The cross-forest trust with the AD forest is established and tested, and users and groups are brought into FreeIPA using the migration tooling, with Kerberos attributes regenerated rather than copied. Sudo and HBAC rules are translated by hand from the inventory, since the migration how-to requires manual migration for them. SSSD clients are then moved host by host, starting with the least critical systems, with the previous configuration kept for fallback on each host. Each change is logged with the host name, date, the test performed and the result. The output is a host migration log and a reconciled user and group list. Keep a host in its prior state if any login, sudo or service check fails.
Cut over remaining hosts and rebuild access rules
Teams move the remaining hosts to FreeIPA enrollment, and the access matrix is rebuilt in FreeIPA as host groups, HBAC rules and sudo rules that match the signed-off design, not a copy of legacy AD group membership. Service accounts are reissued keytabs from FreeIPA and application bindings are repointed and tested. Access owners review the rebuilt matrix against the inventory and sign it off. The output is a signed-off access matrix and a cutover record showing that every host in the inventory authenticates through FreeIPA. Hosts that still depend on AD group membership are listed as exceptions with an owner and a closure date agreed in writing.
Retire direct AD joins and decommission the trust
Once every host in the inventory is verified against FreeIPA, the team removes the Linux computer objects from AD, disables any leftover AD-bound SSSD or Winbind configuration, and checks that no service still sends requests to AD for Linux identity. The trust is kept only if Windows systems or AD-integrated applications still need to reach FreeIPA resources, and that need is recorded with its owner. Before removing the trust, the team confirms with the FreeIPA backup documentation that a current backup exists and that replication is healthy across replicas. The output is a decommission record listing removed objects, retained trusts and the final backup reference.

When to cut the trust and run FreeIPA as the only Linux directory

Cut the cross-forest trust only when FreeIPA can serve every Linux identity need without falling back to Active Directory. In practice that means every Linux host authenticates against FreeIPA, every sudo and HBAC rule has been rebuilt and tested on FreeIPA, service accounts have moved, and no Windows user still needs access to Linux resources through the trust. Confirm each condition against your own estate rather than assuming it. Inventory every host, application and scheduled job that binds to AD, including Kerberos service principals, LDAP bind accounts, NFS or file access paths and any Windows-hosted application that authenticates Linux users. A trust that looks unused can still carry a quiet dependency that surfaces only after removal, so run the checks in a non-production window first and keep the trust available until the last dependency is proven gone.

Before you remove any FreeIPA node, treat backup and replica roles as the first control. FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restores should be planned as recovery events with the replication topology reviewed afterward, not as routine rollbacks. Also confirm which server holds the CA role. The first server handles certificate renewal and CRL publication by default, so decommissioning or demoting that server without moving those responsibilities leaves certificate lifecycle work with no owner. Record the output of your topology and replica checks, confirm that at least one replica per datacenter that runs PKI or DNS remains after removal, and take a full backup before any change to the topology. Use the FreeIPA backup and restore page as the reference for your runbook, and have the restore procedure tested before the trust is cut.

What drives the cost and duration of an AD to FreeIPA move

This table lists the factors that change the effort of moving Linux identity from Active Directory to FreeIPA, why each one matters, and how to keep it contained. Use it to shape a written scope, since most of the cost sits in design, testing and the number of hosts and rules that must be re-created. The main takeaway is that the largest variables are often inventory questions you can answer before requesting a quote.

Driver	Why it changes cost or effort	How to keep it down
Linux hosts and distributions	Each distribution, release and SSSD configuration needs its own enrollment steps, testing and rollback check, so mixed estates multiply test work.	Group hosts into a small number of builds, retire unsupported releases first and confirm which SSSD versions each build ships.
sudo and HBAC rules	AD-based sudo and host access rules must be re-expressed as FreeIPA rules, and the FreeIPA migration how-to says these need manual migration through LDIF.	Export the rules, remove stale or duplicate entries and map each rule to a host group before any design work starts.
Service accounts and Kerberos-dependent applications	Each service principal, keytab and application that authenticates through Kerberos or LDAP bind must be found, re-pointed and tested.	Build a dependency inventory from keytab files, application configs and bind logs, and agree which applications move in the first wave.
Datacenters and replicas	FreeIPA deployment recommendations advise at least two to three replicas per datacenter, with a limit of four replication agreements per replica, so topology size drives design and operations.	Fix the replica count per site in the design, keep servers dedicated and confirm the number of sites in the written scope.
AD forests and trusts	A cross-forest trust requires a DNS domain for the IPA domain that does not overlap any AD domain, and each trusted forest adds testing and policy decisions.	Count forests and trust paths early, decide whether trust is temporary, and document which forests keep their own authentication.
Two-factor and certificate scope	Enrolling OTP tokens, proxying to an existing RADIUS server and issuing certificates from the integrated Dogtag CA each add setup, key ceremony and client work.	Limit the first phase to login paths that need MFA or certificates, and confirm whether an existing PKI will be kept as the signing authority.
Testing and change windows	Business rules on test coverage, approval steps and maintenance windows decide how many cutover rounds are possible and how long parallel running lasts.	State the required test evidence, the change calendar and the rollback criteria in the scope, and ask who signs off each wave.
One-time work (design, migration, training)	Design, rule and account migration, client rollout, testing and staff training are paid once, though they can extend across several waves.	Ask for a fixed-scope breakdown by phase so each deliverable and acceptance test is priced separately.
Recurring work (operations, patching, backups)	Replica operations, OS and FreeIPA patching, ipa-backup routines and support retainers continue after cutover and scale with the topology.	Ask which tasks the retainer covers, how backups are tested with ipa-restore and what staffing your team keeps in-house.

What usually goes wrong in an AD to FreeIPA migration, and how to prevent it

Most AD to FreeIPA problems come from a few places: the DNS namespace chosen for the new domain, backups and replica state, client configuration during the transition, and rules that did not survive the move. Each card below names one failure and the check that prevents it before a cutover window.

Overlapping DNS domains block the trust

A cross-forest trust needs the IPA domain to use a DNS name that does not overlap with any domain in the AD forest. Teams often reuse the parent domain name for convenience, and the trust setup then fails or produces ambiguous name resolution. Before installing anything, list every AD domain and child domain, and pick a separate DNS namespace for FreeIPA. Confirm the choice against the Trusts page before you plan the DNS zones.

Restoring an outdated backup into live replicas

Restoring an old ipa-restore backup into an active replica topology can break replication, because the directory state on the restored server no longer matches its peers. The first server also handles certificate renewal and CRL publication by default, so a stale restore can affect certificate operations too. Test restores in an isolated copy of the topology, document which server is the renewal master, and confirm replication health before and after every restore.

Clients falling back to AD mid-migration

A Linux host whose SSSD configuration still points at Active Directory, or lists both directories without clear precedence, can start logging users in against the wrong source during the transition. Users then see different UIDs, group memberships or password results depending on which host they reach. Move one pilot host at a time, review sssd.conf on each host for the domain and search base in use, and confirm the result with id and a test login before moving the next group of servers.

Sudo and HBAC rules missed in LDIF

The migration tooling moves users and groups, but sudo and HBAC rules need manual migration through LDIF. Teams often migrate accounts successfully and discover days later that an administrator can no longer run sudo on a production host, or that a service account can reach a server it should not. Build an inventory of every sudoers entry and access rule per host group, recreate them as FreeIPA rules, and test privileged and denied paths on staging hosts.

Applications expecting old principals or attributes

Applications that authenticate with Kerberos service principals or read specific LDAP attributes may break when FreeIPA issues different principal names, realms or attribute values. Some legacy software also hardcodes an AD-style base DN or keytab location. Inventory each application's keytab, bind DN, search filter and attribute reads, then test each one against FreeIPA in a non-production environment and record which applications need configuration changes.

Cutting the trust before Windows dependencies are checked

Removing the trust or disabling AD-side accounts before every Windows-side dependency has been checked can stop file shares, print services, Windows-hosted applications and scheduled tasks that still authenticate through AD. Map which Windows systems, services and users still rely on the trust, confirm each one has a replacement or a documented exception, and keep a rollback path until the monitoring period has passed without authentication failures.

How the move changes for a Linux-only estate, a mixed estate and a multi-site estate

Illustrative scenario: a company runs a few hundred Linux servers joined directly to Active Directory through SSSD or a similar client, with only a small set of Windows workstations left for a single application. In this shape the trust is a bridge, not a destination. FreeIPA takes over Linux identity, and the trust exists only long enough to let users and groups move without a password reset wave.

Trust decision: Plan to cut the cross-forest trust once every host and service authenticates against FreeIPA. Set a removal date in the change plan so the trust does not become permanent by default.
Replica design: Two or three replicas in the primary datacenter are usually enough for a single site, with no more than four replication agreements per replica, as the FreeIPA deployment recommendations advise.
Client change pattern: Move hosts in waves, reconfiguring SSSD to point at FreeIPA, then rebuild sudo and HBAC rules from LDIF because they do not migrate automatically.
Main risk: Hosts that still resolve users through AD during the wave can show mixed identities. Confirm the ID source for each host before its wave closes.

Before cutting the trust, confirm that no remaining Windows-dependent service relies on it.

Illustrative scenario: three datacenters, each hosting Linux workloads, with a shared AD forest that links them. Here the directory layout must be designed before the first host moves, because replica placement, DNS and replication decide whether a site keeps working when a link fails.

Trust decision: Decide early whether the trust is temporary or permanent for each site. Sites that cut over at different times need the trust for the longest-running site.
Replica design: The deployment recommendations advise at least two to three replicas in each datacenter. Place at least one replica per datacenter that runs PKI or DNS, and keep those servers dedicated to identity services.
Client change pattern: Point each client at at least two DNS servers in its resolv.conf, and move sites in sequence so one site's failure does not block another's logins.
Main risk: Restoring an outdated backup into an active replica topology can break replication. Run ipa-backup on a schedule and test restores in a separate environment before any production restore.

Confirm the certificate renewal and CRL publication owner, since the first server handles these by default, and write that choice into the runbook.

Questions buyers ask before moving Linux identity to FreeIPA

What does a migration from direct AD joins to FreeIPA cost?

Cost is set by scope, not by a fixed figure, so no single number applies across estates. The main drivers are the number of Linux hosts and their distributions, how many sudo and host-based access control rules must be rebuilt by hand, the number of applications that authenticate through the directory, and whether the trust stays in place during a long transition. Costs fall into one-time work (design, FreeIPA deployment, client changes, testing and cutover) and recurring work (patching, replica operations, backups and staff time). Ask any provider for a fixed-scope quote that lists these items separately, and confirm which of your internal staff hours it assumes.

How long does moving Linux servers off AD joins take?

Duration depends on the size and variety of your Linux estate, how many sudo and HBAC rules need manual migration, how many services depend on current Kerberos or LDAP bindings, and how many change windows your organization allows. FreeIPA's migration documentation notes that sudo and HBAC rules must be migrated manually through LDIF, which is often the longest step for estates with many rule sets. Plan for a pilot group of hosts before any production wave, and confirm the timeline against your own change calendar and host inventory rather than a generic figure.

What must our internal team provide for the migration?

The project needs administrators who know your Active Directory forest and your Linux fleet, because the trust design depends on both. In practice that means AD administrators to confirm DNS domain layout, group membership and the trust configuration, Linux administrators to inventory hosts and test SSSD changes, and application owners to confirm how each service authenticates. Your organization also needs a change approval path for each wave and a written test plan with rollback steps. Confirm named owners and available hours for each role before a scope is agreed.

Can our internal team run this migration without an outside partner?

Many teams with experienced directory and Linux administrators can run parts of the work alone, particularly host inventory, pilot hosts and routine sudo rule cleanup. Tasks that tend to need specialist review include the DNS design (the IPA domain must not overlap with any AD domain), replication topology across datacenters, the backup and restore procedure, and the cutover from the trust. An external partner can plan, implement, test and document these parts under a fixed-scope agreement, and can hand over runbooks so your staff keep ownership afterwards. Decide which parts you will keep in-house before asking for a quote.

Can FreeIPA replace Active Directory for Windows clients?

No. FreeIPA is an identity and authentication solution for Linux and UNIX networks, and it does not act as an Active Directory domain for Windows clients, Group Policy or Windows domain services. Its trust with AD lets FreeIPA users reach Windows resources, but Windows workstations and Windows servers still need Active Directory or another Windows-compatible directory. If your estate still has Windows domain members, plan to keep AD for them and treat FreeIPA as the Linux identity layer. Confirm which Windows services depend on your current domain before scoping any change.

Can the cross-forest trust with AD stay in place indefinitely?

A trust can remain as a long-term coexistence design if you still need Windows resources and Linux users to work together, but it should be a deliberate choice rather than a leftover. Each trust adds dependencies on AD availability, DNS and the Samba components that FreeIPA uses for the trust, so you should document what breaks if AD is unavailable. Before cutting the trust, confirm that every Linux service authenticates against FreeIPA, that no sudo or access rules still reference AD groups, and that restore procedures for FreeIPA have been tested, since an outdated backup restored into an active replica topology can break replication.

What should we ask for in a fixed-scope quote?

Ask for a written scope that names the hosts, distributions and applications in each wave, plus the number of FreeIPA replicas per datacenter and where they run. The quote should list deliverables such as the DNS and trust design, sudo and HBAC rule migration, SSSD client configuration, the test plan, the cutover runbook, backup and restore testing, and documentation. It should state which items are one-time and which are recurring, what your staff must provide, the acceptance criteria for each wave, and how changes to scope are handled. Ask how timelines are set and what assumptions they depend on.

How DeployOpen scopes, runs and supports an AD to FreeIPA migration

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted FreeIPA inside your own infrastructure, including the Linux identity move from Microsoft Active Directory. Work starts from a written scope that covers the trust, host access rules, SSSD client changes and the decision on when to retire the trust.

How we scope

Inventory which Linux hosts join AD directly and which services authenticate against them
Agree in writing whether the trust stays during transition and when it is cut
Confirm the DNS namespace for the IPA domain does not overlap any AD forest domain

How we build

Deploy FreeIPA replicas per datacenter following the vendor's deployment recommendations
Rebuild host-based access control and sudo rules, migrating the sudo and HBAC content by hand
Move client hosts to SSSD configuration and test logins, sudo and Kerberos tickets per host group

How we hand over

Document the topology, trust settings, rule sets and the client change runbook for your team
Set up ipa-backup schedules and a tested restore procedure that respects replication state
Deliver a cutover checklist covering trust removal, rollback steps and sign-off criteria

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer
Confirm with us the scope of post-cutover support, patching windows and CVE response before signing

Migrate Linux identity from Microsoft Active Directory to FreeIPA