What is the problem?
While querying information about users, groups, etc. via commands getent and id, which are internally calling NSS responder, is already optimized by usage of SSSD internal cache, on the contrary, authentication was always performed against server. Authentication against the network many times can cause an excessive application latency. Especially in environments with tens of thousands of users the login process may become inappropriately long when servers are running under high workload (e.g. during classes, when many users log in simultaneously). To handle such situations SSSD now supports cache authentication instead of authenticating directly against network server every time.
To address this problem new option cached_auth_timeout was introduced. This option specifies time in seconds since last successful on-line authentication for which the user will be authenticated using cached credentials while SSSD is in the on-line mode. By default cached_auth_timeout is set to 0 which implies that this feature is disabled.
In plain English it means that if cached_auth_timeout=900, then after successful on-line authentication all subsequent authentication attempts for next 15 minutes will be served from cache (at least all succesfull attempts; see special cases for details).
Setting the feature
Setting cached authentication is quite easy – just add cached_auth_timeout to the domain section and check that cache_credentials=true is also set in the domain section. Then restart SSSD and the feature should be working.
Example of configuration
[domain/domain.dev] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = domain.dev id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = client.domain.dev chpass_provider = ipa dyndns_update = True ipa_server = ipa.domain.dev ldap_tls_cacert = /etc/ipa/ca.crt realmd_tags = manages-system default_shell = /bin/bash use_fully_qualified_names = True fallback_homedir = /home/%d/%u cached_auth_timeout = 150 [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = domain.dev [nss] homedir_substring = /home [pam] # you might consider to uncomment this option to see more verbose output while authenticating #pam_verbosity = 2 [sudo] [autofs] [ssh] [pac] [ifp]
There are a few special cases I would like to briefly describe.
Password got changed locally
In this case subsequent login attempt is processed on-line and the new password is accepted while the old one is denied.
Password got change directly on server or via other client then SSSD
The new password is accepted and that logs inform that cached authentication failed and on-line authentication had to be performed (please note that old password would be accepted as the SSSD client has no knowledge that it was changed).
Entered password does not match the cached one
In this case on-line authentication is performed because it cannot be determined whether there was a typo in password or password was changed directly on server. Also checking on-line is a protection against potential password guessing attacks.
SSSD is in off-line mode
If SSSD is in off-line mode, then this feature is not used and SSSD behaves as usual.