Hi,
Few questions regarding dynlist as a replacement of memberof overlay.
Version: 2.5.13+dfsg-2~bpo11+1 on debian bullseye
1) in relatively simple environment (2 servers, multiprovider, syncrepl and keepalived) we've been using memberof overlay - with memberOf explicitly filtered out in syncrepl configuration (exattrs=memberOf). This has been working fine so far across many versions - but considering the warning in slapo-memberof manpage is this overlay used in this fashion safe or are there other issues that eventually might show up ?
2) I've been experimenting a bit with dynlist as a replacement; judging from examples/manual it seems it was primarily created to populate a dynamic group while doing the search over users under a constraint of a filter; but it seems it's working just fine in reverse way as well, e.g. consider:
dynlist config: olcDynListAttrSet = toukPerson labeledURI dgMemberOf
group with manually added members: cn=ADM,ou=TouK,ou=Group,dc=touk,dc=pl a user: uniqueMember=cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl
and relevant attributes in user's entry: objectClass = toukPerson labeledURI = ldap:///ou=TouK,ou=Group,dc=touk,dc=pl??sub?(uniqueMember=cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl)
This seems to be doing what we are expecting - populating dynamically dgMemberOf with the groups the user has membership in. While this is working, is it ok to use this overlay in this fashion (search over groups instead of over users) ?
3) my last question is more of a curiosity - what case scenario are for additional [+<memberOf-ad>[@<static-oc>[*]]] attributes ? No matter what I tried in what way, neither +memberOf-ad nor +static-oc had any effect whatsoever.
On 2/28/23 17:12, Michal Soltys wrote:
Hi,
Few questions regarding dynlist as a replacement of memberof overlay.
With a few more experiments and shuffling through posts on openldap-technical@ (gotta say that the case where the 2nd parameter - search query - is ignored was a surprise) I got everything working. Some examples for few scenarios in the manual page would do wonders (I could submit a diff later).
I found maybe one bug (as of 2.5.13) - consider following configuration:
{0}toukPerson labeledURI uniqueMember+memberOf@groupOfUniqueNames {1}groupOfURLs memberURL uniqueMember+dgMemberOf@groupOfUniqueNames
The {0} entry (where labeledURI is ignored) will correctly populate the memberOf relatively to static membership. Basically a drop-in memberOf overlay replacement.
The {1} entry will produce dgMemberOf with dynamic group membership correctly (based on memberURL query) but it will not populate static entries IF {0} entry in configuration is present. IF I remove {0} from the dynlist configuration, then both dynamic and static entries will be populated.
So the effects are as follows on some user entry:
if both {0} and {1} are present:
memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
if both {0} and {1} are present and @groupOfUniqueNames is removed from {0}:
dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
If only {1} is present:
dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
For completness - if only {0} is present:
memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
I would expect this behavior to be correct for the first case - {0} and {1}.
memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
openldap-technical@openldap.org
-
Michal Soltys