SSSD puts LDAP and Kerberos behind an NSS and PAM interface

It is a client of directories, and that is the whole design

SSSD provides a set of daemons to manage access to remote directories and authentication mechanisms such as LDAP, Kerberos or FreeIPA. It provides an NSS and PAM interface toward the system and a pluggable backend system to connect to multiple different account sources. That last clause is the one to hold on to. SSSD is not a directory. It does not store users, it is the thing that talks to whatever stores users, and it presents them to the operating system in a way the system already knows how to consume. The reason that matters is the NSS interface specifically, since nsswitch.conf decides which sources answer a getpwnam call, and adding SSSD as a source means the system resolves an identity the same way it resolves a local one, whether or not the machine was ever joined to the directory. For a network with several directory types, the pluggable backend is what lets one interface cover them rather than one configuration per source.

The daemon model is what the caching depends on

The description of the project as a daemon to manage identity, authentication and authorization for centrally-managed systems says more than it looks. A daemon is a long-lived process that stays resident, which is what allows it to hold state between requests, and the practical consequence of that is that identity lookups against a remote directory are answered locally after the first time. The alternative, an LDAP lookup on every call, is slow and means the system depends on the network for every getpwnam. The repository layout is consistent with a project of this shape, with the code under src/, the build system in configure.ac and Makefile.am with its m4/ macro directory, the translation files in po/ and the message bus generation script sbus_generate.sh.in at the root, which is the internal D-Bus interface between the SSSD processes. There is also a Vagrantfile, a .copr/ directory for the COPR build service, and a .pre-commit-config.yaml, so the development environment is set up to be reproducible rather than hand assembled.

Release tarballs are signed, and the key is published

The download section is short and takes distribution of source seriously. SSSD is shipped as a binary package by most Linux distributions, and the README says that if you want the latest source files, navigate to the Releases folder on GitHub. The project signs release tarballs with its GPG key, id C13CD07FFB2DB1408E457A3CD3D21B2910CF6759, since April 2022, and for convenience the key is also uploaded to the keys.openpgp.org keyserver. You can import it directly from the repository.

$ curl -o sssd.asc https://raw.githubusercontent.com/SSSD/sssd/master/contrib/pubkey.asc
$ gpg2 --import sssd.asc

Or fetch it from the keyserver by key id.

$ gpg2 --keyserver keys.openpgp.org --recv-keys C13CD07FFB2DB1408E457A3CD3D21B2910CF6759

Then the verification step, which is the part that actually proves the tarball came from the project.

$ version=x.y.z
$ curl -o sssd-$version.tar.gz https://github.com/SSSD/sssd/releases/download/$version/sssd-$version.tar.gz
$ curl -o sssd-$version.tar.gz.asc https://github.com/SSSD/sssd/releases/download/$version/sssd-$version.tar.gz.asc
$ gpg2 --verify sssd-$version.tar.gz.asc sssd-$version.tar.gz

The key id is long enough to be worth copying rather than typing, and a keyserver import is the safer of the two routes because it does not depend on the same repository serving the file you are about to trust.

Two release streams, and the difference matters for planning

SSSD maintains two release streams, stable and LTM. Releases designated as LTM are long-term maintenance releases and will see bugfixes and security patches for a longer time than other releases. That is a policy most users will care about more than the feature set, because SSSD sits in the login path, where a regression affects whether anyone can get into the machine at all. The recent tags show how the streams interleave, with 2.13.1 from 2026-06-09 and 2.14.0-beta1 from 2026-10-07 sitting alongside 2.9.9 from 2026-04-30, which is a patch release on the older line. The full list of releases is maintained together with the SSSD documentation rather than in the repository, so the releases page on the project site is the place to check which line is where. For an administrator, the practical question is which line your distribution ships, because the daemon talks to system components through NSS and PAM and those interfaces differ between operating system versions.

Documentation lives on its own site, and so do the bug reports

The documentation arrangement is worth noting because it is a deliberate split rather than an accident. The most up to date documentation is at sssd.io, and its source code is hosted at a separate repository, github.com/SSSD/sssd.io, so the documentation can be edited and reviewed independently of the C code. Building and installation from source points at the developer documentation, at sssd.io/contrib/building-sssd.html, and the README does not duplicate build instructions, which is the correct choice for a project whose build varies by distribution. Bugs go in the GitHub issue tracker, with a pointer to a guide on reporting SSSD bugs, which is a sign that the project expects detailed reports rather than one line issues from a system that fails during login. There is a SECURITY.md file at the repository root for anything that should not go in the public tracker. The contact routes are also split by audience, with sssd-devel for development of the daemon and sssd-users for end user discussions, both hosted on Fedora lists, plus the #sssd and #freeipa IRC channels on libera.chat.

Where SSSD is the wrong choice

The clearest wrong case is a machine with only local accounts. Running a daemon to answer identity lookups that the system already answers from /etc/passwd adds a process, a socket and a failure mode to a machine that had none, and if SSSD is not running then even local resolution can be affected depending on how nsswitch is configured. The second wrong case is treating SSSD as an identity store, because it is not one. The README is consistent about this, describing it as a way to manage access to remote directories, so if you want SSSD to hold the accounts rather than proxy them, that is a different project. The third is the operational coupling. A daemon in the authentication path means its failure modes are authentication failures, which is why the release streams, the signing, the bug reporting guide and the security contact all exist, and a team that has not budgeted for that should look at a simpler client configuration first. The fourth is that the C code base and the m4/ autoconf build make local development and contribution a slower path than a Python or Go project would be, whatever the language preference.

Editorial conclusion

SSSD suits a Linux administrator who has a directory of accounts and wants the machine to resolve identities against it without exposing the directory to every process and without a domain join on each login, and the caching behaviour is what makes it viable on laptops and networks with a remote directory. It is the wrong tool for a machine with a handful of local accounts, since running a daemon to answer lookups the system already answers locally is overhead with no benefit, and it is the wrong tool if you want SSSD to be the source of truth, because it is deliberately a client of directories rather than a directory itself. Before deploying, read the release streams page, because SSSD maintains both a stable line and a long term maintenance line and you want to be on the one your distribution ships, and verify release tarballs against the published GPG key. The last push was on 2026-10-19 and the newest tag is 2.14.0-beta1 from 2026-10-07.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. SSSD/sssd on GitHub