Microsoft AD vs FreeIPA: which to choose

Microsoft Active Directory vs FreeIPA: which fits a Linux-heavy estate

FreeIPA is not an AD domain for Windows clients, so the real choice is between replacing Active Directory for Linux identity or keeping AD and trusting it from FreeIPA. Windows desktops and servers will keep joining an Active Directory domain, and Group Policy will keep governing them, unless that domain is retired or moved to a different directory such as Samba AD. FreeIPA combines 389 Directory Server, MIT Kerberos, the Dogtag certificate system and SSSD on clients, which covers Linux and UNIX identity, Kerberos single sign-on, host-based access control and sudo rules. It can also create a cross-forest trust with an Active Directory domain, so AD users can reach Linux resources without a separate account store. Replacing AD for Linux identity fits when most hosts are Linux, when Linux servers are joined to AD only for Kerberos, sudo or access control, and when the Windows estate is small enough to move elsewhere or shrink. Keeping AD and trusting it fits when Windows clients, file services and Group Policy remain central, and FreeIPA is needed for Linux-side policy. The decision turns on three questions: how much of the estate is Windows, whether Linux hosts depend on AD Kerberos and Group Policy, and whether the team can run a FreeIPA topology with replicas, backups and certificate management. Confirm each question with an inventory before choosing. The trust needs its own planning. The IPA domain must use a DNS domain that does not overlap with any domain in the AD forest, and the FreeIPA deployment recommendations advise at least two to three replicas in each datacenter. Migration of users and groups can use the ipa migrate-ds command, but sudo and HBAC rules need manual migration through LDIF, so budget that effort early. Confirm your AD functional level and Windows Server versions against the FreeIPA Active Directory trust setup guide before committing.

Which option fits each scenario

This table maps common estate types to the better fit between keeping Active Directory and replacing it with FreeIPA for Linux identity. Read each row against your own mix of Windows clients, Linux hosts and Group Policy dependencies, since the reason column shows which requirement tips the decision.

Estate scenario	Better fit	Reason
Mostly Linux servers, no Windows domain dependency	FreeIPA	Kerberos SSO, sudo rules, HBAC and host policy are all managed centrally in one IdM domain, so no AD forest is needed for Linux access.
Linux servers already joined directly to AD	FreeIPA, after a transition	Move hosts to SSSD clients enrolled in FreeIPA, then cut the AD trust once sudo and HBAC rules are migrated by hand.
Windows-heavy estate with a few Linux hosts	Keep AD	Windows clients need AD domain join and Kerberos for Windows logon. A small Linux set can use a FreeIPA trust or AD-integrated SSSD instead of a separate directory.
Desktops managed by AD Group Policy	Keep AD	FreeIPA does not provide Group Policy for Windows desktops, so GPO-driven configuration would need a separate management tool. Confirm which GPO settings you rely on.
Mixed estate during a multi-year transition	Keep AD with a FreeIPA trust	A cross-forest trust lets AD users reach Linux resources while hosts move over in stages. The IPA DNS domain must not overlap any AD domain, so plan naming first.
Linux access driven by sudo and HBAC policy	FreeIPA	Host-based access control and sudo rules live in FreeIPA and apply per host group. Confirm how existing AD-based rules map to them before cutover.
Audit or compliance evidence needed for Linux logins	Depends on scope	FreeIPA centralizes Linux identity and certificates, but Windows event evidence stays in AD. Confirm with your assessor which logs must come from which system.
Dedicated Linux identity team with no Windows administrators	FreeIPA	Without Windows domain expertise on staff, the Linux-first design, Kerberos tooling and replica sizing are the skills to confirm before you commit.

What FreeIPA covers and what it leaves to AD

FreeIPA bundles the directory, Kerberos, certificate and client pieces that Linux estates usually stitch together by hand. It does not replace the Windows side of Active Directory, so each card below marks the condition under which a component matters for the decision.

389 Directory Server as the directory

FreeIPA stores users, groups, hosts and policies in 389 Directory Server, an LDAPv3 directory running multi-master replication. This matters if Linux applications query LDAP directly, because the schema and search behavior change when you move off AD. Check which applications bind to LDAP and whether they expect AD attribute names or POSIX attributes.

MIT Kerberos for single sign-on

The MIT Kerberos KDC gives Linux hosts and services single sign-on through tickets issued by FreeIPA. This is the component that replaces AD's Kerberos role for Linux logins and service principals. Confirm which services need keytabs, how ticket lifetimes are set, and whether any Windows clients still expect the AD KDC.

Dogtag certificate authority

