Questions about the sssd cache and its behaviour
SSSD cache related questions
Good Morning,
The System Level Authentication Guide says in chapter 7.1.2. that one bennefit of using sssd is:
Reduced load on identity and authentication servers
When requesting information, SSSD clients contact SSSD, which checks its cache. SSSD contacts the servers only if the information is not available in the cache.
I think this refers to the entry_cache_timeout (integer) parameter. Man sssd.conf(5) describes it as follows:
How many seconds should nss_sss consider entries valid before asking the backend again
The cache expiration timestamps are stored as attributes of individual objects in the cache. Therefore, changing the cache timeout only has effect for newly added or expired entries. You should run the sss_cache(8) tool in order to force refresh of entries that have already been cached.Default: 5400
So, if a user authenticated successfully against a back end this information will be stored for 5400 secondes in the so called "entry cache". If the user tries to authenticate again sssd would lookup this information in its cache instead. Only after 5400 seconds sssd would ask the back end again. Did I get this right?
Does this mean, when I lock or delete a user in a back end system that this user will be able to authenticate to a local system as long as its entry in the "entry cache" is still valid?
If my understanding is correct the "entry cache" is different from the "offline cache" which could be enabled by setting cache_credentails on TRUE. So do I have to deal with to different types of caches here?
What are youre experiences with the offline authentication?
When we setup an user account to run some service, today, we create a user in our central authentication system and create a local system account with the same UID and GID. This way we could ensure that {U|G}IDs are unique throuout our infrastructure but our services stay up and running if the authentication backend is not available.
On the downside we have to use configuration management to remove a local system account from all machines where it exists when the central account is removed.
Offline authentication for sssd seems to make things a little bit easier around here. What are your experiences with it? Do you use offline authentication? Does it work great? Or is it a pain in the ass?
Best regards,
Joerg K.
Responses
Jorg,
My experiences with offline authentication, and SSSD cache in general have been pretty average. If it's working it seems unpredictable, and when it's not working, it's breaking legitimate logins to the directory even when the AD servers are available. I disable the offline authentication altogether and limit the cache, where possible. The architecture of SSSD appears to depend on the cache so turning it off all together isn't really an option unfortunately.
Many of the cache problems i've seen manifest when the servers have been up for extended periods of time, and they are generally inconsistent and difficult to troubleshoot so I haven't had much success raising bug tickets to narrow down issues (you will find some posts on this discussion forum of me discussing SSSD issues).
As for accounts that run services (that I create locally) I find these service accounts are best managed through a configuration management tool, be it Ansible or Puppet (or whatever your configuration management choice is) and the accounts are created/removed as part of application roles/profiles that are being configured for the server. In this scenario, even though these accounts aren't in a central directory, they are centrally managed.
Another pattern for this is to have the application in a container, which ships with all the user account requirements bundled..this doesn't really relate to this SSSD topic, but definitely seeing more sites moving to this model.
Expert
1223 points
Hi, Thanks for your answer.
As I understand from this answer and other sssd related threads in this community forum running sssd is far from operating without issues. For me it does not seem to be a sophisticated service daemon as it should be. I'll keep your answer in mind while making further experiences.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.