[SSSD-users] Group cache entry of removed member in be

[Thomas HUMMEL]

Hello,

sssd-2.3.0 on RHEL/CentOS 8.3, I'm trying to figure out how refreshing a 
user cache entry could impact (or not) a group entry this user is or has 
been a member of in the backend

I'm using sssd-2.3.0 on RHEL/CentOS 8.3 with

     auth_provider = ldap
     ldap_schema = AD
     access_provider = ldap
     id_provider = ldap

authselect provides the following setup of nsswitch:

     passwd:     sss files systemd
     group:      sss files systemd

Initial experience on *some* hosts using the same sssd config:

a user <user> which has been for some time (greater than any sssd 
timeout) removed from group <group> in the AD backend still appeared as 
a member when running getent group <group>

"refreshing" this user with getent passwd <user> would fix the issue

I don't quite get the reasoning behind this behavior.
Does the link between the 2 actions lies in the ghost/unghost mechanism ?

I did not manage to reproduce it. The tests I made on another similar 
host raised some more questions though:

a) I was able to verify the expected behavior of 
entry_cache_group_timeout (or entry_cache_timeout for that matter): 
after 1h30m getent group <group> would get the group entry from the 
backend. Before that result were fed by the cache and could not be 
consistent with the backend

b) I'm having trouble understanding how sss_cache -u or -g works as, 
using ldbsearch -H <cache_ldb_file> I can see the dataExpireTimestamp 
set to 1 but after what I thought would be a refresh (getent passwd or 
group), I still see this value : is this because sssd RAM cache is not 
sync'ed ?

Finally, do you confirm that the setting of ldap_purge_cache_timeout 
should not change how the membership of a user in a group is return ?

Thanks for you help

--
Thomas HUMMEL