9

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
db_ch
  • 638
  • 5
  • 14
  • 20
  • 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 – db_ch Feb 02 '17 at 11:46
  • 1
    any chance you logged out and in again in the meantime? – jopasserat Feb 02 '17 at 14:41
  • @jopasserat: I tried that (logout and login) because I know it can play a role but without success. – db_ch Feb 02 '17 at 16:30
  • there is also `newgrp(1)` in addition to the logout dance – thrig Feb 02 '17 at 19:54

2 Answers2

19

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
Slipeer
  • 3,255
  • 2
  • 18
  • 32
  • Yes nscd is present on the system. If it happens again in the future I will check with you proposed answer. – db_ch Feb 02 '17 at 16:31
  • Ok in fact I tried your solution with the same scenario on another user and it seem to have worked ! – db_ch Feb 02 '17 at 16:33
  • 2
    I think the command is actually `sss_cache` – gerard Sep 27 '18 at 19:42
  • 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. – PT Huynh Sep 10 '20 at 09:37
  • 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 https://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 – phzx_munki Feb 10 '21 at 06:45
3

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.

  • Sorry but I tried that before (login and logout). – db_ch Feb 02 '17 at 16:34
  • Your solution may although help other people in the future having a similar problem – db_ch Feb 02 '17 at 16:34
  • I'm surprised to hear that `getent` didn't agree with a fresh login! –  Feb 02 '17 at 16:36
  • 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). – db_ch Feb 02 '17 at 16:38
  • 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` –  Feb 02 '17 at 17:10