Questions about the sssd cache and its behaviour

Latest response

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.

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.

Hi Joerg, The SSSD local password cache, if enabled, is only used when the service URI is marked offline. If the service is online, the password as well as lockout status, etc, are all validated against the directory. This offline password cache time is tune-able parameter.

If there are locally created accounts, it is best to add the appropriate users/ groups to the ignore sections of the sssd.conf.

Joe

Hello Joe,
Are you sure that the local password cache is only used in case the backend identity provider is offline?

That maybe true for the local offline cache but not for the general local sssd cache. Section 7.1.2. in the System Level Authentication Guide says:

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.

So for information which are stored in the local cache and which are not invalid yet, the SSSD would not check the backend directory service.

Best regards,
Joerg

Hi Jörg,

You already got some valuable comments from our colleagues.

In my view, this worked best and without any glitches in one special environment:

a) All applications run through local accounts exclusively - no dependency on remote authentication services.

b) All application accounts have been locked (no passwords, and no direct access to them).

c) Direct access to those accounts is disabled via /etc/security/access.conf and PAM configurations.

d) All support teams log in via centralized services (AD, LDAP). They do not have any special privileges and the accounts and groups are specifically set in /etc/security/access.conf.

e) There are special AD groups in SUDO configs which potentially allow access to a specific application when approved.

By default, those AD groups contain no members! In other words, nobody can SUDO to application accounts.

f) To access application, one has to get approval to be added to a specific AD group, which is part of an automated workflow.

g) Once the given user becomes a member of that AD group, they can login with their own account, and then SUDO to an application account.

All access (including keystrokes) is audited and centralized on remote servers with machine learning capabilities....

SSSD works well for normal, non-frequent operations but I would not advise it for applications.

Regards,

Dusan Baljevic (amateur radio VK2COT)

Good Morning Dusan,

Thanks for your Answer.

d) All support teams log in via centralized services (AD, LDAP). They do not have any special privileges and >the accounts and groups are specifically set in /etc/security/access.conf. [...] SSSD works well for normal, non-frequent operations but I would not advise it for applications.

So, do you use SSSD for th AD/LDAP integration or do you use something else to provide access for your support teams?

Best regards, Joerg

Hi Jörg,

Yes, SSSD is used for AD/LDAP integration across many systems, from Dev to Prod. It works perfectly well.

One important statement to be careful about options like " dyndns_update" (default in sssd config).

This is what I witnessed at another organisation:

  1. Build a new VM.

  2. Find DNS records for an important server.

  3. Change hostname of the new VM to be identical to the important server’s hostname.

  4. Join AD domain with “dyndns_update = True” option in SSSD config.

  5. Verify DNS: Unprotected DNS allowed update of records for important server!

The point of this exercise: By human error, or deliberately, anyone with domain rights could overwrite DNS resource records via script or various tools because DDNS was allowed by design.

Regards,

Dusan Baljevic (amateur radio VK2COT)