Just a note that sss_cache does not remove anything from sssd cache. It only invalidates entries there.

BTW I think you did not wait sufficient time for next enumeration which would remove user from cache.

man sssd-ldap says:

       ldap_enumeration_refresh_timeout (integer)
           Specifies how many seconds SSSD has to wait before refreshing its
           cache of enumerated records.
           Default: 300
       ldap_purge_cache_timeout (integer)
           Determine how often to check the cache for inactive entries (such
           as groups with no members and users who have never logged in) and
           remove them to save space.
           Setting this option to zero will disable the cache cleanup
           operation. Please note that if enumeration is enabled, the cleanup
           task is required in order to detect entries removed from the server
           and can't be disabled. By default, the cleanup task will run every
           3 hours with enumeration enabled.
           Default: 0 (disabled)

Looking at the very low ID of the user, I wonder if the user who is still showing up comes from the LDAP domain or the files/proxy domain? Because I saw some strange things with enumeration and the files domain, but I didn't file even a ticket so far..

@jhrozek: The userid 516 is ok, all users from passwd are below 500 and users from ldap are starting with 500.

@lslebodn: Yes when I'm set ldap_purge_cache_timeout to a low value (e.g. 5) the deleted testuser1 vanishes from enumeration shortly after it is not reachable via getent passwd testuser1. My questions now:

Is it useful to set ldap_purge_cache_timeout to 5 sec?
Is there a command to clear enumeration cache in sssd manually like sss_cache -E?

@lslebodn: Yes when I'm set ldap_purge_cache_timeout to a low value (e.g. 5) the deleted testuser1 vanishes from enumeration shortly after it is not reachable via getent passwd testuser1. My questions now:
Is it useful to set ldap_purge_cache_timeout to 5 sec?

It depends on your use-case. But usually it should be enough to wait maximall y 300 seconds for next enumeration.

I am not sure why do you want to purge users from cache so fast. Maybe it would help to describe use-case and not intermediate steps.

On the other side, if 5 seconds to periodic clean-up task does not cause any problem(hight load, slow response ...) then I cannot see any issue with using it.

Is there a command to clear enumeration cache in sssd manually like sss_cache -E?

Unfortunately, no.

I am not sure why do you want to purge users from cache so fast. Maybe it would help to describe use-case and not intermediate steps.

The use-case: I have a GUI user administration tool, which shows all enumerated users (glibc function getpwent is used). In this application users can be deleted or created on the ldap server (ldapmodify calls are used). The problem is now, that when you e.g. delete a user via the gui, this user is still in the users list. Here would it be very nice, if I can invalidate the enumeration cache after deleting the user on the server.
Some would suggest now to use ldapsearch for building the user list: This is problematic, because the tool has also a "read-only-mode", where no direct ldap access to the server exists.

My workaround solution would be: Stopping sssd, removing all /var/lib/sss/db/* and starting sssd again.

I am not sure why do you want to purge users from cache so fast. Maybe it would help to describe use-case and not intermediate steps.

The use-case: I have a GUI user administration tool, which shows all enumerated users (glibc function getpwent is used). In this application users can be deleted or created on the ldap server (ldapmodify calls are used). The problem is now, that when you e.g. delete a user via the gui, this user is still in the users list. Here would it be very nice, if I can invalidate the enumeration cache after deleting the user on the server.
Some would suggest now to use ldapsearch for building the user list: This is problematic, because the tool has also a "read-only-mode", where no direct ldap access to the server exists.
My workaround solution would be: Stopping sssd, removing all /var/lib/sss/db/* and starting sssd again.

Thank you very much for explanation. I cannot image more suitable and reliable workaround for your use-case.

BTW such approach for user administration tool will not scale. it take some time do download 1000+ users for sssd.

BTW guys in 389-ds (one of implementation of LDAP server) are doing GUI for management os entries which will be part of Cockpit. It is not ready. But you can ask them about timeframe or help them :-)

I know it is a little bit off-topic. But at least you will know about such effort :-)

https://pagure.io/389-ds-base/issues?status=Open&search_pattern=ockpit

Thank you for your hints, Cockpit is interesting, but a little to fat. The use of my GUI is up to 100 users. You helped me and I think I will set ldap_purge_cache_timeout to 5 sec.
The reason for this issue is, that it is not obvious why getent passwd testuser and getent passwd | grep testuser different results have

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4649

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.