MGM : secondary groups with sssd and LDAP backend, enumeration and user information caching

Hi Franck,

To answer your initial first question: there is nothing special that EOS does in this case, but it’s the way getgrent and sssd work together. As you correctly determined the solution is to enable enumeration in the sssd configuration. There is also an issue about this in the Red Hat forum as you can see in the snippet below, where they recommend the exact same solution as you found out:

Concerning the second question about caching of uid/gid values. That is also true, in EOS in the eos::common::Mapping functionality we use a cache with a 1h expiration for already resolved uid/gid/username pairs so that we alleviate the pressure on sssd - we’ve seen in the past that it can lead to considerable slowdown or even crashes when there are many requests handled by sssd. You can reset this cache information but using the:
eos space reset default --mapping.
The mapping is not actually connected to any space, but it’s global!

Let me know if this answers your questions.

Cheers,
Elvin