Dogtag issues host and service certificates from an integrated certificate authority, so Linux services can use TLS without a separate PKI product. It matters when AD Certificate Services currently issues the internal certificates. Map each certificate template, renewal process and revocation path before you cut over, and confirm which CA chain your clients trust.

SSSD on Linux clients

SSSD runs on each client and handles identity lookups, caching, offline logins and Kerberos authentication against FreeIPA. It replaces the direct AD joins that many Linux servers use today. Inventory each host's current join method, PAM and NSS configuration, and whether offline logon is needed for laptops or remote sites.

Optional DNS and NTP services

FreeIPA can run ISC BIND DNS and NTP alongside the directory, but both are optional. Running DNS inside FreeIPA changes how service locator records are published, so it affects every client that discovers the domain controller. Decide whether to keep AD-integrated DNS for Windows, delegate a subdomain, or run FreeIPA DNS for Linux only.

What stays with AD for Windows

FreeIPA does not domain-join Windows clients, apply Group Policy to Windows desktops, or provide Windows-integrated authentication with NTLM and Kerberos for Windows apps. A cross-forest trust lets AD users reach Linux resources through FreeIPA, but the Windows estate keeps its domain controllers. Confirm which Windows-only dependencies exist, such as GPO, SYSVOL-based scripts and AD-authenticated line-of-business apps, before you decide what to retire.

Capability comparison from the supplied facts

This table compares Microsoft Active Directory Domain Services with FreeIPA on the capabilities that matter for a Linux-heavy estate. FreeIPA cannot act as a domain controller for Windows clients, so read each row as a question about Linux identity, and mark any row where the answer depends on feature depth you still need to confirm. The main takeaway is that FreeIPA covers Linux identity well, while Windows domain membership and Group Policy stay with Active Directory.

Capability	Microsoft Active Directory DS	FreeIPA
Directory and schema	Stores users, computers and objects with a schema, global catalog and query and index mechanism	389 Directory Server as a multi-master LDAPv3 directory for users, groups, hosts and policies
Kerberos single sign-on	Kerberos authentication for Windows and domain-joined clients through the domain controllers	MIT Kerberos KDC provides single sign-on for Linux and UNIX clients
Windows domain join	Native domain join for Windows desktops and servers	Not supported as an AD domain for Windows clients; FreeIPA is not a Windows domain controller
Group Policy for Windows	Manages Windows desktops and servers with Group Policy	Not a Group Policy replacement for Windows; confirm which Linux host policies you need to cover
Linux host policy, sudo and HBAC	Linux machines need third-party tools or a Kerberos realm configuration to authenticate against AD	Host-based access control and sudo rules are managed centrally; sudo and HBAC rules need manual migration through LDIF
Certificate issuance	Depends on Active Directory Certificate Services, which is a separate role; confirm your current setup	Integrated Dogtag certificate authority for issuing certificates to users and hosts
Two-factor authentication (HOTP, TOTP, RADIUS)	Confirm MFA options with your AD federation or Entra ID setup; not covered by the supplied facts	HOTP and TOTP tokens, including YubiKeys, and proxying OTP checks to an existing RADIUS server
DNS	Integrated DNS is available on domain controllers; confirm the design for your zones	Optional ISC BIND DNS; FreeIPA recommends at least two DNS servers in each client's resolv.conf
Backup and restore	Confirm your Windows Server backup approach and system state recovery procedure	ipa-backup and ipa-restore with full or online data-only backups; restoring an outdated backup into an active topology can break replication
Cross-forest trusts	Native trust model between Windows forests and domains	Cross-forest trust with an AD domain on Windows Server 2008 R2 or later; the IPA DNS domain must not overlap any AD forest domain

Data control, hosting and compliance evidence

Both options run inside your own infrastructure when self-hosted, so the first decision is where identity data sits today. An on-premises Active Directory keeps users, groups, computers and policy in your domain controllers. If you have synced identities to Microsoft Entra ID through Microsoft Entra Connect, copies of user objects and some attributes also live in Microsoft's cloud, and a FreeIPA deployment does not remove that copy. Map every sync connector and every application that reads directory data before you decide what moves, because a Linux-only FreeIPA domain can leave the Entra ID copy untouched. Confirm with your identity team which attributes are synced and who controls the sync scope.

FreeIPA keeps users, groups, hosts, host groups, sudo and HBAC policy in the 389 Directory Server, so those records sit on the IdM servers you deploy and nowhere else. Kerberos keys are held by the MIT Kerberos KDC on the same servers. Certificates for hosts and services come from the integrated Dogtag certificate authority, and its signing keys and certificate revocation list are your responsibility to protect and back up. Document which replica runs the CA, how the CA signing key is stored and who may approve certificate requests, and test ipa-backup restores in a lab before you rely on them. The backup documentation also warns that restoring an outdated backup into an active replica topology can break replication, so record the restore procedure as a controlled change.

