FreeIPA vs Kanidm vs LLDAP

FreeIPA is an integrated suite, not a single directory. It combines 389 Directory Server for users, groups, hosts and policies, an MIT Kerberos KDC for single sign-on, and the Dogtag certificate authority for issuing certificates. Clients run SSSD, and DNS and NTP are optional components that the suite can also provide. Its scope is Linux and UNIX identity, host-based policy and Kerberos-dependent services, which is why it also offers a cross-forest trust with Active Directory. What it leaves out is a modern web-based sign-on layer: its OTP and Kerberos model is built for Linux logins and internal services, so OIDC-first application sign-on is not its core job. If your estate depends on Kerberos or internal certificates, plan for FreeIPA's replication and backup model from the start, including the FreeIPA About page for component scope.

Kanidm is a single identity server rather than a bundle. The project describes it as a complete identity provider, so the README states that no other component such as Keycloak is needed alongside it. It stores data in its own database and runs its own eventually consistent replication instead of depending on an external SQL database. Its feature set covers passkeys, an OAuth2/OIDC provider, Linux and UNIX login with TPM-protected offline authentication, SSH key distribution, RADIUS and a read-only LDAPS gateway for legacy systems. What it leaves out matters as much: SAML is not among its listed features, and administration is designed around the CLI rather than the web UI. Confirm that your applications can use OAuth2/OIDC and that your legacy systems can work with a read-only LDAP view before you commit.

LLDAP is a deliberately small authentication server. It provides an opinionated, simplified LDAP interface, with a web front end where administrators manage users and groups and users can edit their own details or reset passwords by email. It is meant to be the user store behind applications that only need LDAP logins. It does not try to be a full directory: its README says the goal is not to provide a full LDAP server and points users who need one to OpenLDAP. For OAuth, OpenID or reverse proxy features, it suggests pairing it with components such as Keycloak or Authelia that treat LLDAP as the source of truth. Ask whether your applications need write access through LDAP, Kerberos or per-host policy, since those needs push you toward FreeIPA or a different design.

The three directories make very different bets on how they stay available and how their data survives failure. FreeIPA uses multi-master replication across its 389 Directory Server topology, so any replica can accept writes. 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. Plan the topology before the first install, because changing it later is work. The backup documentation adds a hard rule: restoring an outdated backup into an active replica topology can break replication, so restore tests should be run against an isolated copy, and you should confirm which server handles certificate renewal and CRL publication in your build, since the first server does so by default.

Kanidm takes a narrower path. It does not use SQL. It stores data in its own key-value engine with its own indexing and an eventually consistent replication layer, so there is no external database to size or back up separately. The README describes two-node high availability through replication, which is the scope to plan around. TLS for all connections is mandatory rather than an optional feature, so certificate issuance and trust distribution belong in the first week of any deployment, not the last. Ask the maintainers or your own tests whether two nodes meet your recovery targets before treating that setup as a full disaster recovery design.

LLDAP is the simplest of the three. It runs as a single small container and stores data in SQLite by default. The LLDAP FAQ says it runs in under 10 MB of RAM including the database, which keeps the footprint small, but SQLite is a single-file store that suits a lab or small estate. LLDAP documents a migration to MySQL, MariaDB or PostgreSQL, and that move should be rehearsed before production. LLDAP also has no native virtual hosts or multi-tenancy: all users sit under one base DN, and the FAQ suggests one instance per virtual host. If you host several customers or business units, count instances, databases and backups as separate units from the start.

FreeIPA carries the heaviest up-front planning of the three, and the first decision is the DNS domain. When you trust Active Directory, the IPA domain must use a DNS domain that does not overlap with any domain in the AD forest, so that name has to be settled before the first server is built. The FreeIPA deployment recommendations also advise dedicated servers without other applications, at least two to three replicas in each datacenter, no more than four replication agreements per replica, and at least two DNS servers in each client's resolv.conf. Your team owns the naming, the datacenter layout, the replica count and the change control around them. DeployOpen can scope the trust configuration, replica build, certificate authority choices and the ipa-backup and ipa-restore runbook, which the backup documentation treats as a real risk area because restoring an outdated backup into an active replica topology can break replication. Confirm the cross-forest trust setup against the FreeIPA Active Directory trust setup page before you commit to a design.

Kanidm asks for a different kind of readiness. TLS is mandatory for all connections rather than an optional layer added later, so certificate issuance and renewal must be in place from day one, and your team needs a plan for that. Administration runs primarily through the CLI, with the web UI aimed at user interactions, so the operators who will manage accounts, groups and OAuth2 clients need to be comfortable at a command line. Upgrades are the recurring obligation to plan for: Kanidm releases quarterly, supports each stable release for four months, and upgrades only from the previous minor version. Skipping a release means a multi-step path, so your team owns the upgrade calendar and the test environment that runs ahead of production. DeployOpen can scope the initial deployment, the replication pair, Unix login and SSH key configuration, and the upgrade runbook. Ask the vendor to confirm current support and migration paths in the Kanidm support guidelines.

LLDAP is the smallest job of the three, but it still has decisions. Installation is from an OCI image with Docker or Podman, from a distribution package, on Kubernetes or TrueNAS, or from source, and the choice should follow your existing patching process. The database choice matters: LLDAP stores data in SQLite by default and can use MySQL, MariaDB or PostgreSQL, with documented migration away from SQLite, so decide early whether a file-based store is acceptable for your backup and recovery targets. The larger effort is usually on the application side, where each service needs its own LDAP bind, search base and attribute mapping, and LLDAP's single base DN means every application sees the same user tree. Your team owns the application inventory, the bind accounts and the test of each login path. DeployOpen can scope the install, the database configuration and the application integration work. Because LLDAP offers no commercial support, the operating risk stays with your team and any contract you add around it.