On Wed, 2013-12-25 at 15:27 +0100, Michael Ströder wrote:
Arthur de Jong wrote:
> Additionally, if you plan to use the contents of the tree
> as Unix users and want to have reasonable performance for
> large trees, you should either:
> - use memberUid attributes
> - user member or uniqueMember with user with uid in the DN
I strongly disagree here.
1. memberUid does not allow to use the same group in OpenLDAP ACLs
Also it's not possible to use slapo-refint to check/update the
reference. Furthermore slapo-memberOf only works with DN-based
attributes. This old group scheme should die, die, die.
I know using DNs in groups can have some benefits in some ACLs and
internal LDAP state. Also, these methods allow for group nesting which
can be very convenient in some scenario's. But for external uses of LDAP
data such as Unix groups (posixGroup) the memberUid attribute is much
simpler to handle.
2. As explained many times on this list the LDAP syntax
18.104.22.168.4.1.1422.214.171.124.34 (Name And Optional UID) is seriously
broken - especially when adding the arbitrary UID part behind a DN
with DirectoryString syntax in top-level DN part.
I haven't seen "Name And Optional UID" before. I was talking about
having a DN with the uid attribute in it such as
With the first DN style for users you can extract the uid attribute from
the DN. This has some problems, when e.g. a posixAccount has multiple
uid attributes but that causes so many other nasty side-effects that you
don't want that anyway.
With the second form, you always have to do an extra lookup.
You can cache things, put them in a local database and use something
other than LDAP search queries to search the data but that comes at a
price. Cache lookups have to take into account the lifetime of cached
entries and handle changes in LDAP gracefully (e.g. change uid of an
attribute of a cached entry). In general, caching is difficult to get
right and takes extra resources.
Thanks for your comments,
-- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org/