FreeIPA vs Active Directory

FreeIPA suits Linux-heavy estates that need Kerberos, sudo and host policy, while Active Directory suits Windows domains managed with Group Policy. Both can coexist through a cross-forest trust.

On this page

FreeIPA vs Active Directory: when each one fits

Choose FreeIPA when most of the estate is Linux or UNIX and the identity layer must provide Kerberos single sign-on, sudo rules and host-based access control in one product. Choose Active Directory when Windows clients, Group Policy and Windows-integrated line-of-business applications are the center of gravity. FreeIPA combines a 389 Directory Server LDAP directory, an MIT Kerberos KDC and a Dogtag certificate authority, and it is built for Linux hosts that need to be enrolled, governed and audited as a fleet. Active Directory Domain Services stores users, computers and other objects, replicates them to every domain controller in a domain, and is the usual home for domain-joined Windows devices and their policies.

The decision turns on three questions. First, where do Windows clients and line-of-business applications sit? If they authenticate with LDAP, NTLM or Kerberos against AD, as Microsoft's comparison describes for most on-premises apps, replacing AD is a much larger project than moving Linux hosts. Second, must AD remain the identity authority? If so, the usual pattern is a FreeIPA cross-forest trust, which the FreeIPA AD trust guide supports from Windows Server 2008 R2 onward, so AD users reach Linux resources without a second password store. Third, who will operate the directory after go-live? FreeIPA replicas, the first server's certificate renewal and CRL duties, and backup restore order all need a team that understands Kerberos and LDAP, not just a Windows administrator.

Before committing, confirm the Windows client and application inventory, the AD functional level and DNS layout, and whether the IPA DNS domain can avoid overlapping with any AD forest domain, which the FreeIPA Trusts page requires. Ask your own team and any partner to document who patches, backs up and restores each platform. For a fixed-scope comparison of your estate, the FreeIPA Active Directory trust setup page is the natural next read for the trust path.

Which platform fits which scenario

This table matches common estate shapes to the platform that usually fits them, with the condition that makes each advantage matter. Read the Why column before the Better fit column, because the same team can land on different answers depending on where its users, hosts and policies already live. The main takeaway is that FreeIPA suits Linux-centred policy, while Active Directory stays the default wherever Windows desktops and Group Policy are the working model.

ScenarioBetter fitWhy
Linux-only estate with central sudo and HBAC rulesFreeIPAHost-based access control and sudo rules are managed centrally in FreeIPA, and the advantage holds when most hosts are Linux and the policy team wants one place to manage them. Confirm that your sudo and HBAC rules can be migrated, because the migration how-to says those rules need manual LDIF migration.
Windows-first estate with Group Policy and domain-joined desktopsActive DirectoryActive Directory provides domain join for Windows devices and Group Policy for desktops and servers, which is the working model most Windows administrators already run. The advantage matters when desktop management is the main job, since FreeIPA does not replace Group Policy for Windows endpoints.
Mixed estate that must keep AD as the authorityActive DirectoryWhen user accounts, groups and Windows logons must originate in AD, AD should stay the source of truth and Linux hosts should join it, either directly or through a trust. FreeIPA is a better add-on for Linux policy than a replacement for the authority.
Linux estate that needs AD users to reach Linux resourcesFreeIPA with a cross-forest trustA cross-forest trust lets AD users reach FreeIPA-managed Linux resources without duplicating accounts, and FreeIPA's guide covers Windows Server 2008 R2 or later. Confirm that the IPA DNS domain does not overlap any domain in the AD forest, since the trust requirements rule this out.
Team with no Windows administratorsFreeIPAA team with Linux skills and no Windows administration capacity can run FreeIPA without adding Windows domain administration to its duties. This matters most when the organization has no existing AD estate to preserve, so confirm how many Windows clients and servers you would still need to manage.
Organization that must replace AD entirelyNeither as a drop-in, evaluate firstReplacing AD means moving Windows logons, Group Policy and application LDAP or Kerberos dependencies, which FreeIPA does not provide as a like-for-like swap. The move is realistic only when Windows clients are few or retired, so inventory every AD-dependent application before deciding.

