6:13 a.m.
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
3:02 p.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7:51 a.m.
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.
>
7:26 a.m.
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.
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7:49 a.m.
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.
9:03 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9:24 a.m.
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.
2:17 p.m.
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.
472
days inactive
474
days old
openldap-technical@openldap.org
7 comments
3 participants
participants (3)
-
Alceu Rodrigues de Freitas Junior -
Howard Chu -
Michael Ströder