PAM responder always starts by determining the user’s group memberships. It does this by internally calling initgroups on each domain stanza, until it finds a match. Once a match is found, the PAM Responder knows which domain to use, which identity to use, and the groups to which the identity belongs. In our use case, there is only a single domain, so if calling initgroups against our domain fails, then the whole client request fails. Note that the presence of subdomains makes this more complicated, but that has been discussed earlier in the document.
The PAM Responder’s context (pam_ctx) is created at startup by pam_process_init(), which takes several actions, including:
- calling sss_process_init with Responder-specific arguments, including supported commands
- initializing Responder-specific optimizations (see Optimizations section)
- retrieving Responder-specific config information from the confdb
Data Flow (PAM Responder)
This diagram shows the data flow generated by an SSS Client Application making a PAM request to SSSD
- SSS Client Application’s request is handled by our dynamically loaded PAM Client Library, which sends request to matching PAM Responder.
- Like the NSS Responder, the PAM Responder sends getAccountInfo request message to Backend, but only to ask it to update Cache with client’s group memberships (i.e. initgroups)
- Backend uses AD Provider Plugin to make LDAP call to remote AD Server and to retrieve response.
- Backend updates Cache, and also sends getAccountInfo response message (containing status) to PAM Responder; this also serves as indication that Cache has been updated.
- PAM Responder reads updated initgroups information from Cache.
- PAM Responder sends pamHandler request message to Backend
- Backend uses AD Provider Plugin to retrieve response from Child Process, which makes the actual KRB calls; note that the Child Process (not shown) will be discussed later in the document
- Backend sends pamHandler response message (containing status) to PAM Responder
- PAM Responder returns updated result to PAM Client Library, which passes it to SSS Client Application.
Difference between PAM and NSS:
1. PAM Responder’s data flow is different from the NSS Responder’s data flow. The primary difference is that the result of a pamHandler request is not stored in the Cache. The pamHandler response message contains status information, most of which is passed back to the PAM Client Library.
2. NSS Responder sends the Backend only a single request message, corresponding to the SSS Client’s request. In contrast, the PAM Responder sends two request messages: the first one to find the client’s group memberships, and the second one corresponding to the SSS Client’s request.
3. PAM responder always downloads the group memberships from the server (if reachable) even if the cache is up to date. This is to ensure correct authorization data on login, because group memberships are set on login on a Linux system.
Let us talk about more intricate details of PAM in the next post!!