Thanks for your answer.
In fact I was wondering if I could avoid having to maintain membership at two different classes (posixAccount and posixGroup) with memberOf instead of performance reasons, but accordingly to this link:
"If you are trying to use memberOf with posixGroups, there isn’t an easy way to do it. This is because the posixGroups memberUid attributes don’t use DNs, which is required by the overlay."
It indeed cannot be done. I guess I won't need to further develop my migration helper. :-)
Em 22/08/2022 11:49, Michael Ströder escreveu:
Not sure I really understand what you're after but I give it a try:
With POSIX groups besides determining user's group membership you also have to read some POSIX group attributes like cn and gidNumber from the LDAP posixGroup entry.
Simple NSS clients can build the passwd and group maps by just reading all posixGroup and posixAccount entries at once (full enumeration).
This might not work in bigger environments with several ten thousand of also possibly very large groups. So some NSS clients allow to disable enumerating the whole maps and try to read data just when needed. In such a situation it can be useful to make use of memberOf attribute, e.g. when determining the group membership of a single user, to avoid having to read the full and possible very big group entries. Together with slapo-deref the NSS client can also read the group entries' POSIX attribute gidNumber referenced by user entry in one round-trip.
Note that disabling full enumeration might not work with some stupid software which always expects to see the full passwd and groups maps.
Personally with Æ-DIR's aehostd I'm using 'memberOf' attribute to select the users made visible for host groups by their group membership (while still doing full enumeration). But that's done for avoiding too much ACL processing: https://www.stroeder.com/publications.html#ldapcon2019
Not sure whether that all makes sense to you though. ;-)