For assessments, you need written evidence for access control, privileged accounts, key and certificate management, logging and backup, and an owner for each. DeployOpen prepares these controls, configuration baselines and evidence packs inside your environment, but independent auditors and certification bodies issue any attestation or report. Ask your assessor early which control framework and evidence period apply, because that determines how you show that Active Directory and FreeIPA policies were changed through approved processes. Plan one review cycle for the trust itself, since a cross-forest trust is an ongoing link between two identity sources and must appear in your access control inventory.

What drives the cost of each option

Active Directory cost is mostly licensing that recurs with every server and user, while FreeIPA moves the cost into people, hardware and support. Each card below names one cost component, who gets paid for it and what to ask for before you compare totals.

Windows Server core licensing

Windows Server 2025 is licensed per core, with a minimum of 16 cores per server and 8 per processor, so every domain controller carries the minimum even when it is lightly loaded. Microsoft lists suggested prices of 1,176 US dollars for Standard and 6,771 US dollars for Datacenter for 16 core licenses, and notes that prices vary by region. Ask your reseller or Microsoft partner for the price in your region and for the count of domain controllers you would license.

Client Access Licenses

Both Standard and Datacenter editions need a Windows Server Client Access License for every user or device that accesses the server. CALs are often overlooked when teams compare a directory with a free product, yet they apply to file, print and application servers that still need to be reached by Windows users. Inventory the users and devices that touch each server before you decide what the directory alone saves.

Azure Arc pay-as-you-go

Microsoft offers pay-as-you-go licensing through Azure Arc at 33.58 US dollars per core per month. This converts a capital purchase into a recurring charge that scales with cores, which can suit short coexistence periods during a migration. Model the monthly total for your domain controller core count over the months you expect to run both directories, and confirm the billing terms with Microsoft.

FreeIPA staff and support time

FreeIPA is licensed under GPL-3.0-or-later and has no paid edition, so there is no license fee to pay. The recurring cost is staff time for patching, monitoring, certificate and replication checks, and any support arrangement you choose to buy from a commercial provider. Ask any provider to separate ongoing operations hours from upgrade and incident support, and to state what the retainer covers.

Replica servers and layout

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 hardware or virtual machines, load balancing and DNS servers for each site are therefore a recurring infrastructure cost. Ask for a written topology with the replica count per site, and confirm whether your hypervisor or cloud account is already paid for.

One-time migration and coexistence work

Moving Linux identity to FreeIPA has one-time costs: designing the trust, migrating users and groups with ipa migrate-ds, rewriting sudo and HBAC rules by hand in LDIF, and changing SSSD on every client. These costs are paid once but often exceed the licensing savings for small estates. Ask the provider for a fixed-scope plan that lists the hosts, sudo rules and applications in scope, and for a test cutover before any production change.

Quotes and what to request

DeployOpen does not publish a price list. A quote follows from a written scope that names the domain controllers, Linux hosts, trust design, replica layout, testing and handover. Request a line-by-line quote that separates one-time work from recurring operations, Microsoft licensing from your own staff time, and any Azure Arc or CAL assumptions. Compare totals only when every option uses the same scope and the same years of operation.

How a Linux identity move from AD to FreeIPA runs

The sequence moves Linux authentication, sudo and host access rules from Active Directory to FreeIPA in controlled stages, with a cross-forest trust keeping Windows users working until the last Linux dependency is gone.