How FreeIPA and Active Directory are built and operated

FreeIPA bundles a directory, Kerberos, a certificate authority and host policy into one Linux-first stack, while Active Directory is a Windows Server role that replicates to every domain controller. The cards below cover the parts each team will operate day to day and the decisions that follow from them.

The FreeIPA component bundle

FreeIPA combines 389 Directory Server for users, groups, hosts and policies, an MIT Kerberos KDC for single sign-on, and a Dogtag certificate authority. Clients run SSSD, and ISC BIND DNS and NTP are optional. Each component is a separate upgrade and troubleshooting surface, so check which pieces your team must own, including DNS, before you commit. Confirm how your distribution packages these components.

Active Directory Domain Services role

AD DS is a Windows Server role that stores users, computers and other objects. It replicates directory data to every domain controller in a domain and provides a schema, a global catalog and a query and index mechanism. Your Windows administrators already know this model, so the main question is whether your Windows estate depends on features that only exist in this stack. Confirm which Windows Server release your domain controllers run.

Replica count and topology limits

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 that run no other applications. Plan the topology before the first install, since adding a site later means revisiting agreements on existing replicas. Ask who will own replication monitoring, and whether your network links between sites can carry that traffic reliably.

Backup and restore cautions in FreeIPA

FreeIPA provides ipa-backup and ipa-restore, with full or online data-only backups. Its documentation warns 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 drills must be part of the runbook, and the team should know which server holds those roles before an incident. Ask your vendor or partner to show a tested restore sequence.

Schema and global catalog in Active Directory

Active Directory keeps one schema for the forest and uses the global catalog to answer searches across domains. Changes to the schema are forest-wide and hard to reverse, so schema extensions from third-party products need a change review. Teams that run Linux identity alongside AD should confirm which applications query the global catalog, since FreeIPA does not provide that role. Check this during the design phase, not after cutover.

What the daily operator owns

A FreeIPA team typically runs Linux hosts, Kerberos tickets, certificate renewals and DNS records. An AD team runs Windows domain controllers, Group Policy and domain-joined clients. Mixed estates need both skill sets on call, and the handoff for certificate renewal, replication failures and password policy should be written down. Ask any partner to document which tasks sit with your staff and which sit with them.

FreeIPA vs Active Directory feature by feature

This table compares how FreeIPA and Active Directory handle the capabilities Linux-heavy and mixed estates care about most. Read each row against where your users, hosts and audit evidence actually live, and treat any cell marked for confirmation as a question for the vendor or your own test environment.

CapabilityFreeIPAActive Directory
LicenseGPL-3.0-or-later, community project with no paid edition of its ownWindows Server licensing per core with Client Access Licenses for each user or device, per Microsoft's pricing page
Kerberos single sign-onProvided by an MIT Kerberos KDC integrated with the directoryKerberos is part of the domain, and Windows-integrated authentication uses NTLM and Kerberos
LDAP directory389 Directory Server, multi-master LDAPv3 for users, groups, hosts and policiesStores users, computers and objects, replicated to every domain controller in a domain
CertificatesIntegrated Dogtag certificate authority, with random serial numbers by default since 4.13.0Requires confirming the Active Directory Certificate Services role and its design for your environment
Two-factor authenticationHOTP and TOTP tokens, including YubiKeys, and can proxy OTP checks to an existing RADIUS serverConfirm which MFA options fit your setup, such as Microsoft Entra ID or AD FS, as this is outside the supplied facts
Linux sudo and HBAC policyNative central sudo and host-based access control rulesRequires third-party tools or Linux configured as a Kerberos realm, so confirm current options with Microsoft and your Linux vendor
Windows domain join and Group PolicyNot its focus, Windows clients are typically served through a trust or a Samba-based domain controllerNative domain join for Windows devices and Group Policy for desktops and servers
Cross-forest trustCan establish a trust with an AD domain on Windows Server 2008 R2 or later, provided the IPA DNS domain does not overlap with the AD forestNative trust support with other AD forests, confirm the trust type and functional level for your forest
Backup toolingipa-backup and ipa-restore with full or online data-only backups, plus a warning on restoring outdated backups into active replicasConfirm backup options and procedures with Microsoft documentation and your backup vendor
Supported platformsPackaged in Fedora, Debian and CentOS, and in Red Hat Enterprise Linux as Identity ManagementWindows Server role, with Windows Server 2025 available since November 1, 2024

