Does Linux keeps a cache of groups members if on LDAP ? (Difference between groups vs getent group))

Question

Our users and groups LDAP configuration is working.

Our server is using LDAP to store users and groups.

# /etc/nsswitch.conf :
passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap

But today we added a new group in LDAP, with 3 users, and then, added other users. The 3 users are in the group but not the others.

We can see this by using the "groups " : more precisely, "getent group GROUPNAME" shows the user in the group while "groups " does not show the group for that user... ?!

Therefore I am trying to understand :

• Is there some kind of cache for groups - LDAP list ?
• Or is it possible for the synchronization to fail, if yes how to manually re-launch it ?

Sorry not to be more precise in my question, but I really don't see where to start...

P. S. Config files

# /etc/ldap/ldap.conf
URI     ldap://172.16.1.232
TLS_CACERT      /etc/ssl/certs/ca-certificates.crt


# /etc/pam_ldap.conf
base dc=ourdomain,dc=ch
uri ldap://172.16.1.232/
ldap_version 3
rootbinddn cn=admin,dc=ourdomain,dc=ch
pam_password crypt

Solution 1

pam_ldap and nsswitch have no caching mechanisms, but nscd or sssd may be present on your system that implement cache.

To invalidate / flush nscd groups cache use:

sudo nscd --invalidate=group

To invalidate / flush sssd groups cache use:

sudo sss_cache -G

Solution 2

jopasserat's comment leads to another possible answer.

The groups command doesn't report group memberships of a user. It reports the group ID privileges of the current process. It only uses NSS to convert numeric group IDs to names.

When a user logs in, the group memberships are obtained from NSS, and the setgid and setgroups system calls are used to give the correct privileges to the user's initial process. All processes descended from there inherit the same privileges (except when a set-id program is executed).

If the configured privileges change, while the user is logged in, the existing processes are not affected. You have to log out and in again to gain privileges, and if you're trying to revoke privileges, you have to kill all of the user's processes to finish the job.

nscd and such can add extra layers of cache to worry about, but pre-existing user processes are effectively a privilege cache that is present in all configurations.

Comments

[db_ch]

P. S. After some time, now everything is OK. But I am still puzzled about what happened and would be happy if someone could answer that question. And I am sure it could help other people

[jopasserat]

any chance you logged out and in again in the meantime?

[db_ch]

@jopasserat: I tried that (logout and login) because I know it can play a role but without success.

[thrig]

there is also newgrp(1) in addition to the logout dance

[db_ch]

Yes nscd is present on the system. If it happens again in the future I will check with you proposed answer.

[db_ch]

Ok in fact I tried your solution with the same scenario on another user and it seem to have worked !

[db_ch]

Sorry but I tried that before (login and logout).

[db_ch]

Your solution may although help other people in the future having a similar problem

[Admin]

I'm surprised to hear that getent didn't agree with a fresh login!

[db_ch]

Yes I can confirm it was the case. The solution was solved with "nscd --invalidate=group"... I can reproduce the case (I just did again before commenting).

[Admin]

Maybe getent bypasses nscd then. It looks like I don't really know what's going on. I'll leave this answer here anyway, since it provides another reason getent might disagree with groups

[gerard]

I think the command is actually sss_cache

[PT Huynh]

I found that even sss_cache -E or stop sssd service, getent command still can retrieve info from cache. That is the NSCD cache. nscd --invalidate clear NSCD cache. Thanks.

[phzx_munki]

My experience in RHEL 6, 7, and up to 8.1 indicates that "sss_cache -E" (or "sss_cache -G") may not work. (Since I run sssd, I don't run nscd or nslcd.) As reported in this open issue at GitHub github.com/SSSD/sssd/issues/4872 the way for the cache to be really cleaned out is to: systemctl stop sssd ; rm /var/lib/sss/db/cache_default.ldb ; systemctl start sssd