Understanding the Local Authentication Workflow with SSSD, PAM, NSS, and AD

Authentication and authorization are critical processes in any operating system, and Linux is no exception. However, setting up a complex authentication system with multiple identity stores can be challenging. That’s where System Security Services Daemon (SSSD), Pluggable Authentication Modules (PAM), and Name Service Switch (NSS) come into play. In this article, we will explore how these tools work together with Active Directory (AD) to create a seamless and secure authentication workflow.

Abstract:

1. PAM, NSS and SSSD are present locally on the OS.
2. Any call made to OS for authenticating or authorization results in a call to PAM/NSS then to SSSD and eventually to AD or LDAP.
3. SSSD is configured in sssd.conf to contact AD for authentication.
4. SSSD can maintain AD id-mapping cache locally on the OS.
5. SSSD will lookup both in the external source and locally to get user -> password or user name to -> uid , uid-> username, group name to gid, gid-> group name etc.

Workflow:

1. configure the sssd.conf and add nss and pam as responders
2. configure nsswitch.conf to be compatable with sss
3. use pam-config tool to seamlessly add sss to pam modules/lib without breaking anything.
4. now everything will go through sssd through the responders

The SSSD daemon (Running locally on the Linux OS) will control the login process. 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 AD directory.

NSS is there to enumerate information from ad about services/users (what group you belong to, where your home directory is ,etc). PAM determines what to do about that information. and all of that is under SSSD.

Local:

how SSSD work with PAM, NSS,krb5 and AD:

• SSSD
• NSS
• PAM
• krb5

SSSD: System Security Services Daemon

since pam and nss are complex to configure with no offline auth capability. traditional Linux auth we can authenticate locally and one and only one remote source whether ldap or krb5

we can use SSSD we can authenticate to multiple identity stores and it works as a gateway of some sort which allows us to use a central location for different services in a single conf file

SSSD uses a parent/child process monitoring model:
[sssd] Parent process, Monitor
[nss] [pam]Child process, Responder
[domain/AD] Child process, Provider

SSSD configuration is found in /etc/sssd/sssd.conf

NSS: Name Service Switch

The nsswitch. conf file commonly controls searches for users (in passwd), passwords (in shadow), host IP addresses, and group information and defines the search order of the network databases.

NSS — A module based system for controlling how various OS-level databases are assembled in memory. This includes (but is not limited to) passwd, group, shadow (this is important to note), and hosts. UID lookups use the passwd database, and GID lookups use the group database.

NSS conf is in /etc/nsswitch.conf

PAM: Pluggable Authentication Modules

PAM — A module based system for allowing service based authentication and accounting. Unlike NSS, you are not extending existing databases; PAM modules can use whatever logic they like, though shell logins still depend on the passwd and group databases of NSS. (you always need UID/GID lookups).PAM does nothing on its own. If an application does not link against the PAM library and make calls to it.

several changes is done in /etc/pam.d/ we added SSS module pam_sss.co

files that have the module are: common-account common-auth common-password common session

krb5 (Kerberos): Network Authentication Protocol

Kerberos is used to authenticate entities requesting access to network resources, especially in large networks to support SSO.

example use case :

1. to initially join the system to the domain and generate the key-tab file ( contains encoded credentials used by the Linux system itself to pre-authenticate to active directory ).
2. to allow normal active directory users to pre-authenticate to perform tasks that require a krb connections.

conf is in /etc/krb5.conf

SSSD, PAM, NSS, and AD work together to create a seamless and secure authentication workflow. By using SSSD, we can authenticate to multiple identity stores and maintain a single configuration file. NSS and PAM work under the control of SSSD, allowing us to extend the existing databases and use any logic we like for authentication. With Kerberos, we can enable Single Sign-On for our network resources, making our authentication workflow even more streamlined and efficient.