FreeIPA vs 389 Directory Server

With a bare 389 Directory Server, the team designs the replication topology itself. 389 Directory Server provides asynchronous multi-supplier replication for fault tolerance and high write performance, and port389.org says database size is restricted only by disk space. That flexibility is useful, but every decision is yours: how many suppliers exist, which ones replicate to which, how each site is covered, and how failover is handled by your applications. You also own the consequences of a bad topology, such as writes that take time to converge across suppliers or a site that loses its only path to the directory. Confirm with the 389 Directory Server project which topology patterns it recommends for your number of sites before you commit to one.

FreeIPA takes most of that design work off your hands by publishing a layout. Its deployment recommendations advise 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. Dedicated servers without other applications are also recommended. The benefit is a tested starting point. The cost is that you must still fit your sites into that shape and keep it intact as you add or retire replicas. Ask your vendor or DeployOpen to show the replica map for your sites and the reasoning behind it, because the recommendations are guidance, not a substitute for an approved design.

Backups carry a different risk. FreeIPA provides ipa-backup and ipa-restore, with full or online data-only backups. Its backup documentation warns that the first server handles certificate renewal and CRL publication by default, so an outage of that server affects certificate lifecycle as well as logins. It also warns that restoring an outdated backup into an active replica topology can break replication. In a bare directory you control the backup tooling and the restore sequence, which means you carry that same risk without a published runbook. Either way, rehearse restores in an isolated environment, record which server holds the renewal role, and never restore a backup over a live topology without a documented procedure for re-establishing replication. The bare directory is acceptable when your team already runs LDAP at scale, needs custom topology or schema control, and has no requirement for Kerberos, an internal CA or host policy from the same product. FreeIPA is acceptable when you want one supported topology and one backup and renewal model across identity, certificates and DNS, and you can staff the operating model it implies. If neither condition fits, plan the operating roles before choosing.

Neither project charges a license fee. FreeIPA is GPL-3.0-or-later with no paid edition of its own, and 389 Directory Server is GPLv3, so the cost of either option is the people who design, install, operate and support it, the servers it runs on, and any support contract you buy from a vendor or partner. The biggest difference is what each option makes you build. A FreeIPA install delivers Kerberos, the Dogtag certificate authority, DNS and host policy in one package, while the bare directory leaves those pieces for your team to design and maintain. One-time costs cluster around design and proving the system works. For FreeIPA, that means choosing the replica layout, the DNS domain (which must not overlap with any Active Directory domain if you plan a trust), and the certificate authority model, then enrolling clients and testing what happens when a replica fails and when a backup is restored. For the bare directory, add the work of building Kerberos, certificate issuance, host policy and their integrations yourself, plus migration with openldap_to_ds if you are moving from OpenLDAP. Ask any partner to quote replica failure and restore testing as a named deliverable, not an assumed step.

Recurring costs are patching, upgrades, operating replicas and DNS servers, and on-call effort. FreeIPA's deployment recommendations advise at least two to three replicas in each datacenter, dedicated servers without other applications, at least one replica per datacenter running PKI or DNS if you use them, and at least two DNS servers in each client's resolv.conf. Each of those choices adds machines, monitoring and patch cycles, so the footprint is larger than a single directory service. The bare directory can run on fewer servers, but every custom Kerberos, certificate or policy component you build carries its own upgrade and testing burden, and FreeIPA's security fixes such as those in 4.13.4 must be applied by someone on your team either way. When requesting a quote, ask for the scope and written deliverables, who operates each component after handover (directory, Kerberos, CA, DNS, backups), which upgrades and security patches are included and for how long, and whether restore testing is part of the price. Confirm with the vendor or partner whether support for your platform version is covered by the subscription. The quote should state what the team must still do internally.

The schedule usually slips in the areas that sit outside the directory itself. DNS design is the first. A FreeIPA install ties client resolution, service discovery and, if used, the integrated DNS servers to the IPA domain, and the team has to settle that domain name before anything else is built. If a cross-forest trust with Active Directory is planned, the IPA domain must not overlap any DNS domain in the AD forest, so that check belongs in week one, not at trust setup. Client enrollment is the second source of delay. A mixed fleet of Linux hosts, appliances and systems with local customizations rarely enrolls in one pass, and each exception adds a test cycle. The third is certificate chain decisions made late. Whether the integrated Dogtag CA runs with a self-signed root, is signed by an external CA, or is replaced by certificates from an outside CA changes how services get certificates and how renewal is handled. Revisiting that choice after hosts are enrolled is expensive.

Application LDAP integration is where the bare 389 Directory Server option most often runs long. Each application expects its own bind accounts, group structure and schema attributes, and changes to the schema or access controls (ACIs) are made online through LDAP operations, which makes them easy to make and hard to roll back cleanly. Ask every application owner for a written list of required attributes and a dedicated test account before design starts. Replication and restore testing is the step most often skipped under pressure. FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so a restore drill against a copy of the topology is the check to schedule, not assume.

The work needs named owners on the client side: directory owners for the schema, groups and replication topology, DNS and PKI owners for the name space and certificate chain, and application owners who can provide test access and sign off on their LDAP behavior. DeployOpen works from a fixed-scope written agreement, so the scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that scope. Ask each owner group to confirm availability and decisions in that scope document, because the open decisions above are what move dates.