Kanidm: a Rust identity provider that ships OIDC, RADIUS and Unix login in one server

What Kanidm actually replaces in an identity stack

Kanidm is an identity provider that other applications hand their authentication to. The README frames the goal bluntly: it wants to be a complete identity provider, and adds that you "should not need any other components (like Keycloak)" when you use it. That sentence is the whole pitch. Instead of running an LDAP directory plus a separate OIDC broker plus something for RADIUS, you run Kanidm and it answers on all of those fronts.

The feature list in the README covers passkeys (WebAuthn), including attested passkeys for environments that require them, an application portal for linked apps, OAuth2/OIDC as an authentication provider, OAuth2/OIDC service access with token exchange, Linux and Unix integration with TPM-protected offline authentication, SSH key distribution, RADIUS for network and VPN authentication, a read-only LDAP gateway for legacy systems, CLI administration tooling, two-node high availability through database replication, and a WebUI for self-service.

Who is this for? The README names home labs, families, small businesses and large enterprise needs in one breath. The honest reading is that the target is anyone who wants to host their own authentication service and would rather not operate four products to get there. If your organisation already runs a directory you are happy with, Kanidm is not competing for that slot.

How the pieces fit: one server, many front doors

The repository layout tells you a lot about the architecture. There is a server/ directory containing daemon, lib, core and testkit crates. There is a proto/ crate for the wire protocol, libs/client for the client library, and tools/cli for the command-line tool. Unix integration is split into its own workspace members: nss_kanidm, pam_kanidm, resolver_kanidm, plus a parallel set of sparkle variants (nss_sparkle, pam_sparkle, resolver_kanidm) and shared common crates. RADIUS lives under rlm_kanidm with entrypoint, module and shared crates.

That split is the data flow in miniature. The daemon holds the directory and the authentication logic. Clients speak to it through proto and libs/client. The CLI is one such client. On a Unix machine, NSS and PAM modules let the operating system resolve users and authenticate them against the same server, and the resolver module handles name resolution. RADIUS is implemented as a module rather than a separate service. Legacy systems that only speak LDAP reach the read-only LDAP gateway.

The README describes the design philosophy as strict defaults, simple configuration and self-healing components. That is a deliberate trade: fewer knobs, and the ones that exist are meant to be safe out of the box. It also means the configuration surface you can tune is narrower than what a general-purpose LDAP server exposes. For most deployments that is the point. For an environment with unusual directory semantics, it is a wall.

Installing Kanidm and adding a first user

The README does not contain installation commands. It points to the Kanidm book at kanidm.github.io/kanidm/stable/ as the place to read about what Kanidm can do, and that book is where install instructions live. The repository does give you the pieces: examples/server.toml and examples/server_container.toml for server configuration, examples/config and examples/config_localhost for client configuration, examples/kanidm for the CLI, and examples/unixd and examples/unixd-safe-default for the Unix daemon. The Makefile exposes a development path, with a run target that changes into server/daemon and executes run_insecure_dev_server.sh.

If you are building from source, the workspace Cargo.toml pins rust-version = "1.96" and edition = "2021", so a recent Rust toolchain is required before anything else. The Makefile also documents container build variables, including CONTAINER_TOOL (default docker), CONTAINER_IMAGE_BASE (default kanidm) and CONTAINER_IMAGE_VERSION (default devel). Those defaults are what a container build would use unless you override them.

make config

That target prints the effective values for CONTAINER_IMAGE_BASE, CONTAINER_IMAGE_VERSION, CONTAINER_TOOL and the related variables, which is the quickest way to confirm what a build would produce before you start it.

make run

The run target starts the test and development server by changing into server/daemon and running run_insecure_dev_server.sh. The name is a warning, not decoration: this is a development server, and you should not treat it as a production deployment.

For a real deployment the configuration files under examples/ are the starting point. Copy examples/server.toml, adjust it, and start the daemon against it. The client side reads examples/config or examples/config_localhost depending on whether you are talking to a local or remote server. The CLI is the administration surface, so the first real task after the server is up is creating an admin account and then ordinary users through that CLI. The book, not the README, documents the exact command sequence for that.

Administration is CLI-first, and that is a real constraint

The README's own comparison with LLDAP is unusually candid about this. It states that while LLDAP provides a simple Web UI as the main user management interface, Kanidm currently offers administrative functionality primarily via its CLI, with its Web UI designed more for user interactions than for administration. That is the single most important thing to know before adopting Kanidm.

