Greetings,
For a matter of studying OpenLDAP, I decided to create a CLI in Golang that is based on the migrationtools (https://gitlab.com/future-ad-laboratory/migrationtools), which is written in Bash and (very old) Perl code.
All the Golang module is available here: https://github.com/glasswalk3r/aprendendo-openldap/tree/main/migration.
After learning about the memberof overlay, I've being wondering if it is possible to use it to maintain the UNIX groups at /etc/group instead of just replicating the same information over an over.
I've tried to find references in the documentation of using PAM and NSCD in the Linux clients for authenticating from a OpenLDAP server, but found nothing regarding those requirements, neither a detailed explanation (without resorting looking into the source code) of how those requests from a Linux client would be sent to OpenLDAP in order to check that.
If any has any pointers on the subject, I would be glad to receive them.
Thanks in advance,
Alceu
Alceu Rodrigues de Freitas Junior wrote:
Greetings,
For a matter of studying OpenLDAP, I decided to create a CLI in Golang that is based on the migrationtools (https://gitlab.com/future-ad-laboratory/migrationtools), which is written in Bash and (very old) Perl code.
All the Golang module is available here: https://github.com/glasswalk3r/aprendendo-openldap/tree/main/migration.
After learning about the memberof overlay, I've being wondering if it is possible to use it to maintain the UNIX groups at /etc/group instead of just replicating the same information over an over.
I've tried to find references in the documentation of using PAM and NSCD in the Linux clients for authenticating from a OpenLDAP server, but found nothing regarding those requirements, neither a detailed explanation (without resorting looking into the source code) of how those requests from a Linux client would be sent to OpenLDAP in order to check that.
If any has any pointers on the subject, I would be glad to receive them.
Thanks in advance,
Alceu
You don't need memberOf to maintain /etc/group info in LDAP.
I guess I failed to express myself properly.
I do know memberOf is not a requirement: regular exporting data from /etc/passwd, /etc/shadow and /etc/group as LDIF files are working as expected.
But wouldn't it be a better option to use it instead of handling data in multiple places (users and groups) instead of just the groups entries in the tree?
At least this is my understanding regarding the usefulness of memberOf. Not sure either if that would become a performance issue.
Em 20/08/2022 19:02, Howard Chu escreveu:
You don't need memberOf to maintain /etc/group info in LDAP.
Alceu Rodrigues de Freitas Junior wrote:
I guess I failed to express myself properly.
I do know memberOf is not a requirement: regular exporting data from /etc/passwd, /etc/shadow and /etc/group as LDIF files are working as expected.
But wouldn't it be a better option to use it instead of handling data in multiple places (users and groups) instead of just the groups entries in the tree?
The PAM/NSS functions for interacting with LDAP already know how to efficiently check membership of a user in a group, without using memberOf attribute.
To check if a user is a member of a specific group, one merely needs to do an LDAP Compare on the group, against member:<user>. To see all members of a group, one just needs to retrieve the group entry.
The memberOf attribute has zero relevance here.
At least this is my understanding regarding the usefulness of memberOf. Not sure either if that would become a performance issue.
Em 20/08/2022 19:02, Howard Chu escreveu:
You don't need memberOf to maintain /etc/group info in LDAP.
On 8/21/22 16:51, Alceu Rodrigues de Freitas Junior wrote:
I do know memberOf is not a requirement: regular exporting data from /etc/passwd, /etc/shadow and /etc/group as LDIF files are working as expected.
But wouldn't it be a better option to use it instead of handling data in multiple places (users and groups) instead of just the groups entries in the tree?
At least this is my understanding regarding the usefulness of memberOf. Not sure either if that would become a performance issue.
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. ;-)
Ciao, Michael.
Michael Ströder wrote:
On 8/21/22 16:51, Alceu Rodrigues de Freitas Junior wrote:
I do know memberOf is not a requirement: regular exporting data from /etc/passwd, /etc/shadow and /etc/group as LDIF files are working as expected.
But wouldn't it be a better option to use it instead of handling data in multiple places (users and groups) instead of just the groups entries in the tree?
At least this is my understanding regarding the usefulness of memberOf. Not sure either if that would become a performance issue.
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.
You can just search for all groups where member=<user>, returning no attributes, or returning only cn and gidNumber. Again, memberOf is not helpful here and no other extensions are needed.
On 8/22/22 18:03, Howard Chu wrote:
You can just search for all groups where member=<user>, returning no attributes, or returning only cn and gidNumber. Again, memberOf is not helpful here and no other extensions are needed.
Of course slapo-memberof is not *needed* for this.
But in some specific cases extensions like slapo-memberof and/or slapo-deref can improve performance. As usual YMMV and of course you have to know what you're doing. Otherwise it's only wasteful over-engineering.
Ciao, Michael.
Hello Michael,
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:
https://tylersguides.com/guides/openldap-memberof-overlay/
"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. ;-)
Ciao, Michael.
openldap-technical@openldap.org
-
Alceu Rodrigues de Freitas Junior -
Howard Chu -
Michael Ströder