What each platform costs to license and what is paid for

FreeIPA is licensed under GPL-3.0-or-later, according to the project's COPYING file, and it is a community project with no paid edition of its own. The software carries no license fee, so the money goes to the servers that run replicas, the people who install and operate them, and any support contract you choose to buy. The same code reaches you through several channels. The FreeIPA downloads page lists packages for Fedora, Debian and CentOS, and Identity Management in Red Hat Enterprise Linux.

  • No license fee for the software: GPL-3.0-or-later code can be installed and run without a per-user or per-core charge from the project.
  • Infrastructure recurs: The project's deployment recommendations call for two to three replicas in each datacenter on dedicated servers, so hardware or virtual capacity is an ongoing cost.
  • Support is a separate purchase: Community channels carry no contractual response terms. Vendor or integrator support is quoted against a written scope.
  • RHEL build terms differ: Identity Management on RHEL is supplied under Red Hat's subscription terms, which you should confirm directly with Red Hat rather than assume they match the community build.
  • Staff effort is the largest driver: Installation, replication checks, backup testing, certificate renewal and upgrades consume internal or contracted hours every year.

Confirm with Red Hat which subscription and support level covers Identity Management on your systems, and confirm with your implementation partner what a fixed-scope build and any operations retainer would include.

What drives running cost on each side

Running cost for FreeIPA and Active Directory is shaped less by the software price than by how many servers you run, who operates them and when you must upgrade. The cards below separate the license lines from the recurring effort, so you can ask each vendor or partner for a quote built on the same scope.

Windows Server core and CAL licensing

Active Directory domain controllers run on Windows Server, which Microsoft licenses per core with a minimum of 16 cores per server and 8 per processor. Standard and Datacenter editions both need a Client Access License for every user or device that accesses the server. Ask for the license count per domain controller, the CAL basis and whether pricing is perpetual or pay-as-you-go. Regional pricing varies, so get the figures from your reseller or agreement rather than the list price.

No license fee for FreeIPA

FreeIPA is GPL-3.0-or-later and is a community project with no paid edition of its own, so the software itself carries no license line. Your recurring cost is the servers, the operating system subscription if you use one, and the people who run them. The license line is zero, so the quote should focus on infrastructure and labor. Confirm whether you will buy vendor support, which is a separate line item.

Domain controller and replica count

Both platforms need redundancy in every datacenter, and the count drives hardware, backup storage and patching time. FreeIPA's deployment recommendations advise at least two to three replicas per datacenter, no more than four replication agreements per replica, and dedicated servers without other applications. Ask how many domain controllers or replicas each site needs, and who pays for the hosts they run on. Your own topology sets the real number, so validate it against your sites and recovery targets.

Staff skills and on-call coverage

Active Directory skills are common in most Windows shops, while FreeIPA needs people comfortable with Kerberos, the Dogtag certificate authority, 389 Directory Server and SSSD on clients. The first server handles certificate renewal and CRL publication by default, so restore and replication mistakes can be costly. Ask who covers Kerberos and certificate incidents out of hours, and whether the team already runs Linux identity in production. Training and retained specialist time are recurring costs that a quote should show separately.

Vendor support and subscriptions

Active Directory support usually runs through Microsoft agreements, while FreeIPA is packaged as Identity Management in Red Hat Enterprise Linux, where support follows the RHEL subscription. Community FreeIPA on other distributions has no vendor support contract by default. Confirm which support tier covers your directory, the response terms, and whether the subscription is required for every host or only the identity servers. Treat support as a recurring line that can outweigh the license difference in a regulated estate.