If your administrators expect to click through a web console to create groups, reset credentials and inspect sessions, Kanidm will feel wrong on day one. The CLI is complete, according to the README, but complete and convenient are different properties. Scripting against a CLI is fine for a small team that already lives in a terminal. It is a harder sell for a helpdesk that rotates staff.

There is a second constraint buried in the feature list: the LDAP gateway is read-only. Legacy systems that only need to look up users and groups can be pointed at it. Anything that expects to write to LDAP, such as an application that provisions its own entries, cannot use Kanidm as its directory. That is a design boundary, not a bug, but it rules out a class of integrations that a general-purpose LDAP server would accept.

Where Kanidm is the wrong tool

The README's comparison section names four alternatives, and each one marks a case where Kanidm is not the right answer. LLDAP is the small, simple option: fewer features, easier to deploy and manage. If Kanidm feels too complex for your needs, the README says LLDAP is the smaller and simpler alternative. That is an admission that Kanidm's breadth has a cost.

389 Directory Server and OpenLDAP are the other end. They are general-purpose LDAP servers that provide LDAP functionality only, so you supply your own identity management components: an OIDC portal, a self-service web UI, command-line administration tools. If you need maximum customisation of your LDAP deployment, the README says those may be better choices. Kanidm is opinionated about how identity works, and opinionated systems are poor fits for environments that need to bend the model.

FreeIPA is the closest in ambition. It bundles LDAP, Kerberos, DNS and a certificate authority into one system, and the README describes it as complex, with numerous components and configurations leading to higher resource usage and administrative overhead during setup and upgrades. Kanidm aims for FreeIPA's feature richness with a lighter footprint and simpler management. The README cites a benchmark with 3,000 users and 1,500 groups in which Kanidm showed roughly three times faster search operations and five times faster modifications and additions, while noting results may vary. Treat that as a project claim, not an independent measurement.

Keycloak is the case people ask about most. It is an OIDC, OAuth2 and SAML provider that can layer WebAuthn on top of existing identity management, and it is commonly used alongside an LDAP server. The README concedes that Keycloak can operate stand-alone, but argues that deploying it requires significant configuration and expertise, and that its extensive authentication workflow customisation makes initial setup challenging. Kanidm's counter-argument is that it does not need Keycloak to provide OAuth2 and other services. If you need SAML, though, note that SAML does not appear in Kanidm's feature list while it does appear in Keycloak's description here.

Rauthy is the minimal OIDC provider that also supports WebAuthn and shares some libraries with Kanidm. The README states Rauthy focuses exclusively on OIDC and does not support additional use cases. If OIDC is genuinely all you need, a narrower tool is less to operate.

Licence, maintenance and upgrade cost

Kanidm is licensed MPL-2.0, stated in both the repository metadata and the workspace Cargo.toml. MPL-2.0 is a file-level copyleft licence: modifications to files that are part of the covered source must be made available under the same licence, while larger works that combine Kanidm with other code can be distributed under other terms. That is the general shape of the licence, not legal advice, and if you plan to embed Kanidm in a product you should read LICENSE.md and get your own counsel.

The project is not archived, and the last push was on 2026-09-21. Releases are frequent: v1.11.0 on 2026-08-02, v1.11.1 on 2026-08-14 and v1.11.2 on 2026-09-11. That cadence is the upgrade cost. Three point releases in six weeks means you should expect to track versions rather than install once and forget, and the workspace version string is 1.12.0-dev, so the next minor line is already in progress.

The README also points to a support guidelines document that describes what the project team will support. That document, not the feature list, is the thing to read before you commit to a platform. Two-node high availability via database replication is the documented redundancy story; anything beyond that is not described in the README or the repository files.

Editorial conclusion

Adopt Kanidm if you want one Rust binary set covering OIDC, RADIUS, SSH keys, Unix login and a read-only LDAP gateway, and you are comfortable administering it from the CLI. Skip it if you need a full administrative web UI or SAML, since the README says the Web UI is aimed at user self-service and the comparison notes do not list SAML. Before committing, check the Kanidm book for the version you will run and read the support guidelines to see whether your platform and deployment shape are covered.

Frequently asked questions

Official sources

1. kanidm/kanidm on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases