Authenticate against cache in SSSD

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

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain =
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname =
chpass_provider = ipa
dyndns_update = True
ipa_server =
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

services = nss, sudo, pam, ssh
config_file_version = 2

domains =
homedir_substring = /home

# you might consider to uncomment this option to see more verbose output while authenticating
#pam_verbosity = 2






Special cases

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.

Further reading

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s