Upgrade cadence and migration effort

Windows Server 2025 has mainstream support until November 14, 2029 and extended support until November 15, 2034, and Windows Server 2022 mainstream support ended October 14, 2026, with extended support running to October 15, 2031. Moving between AD and FreeIPA is a one-time project covering users, sudo and HBAC rules, which must be migrated by hand, and client reconfiguration. Ask for the upgrade plan per release, the migration scope in writing, and the rollback plan if a trust or replication step fails.

Moving users, hosts and policy between the two

This sequence gives a team that runs FreeIPA and Active Directory side by side, or moves from one to the other, a written order of work: what gets inventoried, which system owns each identity, how trust is built, what migrates by tool and what is rebuilt by hand. It ends with a documented cutover and retirement plan.

  1. Inventory users, groups, hosts and policies

    Identity and platform engineers list every user, group, host, sudo rule, HBAC rule, service account and application that authenticates against the current directory. Record where each object lives, which applications bind to LDAP or Kerberos, and which policies exist only as configuration on a server. The output is a signed inventory spreadsheet or export that the owners of each application have reviewed. The step is done when no application is missing from the list and every policy has a named owner.

  2. Assign an authority for each identity

    Decide, per identity type, whether FreeIPA or Active Directory is the source of truth. A common pattern is to keep Windows user and device management in AD and Linux host, sudo and HBAC policy in FreeIPA, but the split is a design choice that depends on your estate. Document the decision in a RACI-style table and confirm it with security, IAM and application owners. The step is done when every object type in the inventory has exactly one authoritative system and the table is approved in writing.

  3. Build the cross-forest trust first

    Before moving any workload, the platform team prepares the DNS design and establishes the cross-forest trust using the FreeIPA Active Directory trust guide. The IPA DNS domain must not overlap any domain in the AD forest, and the AD domain must run on a Windows Server version the guide supports. Test that an AD test user can authenticate to a Linux test host and that a Linux resource is reachable from a Windows client. The step is done when test logins succeed in both directions and the results are recorded.

  4. Migrate users and groups with ipa migrate-ds

    Use the ipa migrate-ds command from the FreeIPA migration how-to to copy users and groups from the source LDAP server into FreeIPA. The tool excludes Kerberos attributes, which FreeIPA regenerates, so every migrated user needs a new Kerberos password or key set during the cutover window. Run the migration first against a non-production replica, compare object counts and group memberships, then repeat it for production. The step is done when counts and memberships match the inventory and a sample of users can log in.

  5. Rebuild sudo and HBAC rules by hand

    Sudo and host-based access control rules do not move with the migration tool, so the team exports them from the source system and rewrites them as LDIF for FreeIPA, following the migration how-to. Review each rule against the inventory, remove rules that no longer match an active host, and test privilege escalation and access denial on representative hosts. Record which rules were retired on purpose. The step is done when each rule has a reviewed LDIF entry, a test result and an owner sign-off.

  6. Move host enrollment and application bindings

    Re-enroll Linux hosts into FreeIPA with the client tooling in batches, and repoint each application's LDAP, Kerberos or certificate settings to the new realm and servers. Keep the old bindings available for rollback until the application owner confirms the new login path. Verify DNS resolution from clients, including the recommendation to list at least two DNS servers in resolv.conf. The step is done when every host in the inventory reports a successful enrollment and each application passes its login test.

  7. Cut over and back up before retirement

    Freeze changes to the source directory, run a final synchronization, and switch authority for each identity type as agreed in the written plan. Take a full ipa-backup of the FreeIPA topology and confirm it can be restored, since the backup documentation warns that restoring an outdated backup into an active replica topology can break replication. Monitor authentication logs and certificate renewal for an agreed period. The step is done when the backup restore has been tested and the cutover checklist is signed off.

  8. Retire the old system on a written schedule

    After the cutover checks pass, decommission the old directory in stages: disable write access, keep a read-only copy for the agreed retention period, then remove the service. Update the inventory, the RACI table and the disaster recovery runbook to show the new authority. Confirm the order and timing of each stage in the written plan with the security and compliance owners before work starts. The step is done when the old system is removed and the documentation shows FreeIPA or AD as the only authority for each identity.

