Question
SSSD Offline Credentials vs LDAP Password Expiration Enforcement in RHEL 9
Dev Finch
0 reputation · 15 Sept 2021, 10:10 UTC
119.3K views1
Loading…
0 reputation · 15 Sept 2021, 10:10 UTC
RHEL 9's default authentication stack uses SSSD as the primary backend for LDAP/AD integration, with pam_sss.so delegating authentication to SSSD. The pam_unix.so module handles local password expiration checks, but when LDAP passwords expire, the system's behavior depends on SSSD's cache configuration.
The key constraint is ensuring that expired LDAP credentials are rejected immediately during authentication, rather than being accepted through SSSD's offline cache mechanism. This becomes critical in environments where password policies mandate immediate enforcement of expiration dates across all authentication methods.
Two documented approaches exist: configuring SSSD to disable offline credentials entirely, or adjusting cache expiration timeouts to align with LDAP password policies. The unresolved decision centers on which approach provides proper balance between authentication reliability and security enforcement when LDAP servers are unavailable.
Which SSSD configuration approach—disabling offline credentials or synchronizing cache expiration with LDAP password policies—correctly enforces expired LDAP password rejection while maintaining acceptable authentication availability during network outages?
34275 reputation · 15 Sept 2021, 22:02 UTC
Disabling SSSD's credential cache (cache_credentials = False in the [domain/…] section of sssd.conf) is the approach that comes closest to guaranteeing immediate rejection of expired LDAP passwords, because every authentication attempt then requires a live LDAP bind. Adjusting cache expiration timers only shrinks the window in which an expired password might still be accepted from cache; it cannot enforce immediate rejection.
redhatcache_credentials = False, SSSD does not store or use cached credentials, so authentication always goes to the LDAP server. If the server reports the password as expired (via a password-expired control or policy response), the bind fails and login is rejected.ldap_pwd_policy setting being able to process that policy. Verify your directory returns expiration information on bind.account_cache_expiration and entry_cache_timeout affect how long cached user/account data is trusted; they do not provide hard enforcement of password expiry when caching is enabled.[pam] section option offline_credentials_expiration controls how long cached logins remain valid while the system is offline — it is relevant only when credential caching is enabled./etc/sssd/sssd.conf and in your [domain/…] section set cache_credentials = False.ldap_pwd_policy is appropriate for your directory (e.g., shadow or the default for AD-style policies) so expiration responses are honored.systemctl restart sssd.grep -r cache_credentials /etc/sssd/.ssh or su). Login should fail, and /var/log/sssd/sssd_<domain>.log should show the bind failing due to the expired password.With caching disabled, any LDAP outage (network partition, server down) means all LDAP logins fail. This is only acceptable if you have LDAP replicas/load balancing or local emergency accounts.
Do you have redundant LDAP servers or local fallback accounts? If not, the safer compromise is keeping cache_credentials = True with a short offline_credentials_expiration (in [pam]), accepting a bounded window rather than immediate enforcement.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.