Cached authentication

QA Handover session

Problem statement

1. Identity lookups

   • Shell commands: id, getent but also ls
   • Common call such as:

     ls -l

     can generate huge number of queries SSSD has to handle

   • SSSD already uses cache to optimize performance of identity lookups

2. Authentication

   • Shell commands: su, ssh
   • Authentication is always performed against server
   • Requests generally happen less frequently than identity lookups
   • Growing number of users and servers running under high workload (e.g. when many users log in simultaneously)

   • Logging might take too long

Solution

• Add support for caching!

• New option cached_auth_timeout is introduced
  1. Time (seconds) since last successful on-line login for which the user can authenticate using cached credentials
  2. 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)

Configuration

It is simple!

1. Add cached_auth_timeout to the domain section in sssd.conf
2. Check that option cache_credentials is set to true in the domain section
3. Restart SSSD

Example of sssd.conf

[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
          

Special cases

• Password got changed locally

  • Subsequent login attempt is processed on-line
  • The new password is accepted
  • The old one is denied

• Password got changed directly on server or via other client then SSSD

  • The new password is accepted (Logs inform that cached authentication failed)
  • 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

  • On-line authentication is performed because it cannot be determined whether there was a typo in password or password was changed directly on server
  • 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 sources of information

• SSSD manual pages
• Design page
• Blog post

Thanks

Questions?