Where FreeIPA and Active Directory projects usually run long

The work that stretches timelines is rarely the installation. It is DNS design, and it should be settled before any server is built. A cross-forest trust requires that the IPA domain use a DNS domain that does not overlap with any domain in the AD forest, so a team that reuses an existing internal namespace will find the trust blocked late in the project. Clients also need at least two DNS servers in their resolver configuration, which means the team must confirm how /etc/resolv.conf is managed on each host class, and whether those hosts are configured by a provisioning tool that overwrites it. Ask the client's network team to document the zone layout, the forwarders and the ownership of each DNS record before the schedule is fixed.

Replica topology and backup discipline come next. FreeIPA's deployment recommendations call for at least two to three replicas in each datacenter, no more than four replication agreements per replica, and dedicated servers without other applications, so the topology has to be drawn against the client's actual sites and network links. Backups need the same care. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so restore runbooks must state which backup is valid, who authorizes a restore, and how the restored server is brought back without disturbing the rest of the topology. Also confirm which server handles certificate renewal and CRL publication by default, because that role must survive any replacement or decommissioning of the first server.

Application authentication is the risk most often underestimated. Line-of-business applications that bind to LDAP, expect NTLM, or depend on Kerberos service principals each behave differently against FreeIPA than against Active Directory, and none of them can be assumed to work from a vendor's general compatibility statement. Build an inventory of every application that authenticates, record the protocol and the account it uses, and test each one individually against a non-production realm. Scope, deliverables and timelines should be agreed in writing before work starts, with the application test matrix named as a deliverable. The unknowns in this section belong to the client's own estate, not to a general rule, and only the client's inventory can show how many of them exist.

What buyers ask before choosing or hiring help

What does it cost to run FreeIPA compared with Active Directory?

FreeIPA has no license fee because it is GPL-3.0-or-later community software with no paid edition of its own, so the cost is staff time, servers, replicas, backups and any support subscription you buy from a vendor. Active Directory runs on Windows Server, which Microsoft licenses per core with a minimum of 16 cores per server and 8 per processor, and both Standard and Datacenter editions need a Windows Server Client Access License for every user or device that accesses the server. Microsoft's Windows Server 2025 pricing page lists a suggested price 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. Cost rises with the number of domain controllers or replicas, the number of users and devices, and the Windows skills you need in-house. Ask any quote to break out one-time work from recurring licensing, support and patching.

Can we keep Active Directory and add FreeIPA for Linux?

Yes, this is the coexistence model FreeIPA is built for. FreeIPA can establish a cross-forest trust with an Active Directory domain on Windows Server 2008 R2 or later, so AD users can reach Linux resources while Windows remains managed by AD. Your Windows estate keeps its domain controllers, Group Policy and domain-joined desktops, and your Linux hosts, sudo rules and host-based access controls live in FreeIPA. The IPA domain must use a DNS domain that does not overlap with any domain in the AD forest, so plan the naming before installing. Confirm the trust scope, DNS design and any applications that expect AD group behavior with your own test environment before you commit.

How long does a migration from Active Directory to FreeIPA take?

The duration depends on the written scope, and no researched duration applies, so you should confirm it against a scope document rather than a generic estimate. The main drivers are the number of users, groups, hosts and applications that authenticate against AD, how many use LDAP, Windows-integrated authentication or header-based authentication, and whether Windows clients remain. FreeIPA can migrate users and groups from other LDAP servers with the ipa migrate-ds command, but sudo and HBAC rules need manual migration through LDIF, and Kerberos attributes are regenerated rather than copied. Each application that depends on AD behavior adds testing time. Ask for the phases, test plan and cutover approach to be written into the scope before work starts.