Inventory Linux hosts and their AD dependencies
Your Linux administrators, with the platform team, list every Linux and UNIX host that joins AD or authenticates against it, along with the services, sudo rules, SSH logins and applications that rely on those accounts. Record which hosts use SSSD, which use Kerberos, and which apps bind to AD over LDAP. The step is done when each host has an owner and a named dependency list, and you can say which hosts block a trust cut-over.
Build the FreeIPA replica topology
The FreeIPA team deploys dedicated servers, not shared with other applications, following the project's deployment recommendations: at least two to three replicas in each datacenter, no more than four replication agreements per replica, and at least one replica per datacenter running PKI or DNS if you use those services. Confirm that clients will have at least two DNS servers in resolv.conf. The step is done when replication is healthy between all replicas and a test client resolves and authenticates.
Establish the cross-forest trust with Active Directory
Before the trust is created, confirm that the IPA DNS domain does not overlap with any domain in the AD forest, and that your domain controllers meet the version requirements in the FreeIPA trust guide. The AD and FreeIPA administrators then create the trust so Windows users can reach Linux resources during the transition. The step is done when an AD test user can log in to a FreeIPA-enrolled test host and an AD group can be mapped to a FreeIPA access rule.
Migrate users and groups with ipa migrate-ds
Run the ipa migrate-ds command to bring users and groups from the source directory into FreeIPA. The tool excludes Kerberos attributes, which FreeIPA regenerates, so existing Kerberos keys and password material will not carry over, and users must be prepared for a credential reset or a planned re-enrollment. Compare user counts, group membership and key attributes against the source export. The step is done when the reconciled report shows no unexpected gaps and each user's identity maps to the intended FreeIPA account.
Rebuild sudo and HBAC rules from LDIF
sudo and host-based access control rules do not migrate with the standard tool, so the team exports them from AD as LDIF, reviews each rule, and recreates it as FreeIPA sudo and HBAC policy. Remove rules that no longer match current hosts and groups rather than copying them unchanged. The step is done when a sample of privileged and non-privileged logins on test hosts produces the same permitted and denied results as the original rules.
Change SSSD client configuration host by host
Each Linux host is moved to FreeIPA client enrollment and its SSSD configuration is updated, one host group at a time, starting with low-impact systems. Keep a rollback path for each host, and record the enrollment and access tests run after the change. Confirm applications that bind directly to AD by LDAP are either repointed or listed for a separate decision. The step is done when every host in the group logs in as expected, its sudo and HBAC results match the test plan, and the rollback has been tested.
Protect backups during the transition
Take full backups with ipa-backup before each major change, and keep data-only backups on a defined schedule. Note the project's warning that the first server handles certificate renewal and CRL publication by default, and that restoring an outdated backup into an active replica topology can break replication. Restore only into a rebuilt, isolated environment unless the replication plan says otherwise. The step is done when a restore has been rehearsed in a test environment and the team agrees on which server holds the authoritative backup.
Cut the trust only when no Linux host depends on AD
The trust is retired only after the dependency inventory shows no Linux host, service or application still authenticating against Active Directory, and after an agreed observation period with no unresolved failures. Remove the trust, then confirm that Windows and Linux access still works as designed for each group. Document the final state, including which AD services remain for Windows clients. The step is done when the inventory is signed off and the remaining AD dependencies are documented as Windows-only.

What running FreeIPA asks of your team

A team with strong Linux administration skills can run FreeIPA without a Windows counterpart, provided it treats the identity service as a production system with its own runbooks. The daily load is mostly replica health, Kerberos ticket issues, SSSD behavior on clients and certificate housekeeping. The team also owns every upgrade, because FreeIPA is a community project with no paid edition and no vendor support contract.

Replica health: Check replication agreements, keep at least two to three replicas in each datacenter, and respect the limit of no more than four replication agreements per replica.
Certificate and CRL duties: The first server handles certificate renewal and CRL publication by default, so monitor that server and its certificate expiry dates closely.
Patching: Track releases such as 4.13.4, which fixed two CVEs including LDAP access control flaws, and schedule rolling updates across replicas.
Backup testing: Use ipa-backup and ipa-restore on a schedule, and test restores in a lab, since restoring an outdated backup into an active topology can break replication.
Skills: Expect the team to cover 389 Directory Server, MIT Kerberos, Dogtag and DNS, which is a deeper bench than general Linux administration.

Before committing, confirm that at least two people can perform a full recovery without outside help.

Questions buyers ask before moving Linux identity to FreeIPA

Can FreeIPA replace Active Directory for Windows desktops?

No. FreeIPA does not provide a Windows domain for client machines, so Windows desktops cannot be domain-joined to it and Group Policy for Windows clients is not part of its scope. What FreeIPA does is act as the identity source for Linux and UNIX hosts, covering Kerberos single sign-on, host-based access control, sudo rules and centrally managed certificates through its integrated 389 Directory Server, MIT Kerberos and Dogtag components. Most organizations therefore keep Windows endpoints on AD or Entra ID and create a cross-forest trust so Active Directory users can reach Linux resources. Confirm your Windows management needs before you plan the cut.

What does a FreeIPA move cost, and what drives the cost?

