Open-source directory services compared

FreeIPA is licensed under GPL-3.0-or-later and Samba under GPL-3.0, both copyleft licenses. In practice, that means if you modify and distribute either project, the terms of the GPL generally apply to what you distribute, which matters most for teams that ship changed builds to customers or embed these components in their own products. Running them unmodified inside your own infrastructure is a different situation from redistributing them, so have counsel confirm which applies to your deployment. OpenLDAP is distributed under the OpenLDAP Public License, which the project describes as a non-restrictive, free, open-source license. Do not assume it carries the same obligations as the GPL, and do not describe it as OSI-approved in internal documents unless your own review confirms that status.

FreeIPA has no paid edition of its own. The FreeIPA project is a community effort, and there is no vendor-backed commercial version to buy. Red Hat Enterprise Linux packages the same functionality as Identity Management, so for many enterprises the paid element is the operating system subscription, which includes support for that packaged form. Fedora, Debian and CentOS also package FreeIPA, but those distributions support their packages under their own terms. Samba and OpenLDAP follow a similar pattern: the software is free to use, and any paid support comes from a distributor, a consultancy or the project's own ecosystem, not from a license upgrade. Confirm with each provider exactly what a support contract covers, including patches for the release lines you run, the response commitments and whether it extends to custom integrations such as an Active Directory trust.

Before you sign anything, ask each vendor or distributor four questions in writing: which release lines receive security fixes and for how long, whether a support contract covers your specific packaging, whether redistribution rights differ from internal use, and whether any add-on you plan to use, such as a monitoring or backup integration, is under a separate license. Those answers determine the recurring cost far more than the license itself. Where a support term is not stated in a supplied source, treat it as unknown until the provider confirms it in a signed document.

The ongoing work in a directory is mostly topology, backup discipline and name resolution, and the three options put that work in different places. FreeIPA's deployment recommendations call for two to three replicas in each datacenter, no more than four replication agreements per replica, dedicated servers that run no other applications, and at least one replica per datacenter running PKI or DNS if you use those services. Clients should also list at least two DNS servers in resolv.conf. Budget for these as standing design decisions, because the replica count and agreement layout are hard to change once clients and services depend on them.

Backups carry a specific trap. FreeIPA provides ipa-backup and ipa-restore, with full or online data-only backups, but its documentation warns that restoring an outdated backup into an active replica topology can break replication. Write a runbook that says which backup type you take, how often, where copies go, and how a restore is coordinated across replicas before anyone runs it. Confirm with the FreeIPA project which server handles certificate renewal and CRL publication in your layout, since the first server does so by default. Samba's operational risk is different. The Samba wiki advises against using an AD DC as a file server when multiple DCs exist and recommends a separate Samba domain member for file serving, so plan an extra server role and its patching from the start.

OpenLDAP's effort sits in different places. slapd gives you single-provider replication, multi-provider replication and a caching proxy, but the schema, replication design and the Kerberos and Windows integration are all built and maintained by your team. Ask whether your staff has the skills for schema governance and replication testing, and confirm which Kerberos and Windows bridging you will use, because neither is supplied as a finished identity service. Any outside implementation work is scoped and priced from a written statement of those tasks, not from a generic estimate.

Moving off a directory is rarely a data copy. The hardest parts are the ones that bind users, hosts and applications to the directory's identity model. If you plan to migrate from FreeIPA later, expect Kerberos principals to be regenerated during migration rather than carried over unchanged, so every service that authenticates with Kerberos needs its keytabs and service principals re-issued and tested. Ask the project or your integrator to document exactly which attributes the ipa migrate-ds path excludes and regenerates, and to confirm how sudo and HBAC rules are moved, since the FreeIPA migration how-to says those need manual migration through LDIF.

The schema and group model are the next constraint. Users, groups, host objects and nested group membership in one directory rarely map one to one into another, so attribute names, object classes and group nesting need a written mapping before any cutover. Client enrollment is also a cost: every Linux host enrolled through SSSD, every Windows member and every Samba or Active Directory trust relationship has its own state. Application bind configuration is often the most expensive item, because each LDAP-bound application stores its own base DN, bind account, search filter and certificate trust. Inventory these bindings now, and treat each one as a test case in the migration plan.

Treat a directory move as a project in its own right with its own cutover window, rollback path and acceptance tests, not as a side task of an upgrade. Before you commit, ask the vendor or project for the supported migration path between your current and target directories, the versions it covers, and the rollback procedure if replication breaks partway through. Confirm these in writing, and build the cost of the migration into the original platform decision, because the effort to leave a directory usually grows with the number of applications that depend on it.