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
Show replies by date