What skills does the internal team need to run FreeIPA?

Plan for Linux administrators who understand Kerberos, LDAP, certificates and DNS, plus Windows administrators who can still manage AD, Group Policy and any domain-joined desktops during coexistence. DNS knowledge matters most, because FreeIPA's deployment recommendations call for at least two DNS servers in each client's resolv.conf and at least one replica per datacenter running PKI or DNS if used. Your team also needs to handle replication topology: the recommendations advise two to three replicas in each datacenter and no more than four replication agreements per replica. Backup skills are required too, since ipa-restore of an outdated backup into an active replica topology can break replication. Confirm these skills with your own staff before scoping the work.

Can our team do the migration itself, and where does outside help add value?

A capable team with Linux and Windows experience can run FreeIPA on its own, because the product is community software with public documentation and no paid edition gating features. Outside help usually adds the most value in design decisions that are hard to reverse, such as the DNS naming that must not overlap the AD forest, replica placement, certificate authority setup and the mapping of existing sudo and HBAC rules. It also helps with test plans for applications that depend on AD, and with a written runbook for backup and restore. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, usually under a fixed-scope agreement with scope and timelines written before work starts. Ongoing support is available as a retainer.

Can FreeIPA replace Active Directory for Windows desktops?

Not on its own, and the answer depends on what you need from Windows. FreeIPA gives Linux and UNIX hosts central identity, Kerberos, certificates and sudo and host policy, and a cross-forest trust lets AD users reach those Linux resources. Microsoft's comparison notes that Active Directory lets administrators domain-join Windows devices and manage Windows desktops and servers with Group Policy, while Linux machines need third-party tools or must be configured to authenticate against AD as a Kerberos realm. So replacing AD for Windows desktops means finding another way to deliver the Group Policy and domain-join functions your desktops depend on. Test that with your own Windows management tooling before deciding.

What does a cross-forest trust between FreeIPA and Active Directory require?

A cross-forest trust requires a supported Active Directory domain, which FreeIPA documents as Windows Server 2008 R2 or later, and a non-overlapping DNS namespace, because the IPA domain cannot share a DNS domain with any domain in the AD forest. FreeIPA establishes the trust through Samba components, so you need the trust setup steps and the relevant network paths between the two environments working correctly. Confirm the functional level, DNS resolution in both directions, time sources, firewall rules and the account used to create the trust with your Windows and Linux administrators. Review the FreeIPA Active Directory trust setup guide before you plan the change window.

How DeployOpen helps choose, implement or migrate without favoring either platform

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the choice between FreeIPA and Active Directory starts from your requirements rather than a preferred product. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.

How we scope

  • Inventory which systems authenticate to Active Directory today, including LDAP binds, Windows-integrated logins and Linux Kerberos clients.
  • Record which Linux hosts need sudo, host-based access and certificate policy, since those drive the FreeIPA fit.
  • Agree the written scope, deliverables and timeline before any build work starts, and confirm which trust or migration path is in it.

How we build

  • Design the FreeIPA topology with replica counts per datacenter, replication agreements and DNS placement against the vendor's deployment recommendations.
  • Set up cross-forest trust or direct SSSD integration in a test environment, and verify that AD users reach Linux resources as intended.
  • Test backup and restore, certificate renewal and failover in your environment, not only on installation day.

How we hand over

  • Document the final topology, trust configuration, sudo and HBAC rules, and the operating runbook for your own administrators.
  • Hand over backup procedures, including the caution about restoring an outdated backup into an active replica topology.
  • Provide evidence of configured controls for your compliance assessor, while noting that independent auditors issue any attestation.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer after handover, sized to the written scope.
  • Plan upgrades against the FreeIPA release and CVE history, such as the 4.13.4 security fixes, before they reach production.
  • Confirm with your team and vendor which distribution build you run, since support scope differs between community and vendor-backed editions.

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.