PAM vs LDAP vs SSSD vs Kerberos
The sssd
daemon acts as the spider in the web, controlling the login process and more. The login program communicates with the configured pam
and nss
modules, which in this case are provided by the SSSD package. These modules communicate with the corresponding SSSD responders, which in turn talk to the SSSD Monitor. SSSD looks up the user in the LDAP directory, then contacts the Kerberos KDC for authentication and to aquire tickets.
(PAM and NSS can also talk to LDAP directly using pam_ldap and nss_ldap respectively. However SSSD provides additional functionality.)
Of course, a lot of this depends on how SSSD has been configured; there lots of different scenarios. For example, you can configure SSSD to do authentication directly with LDAP, or authenticate via Kerberos.
The sssd
daemon does not actually do much that cannot be done with a system that has been "assembled by hand", but has the advantage that it handles everything in a centralised place. Another important benefit of SSSD is that it caches the credentials, which eases the load on servers and makes it possible to go offline and still login. This way you don't need a local account on the machine for offline authentication.
Related videos on Youtube
Comments
-
tfh almost 2 years
I am basically aware of what these services do separate from each other. What I want to know: what exactly happens on a successful login in a linux based network that uses all of these services? In which order these services are consulted? What service talks to what service?
-
tfh over 7 yearsQuite surprising to see that sssd seems to be the coordinator of the process. I thought that would be the task of PAM as it abstracts over implementation details.
-
user2066657 almost 5 yearsYeah, but the devs of SSSD decided to reinvent 'coordination' ... mostly. It follows the old unix adage of "do everything, mostly okay".