Simply put, the main SSSD purpose is to store data from the remote database in a local cache and then serve this data to the target user (application). Keeping the cache up to date and valid is a difficult task and to do that SSSD consists of multiple components (processes and libraries) that talk to each other through various inter-process communication techniques. The following diagram gives you a basic understanding about the components and their relations. The components are described in more detail below the diagram.
The goal of the backend is to keep the cache up to date. To do so, it talks to the remote server, requests required data and then stores the data in the cache. There are multiple mechanisms that keeps the cache valid and consistent, some of them are triggered by a user request (e.g. user authentication) and some of them happens automatically on the background.
Each backend represents one SSSD domain that is configured in the
[domain/$name]section of the SSSD configuration and it is started as its own instance of
sssd_beprocess. It consist of modules called the data providers that implements specific functionality such as:
id provider: identity of users, groups, services, …
auth provider: user authentication
access provider: grants or denies user access to the machine
sudo provider: provides sudo rules from remote server
and many more
A responder serves as a middle man between the target application and the local cache. When the application requests data (e.g. search user by id), the responder looks into the cache. If the requested data is valid it just returns it. If the data is missing or expired, it asks the backend to query the server first and then the responder returns the result.
There are many responders that serve many different purposes, such as the NSS responder that provides data to the Name Service Switch (nsswitch, nss) service (do not confuse it with Network Security Services) or the PAM responder that implements authentication via Pluggable Authentication Modules (PAM).
Each responder lives in its own process such as:
sssd_nss: The NSS responder
sssd_pam: The PAM responder
sssd_sudo: The sudo responder
… and so on
- Client libraries
These libraries are part of the SSSD project. They implement an interface that is used by the target applications. Their mission is to arrange a communication between the application and a responder in order to retrieve desired data. Example of such libraries are
Clients are not part of SSSD, they are the applications used by users. These applications talk to SSSD using the interface implemented in the client libraries. We can state
sudoas examples of such applications or
glibcand its nsswitch or PAM libraries that talk with SSSD on behalf of the application.
The monitor is the main SSSD process
sssd. It’s purpose is to start and stop requested backends and responders and as the name suggest, it also monitors their state and restarts them if they suddenly stop.
These are utility tools that can be used to monitor SSSD’s status and manipulate the cache from command line.
Backend is the only component the writes to the local cache.
- Local cache (cache)
Local cache is the main and persistent storage. It is stored on the disk using the ldb database (an LDAP-like embedded database) and it contains all data that is currently cached and known to SSSD.
Every object stored in the cache has its own expiration time. The object is considered valid within this time and invalid or expired when the expiration time was reached. If the object is valid, it is returned immediately when requested. If the object is expired then SSSD tries to refresh it before returning the data. Staled data may be returned if the backend is not reachable in the moment of the refresh process.
- Negative cache (ncache)
A negative cache is a non-persistent cache for negative lookups stored inside each SSSD responder. It contains information about objects that are known to not exist (user does not exist) to prevent multiple subsequent queries to the remote database.
- In-memory cache (memcache)
This is a small volatile memory mapped cache of selected objects (user, groups and initgroups). The NSS responder stores objects in this cache after a successful lookup. This cache is then searched by the
nss_sss.solibrary to avoid contacting the NSS responder in the case when the object was already resolved moments ago.
SSSD is capable of caching many object types such as users and groups but also autofs maps, sudo rules, SSH keys and many more. A cache lookup is performed when data is requested. The lookup is performed through a unified cache interface therefore all lookups share the basic algorithm regardless of the object type. The following diagram can give you a basic understanding of how the lookup is performed.
In reality, the lookup is more difficult than what is shown on the diagram and more operations and checks are performed. Some of them implements shortcuts (e.g. we already know what domain is the user from) and some implements subtle differences that are specific to the requested object type. But the diagram is sufficient to get the idea as it catches all the fundamental steps.
User lookup example
The following diagram show the example of looking up a user named Alice. This
happens every time you log in to your computer, list directories, use
sudo commands and so on.
This diagram starts with a call to
getpwnam POSIX function which
responsibility is to resolve the user name (Alice) to a user object which holds
the user id, group id, gecos an similar data. This function is internally called
from the processes and commands mentioned above.