FreeIPA is licensed under GPL-3.0-or-later and has no paid edition of its own, so the software itself carries no license fee. The costs are the servers and replicas, the Linux operating system subscriptions if you buy them, staff time for design, migration and testing, and ongoing operation. Cost rises with the number of Linux hosts, the number of data centers that need replicas, the volume of sudo and host-based access rules to migrate, and the number of applications that must be re-tested. Windows Server 2025 licensing is a separate line, since the Windows Server 2025 pricing page notes Standard and Datacenter editions are licensed per core with a minimum of 16 cores per server. Ask any implementation partner for a fixed-scope quote built from your host inventory and replica design.

How long does a FreeIPA migration take?

The duration depends on what has to be proven before the trust is cut, not on the install itself. The main drivers are the size and age of the Linux estate, how many systems still join AD directly, how many sudo and host-based access control rules exist, and whether every application that authenticates to Linux has been tested. The FreeIPA migration how-to notes that users and groups can be imported with the ipa migrate-ds command, but sudo and HBAC rules need manual migration through LDIF, which often sets the pace. Timing also depends on your Windows Server lifecycle dates, covered below. No duration is fixed by the vendor, so ask for a schedule tied to a written scope and milestone list.

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

A team with strong Linux, Kerberos, DNS and LDAP skills can run the work internally, provided it has time to test and a rollback plan. The risk points are replication design, since the FreeIPA deployment recommendations advise at least two to three replicas in each datacenter, and backup discipline, since restoring an outdated backup into an active replica topology can break replication. Certificate operations also need an owner, because the first server handles certificate renewal and CRL publication by default. If these skills are thin, many organizations bring in outside help for design, migration and hardening while keeping operations in-house. Confirm your staffing and cover for on-call before you decide.

What does the organization need to provide for the project?

The organization needs an accurate inventory of Linux and UNIX hosts, the AD objects and groups they depend on, and the list of applications that authenticate against them. It also needs DNS ownership, because the IPA domain must use a DNS name that does not overlap with any domain in the AD forest, and the FreeIPA deployment recommendations call for at least two DNS servers in each client's resolv.conf. Dedicated servers without other applications are recommended, so budget for hardware or virtual machines. Change control, test environments and named application owners for sign-off are also required. Ask the provider to list these inputs in the written scope so gaps show up before work starts.

Can the cross-forest trust with Active Directory stay in place permanently?

Yes, a cross-forest trust can remain in place for the long term if you need Active Directory users to reach Linux resources. FreeIPA supports a trust with an AD domain on Windows Server 2008 R2 or later, according to the FreeIPA Active Directory trust guide. Whether to keep it depends on whether Windows users still need access to Linux services, and whether the AD forest remains the source of truth for people. If you choose to cut the trust and run FreeIPA as the only Linux directory, plan for every Linux host and application to authenticate without AD. Review the trust design against your access model at each Windows Server lifecycle milestone.

How do the Windows Server 2022 and 2025 lifecycle dates affect the decision?

The lifecycle dates set the deadline for Windows domain controllers, while FreeIPA addresses only the Linux side of identity. Microsoft's lifecycle page lists Windows Server 2025 as available since November 1, 2024, with mainstream support ending November 14, 2029 and extended support ending November 15, 2034. Windows Server 2022 mainstream support ended on October 14, 2026, and extended support ends on October 15, 2031. If your domain controllers run Windows Server 2022, you still have a supported window, but the cost of staying on AD is no longer tied to a single migration date. Use these dates to schedule the Linux identity move against your planned upgrade or retirement of Windows domain controllers, and confirm each date against the current Microsoft lifecycle pages.

How DeployOpen helps evaluate and move Linux identity

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including FreeIPA. For Microsoft Active Directory vs FreeIPA, the work starts by deciding which identity role FreeIPA will take, then builds and documents only that scope.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope states which Linux hosts, sudo rules, host access policies and Kerberos realms move, and which remain on Active Directory.
We confirm whether a cross-forest trust is kept for Windows users or whether FreeIPA becomes the only Linux directory.

How we build

We deploy FreeIPA replicas in your own data centers or cloud accounts, following the replica count and placement guidance for each site.
We configure the cross-forest trust with a DNS domain that does not overlap the AD forest, then test Kerberos and SSSD logins.
We migrate sudo and host-based access rules by hand, since they do not move automatically, and check each rule against the source.

How we hand over

You receive written runbooks covering replica topology, certificate renewal ownership, backup schedules and restore steps.
Backup and restore procedures are tested on a copy of the topology, so you know how an outdated backup behaves before you need one.
Handover documents the evidence of each access control test, prepared for your internal reviewers and independent auditors.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover FreeIPA version upgrades, including security releases, with changes tested before they reach production replicas.
Before any retainer starts, confirm response expectations, change windows and who owns each FreeIPA host in writing.

Microsoft Active Directory vs FreeIPA