Are there any plans to extend the dynlist overlays dynamic group feature to return not the DNs of the matched entries but an attribute of the entries?
This would be useful for defining dynamic groups based on posixGroup (which need only the username, not the full DN) and populating them with entries from posixAccounts.
If the dynlist-attrset could be extended by one parameter like:
dynlist-attrset <group-oc> <URL-ad> [<member-ad>] [<result-ad>]
... where the additional parameter specifies the attribute that should be returned from the search results, a dynamic posixGroup could be configured like that:
dynlist-attrset myposixGroup memberURL memberUid uid
with a search filter like that:
ldap:///ou=users,dc=local,dc=site??sub?(&(objectClass=posixAccount)(<searchfilter>))
I.e. "take the uid attribute of the matched entries and add them as memberUid."
Could this extension be easily implemented?
Is there currently any workaround? E.g. a way to dynamically add a memberUid to each posixAccount that contains the same data as the uid attribute? If that works, a filter like ldap:///ou=users,dc=local,dc=site?memberUid?sub?(&(objectClass=posixAccount)(<searchfilter>)) ... could work.
Thanks in advance, --leo
On Thu, Sep 24, 2009 at 08:00, Alexander 'Leo' Bergolth leo@strike.wu.ac.at wrote:
Are there any plans to extend the dynlist overlays dynamic group feature to return not the DNs of the matched entries but an attribute of the entries?
That's possible already.
Taken from the OpenLDAP Admin guide (http://www.openldap.org/doc/admin24/overlays.html#Dynamic%20Lists):
overlay dynlist dynlist-attrset nisMailAlias labeledURI
cn=all,ou=aliases,dc=example,dc=com cn: all objectClass: nisMailAlias labeledURI: ldap:///ou=People,dc=example,dc=com?mail?one?(objectClass=inetOrgPerson)
And here the drawing of the end result when fetching the above "cn=all" entry:
http://www.openldap.org/doc/admin24/allmail-en.png
So, for your case, just change the configuration accordingly
On 09/24/2009 03:01 PM, Andreas Hasenack wrote:
On Thu, Sep 24, 2009 at 08:00, Alexander 'Leo' Bergolth leo@strike.wu.ac.at wrote:
Are there any plans to extend the dynlist overlays dynamic group feature to return not the DNs of the matched entries but an attribute of the entries?
That's possible already.
Taken from the OpenLDAP Admin guide (http://www.openldap.org/doc/admin24/overlays.html#Dynamic%20Lists):
overlay dynlist dynlist-attrset nisMailAlias labeledURI cn=all,ou=aliases,dc=example,dc=com cn: all objectClass: nisMailAlias labeledURI:ldap:///ou=People,dc=example,dc=com?mail?one?(objectClass=inetOrgPerson)
That's not what I was looking for. This approach takes the "mail" attribute out of an inetOrgPerson entry and adds it to the nisMailAlias, again as a "mail" attribute.
In my example I need to get the "uid" attribute out of a posixAccount element and add it to the posixGroup as a _"memberUid"_ attribute. In other words, the target attribute is named differently from the source attribute.
That's why I suggested the extended syntax like
dynlist-attrset <group-oc> <URL-ad> [<member-ad>] [<result-ad>] i.e.: dynlist-attrset myposixGroup memberURL memberUid uid
Cheers, --leo
Alexander 'Leo' Bergolth wrote:
Are there any plans to extend the dynlist overlays dynamic group feature to return not the DNs of the matched entries but an attribute of the entries?
As Andreas already posted, this has been a dynlist feature for a long time.
Could this extension be easily implemented?
Is there currently any workaround?
Use RFC2307bis. posixGroups with memberUid are deprecated.
E.g. a way to dynamically add a memberUid to each posixAccount that contains the same data as the uid attribute? If that works, a filter like ldap:///ou=users,dc=local,dc=site?memberUid?sub?(&(objectClass=posixAccount)(<searchfilter>)) ... could work.
On 09/24/2009 08:43 PM, Howard Chu wrote:
Alexander 'Leo' Bergolth wrote:
Are there any plans to extend the dynlist overlays dynamic group feature to return not the DNs of the matched entries but an attribute of the entries?
As Andreas already posted, this has been a dynlist feature for a long time.
As explained in my previous mail, this functionality isn't covered yet for posixGroups memberUid style setups.
Could this extension be easily implemented?
Is there currently any workaround?
Use RFC2307bis. posixGroups with memberUid are deprecated.
Even RFC2307bis says "either ... or", AFAIK it doesn't contain any valuation which one is preferred:
It is suggested that uid and cn are used as the naming attribute for posixAccount and posixGroup entries, respectively. Group members may either be login names (values of memberUid) or dis- tinguished names (values of uniqueMember).
E.g. samba recommends to use smbldaptools for managing Users and Group, which cannot handle uniqueMembers.
Anyway, memberUIDs are still used in many large distributed setups that cannot be easily migrated to uniqueMember style groups without major modifications to all components involved.
So how do you estimate the complexity of adding this extension to dynlist-attrset?
dynlist-attrset <group-oc> <URL-ad> [<member-ad>] [<result-ad>] i.e.: dynlist-attrset myposixGroup memberURL memberUid uid
E.g. a way to dynamically add a memberUid to each posixAccount that contains the same data as the uid attribute? If that works, a filter like ldap:///ou=users,dc=local,dc=site?memberUid?sub?(&(objectClass=posixAccount)(<searchfilter>))
... could work.
Or maybe another workaround could be to first add the user-account DN to the memberUid attribute using existing dynlist features and then rewrite it's value by extracting the username out of the DN using another overlay? Would this be a realistic approach?
Cheers, --leo
Alexander 'Leo' Bergolth wrote:
On 09/24/2009 08:43 PM, Howard Chu wrote:
Use RFC2307bis. posixGroups with memberUid are deprecated.
Even RFC2307bis says "either ... or", AFAIK it doesn't contain any valuation which one is preferred:
It is suggested that uid and cn are used as the naming attribute for posixAccount and posixGroup entries, respectively. Group members may either be login names (values of memberUid) or dis- tinguished names (values of uniqueMember).E.g. samba recommends to use smbldaptools for managing Users and Group, which cannot handle uniqueMembers.
uniqueMember is also deprecated.
http://www.ietf.org/id/draft-howard-rfc2307bis-02.txt
Section 5.2
Anyway, memberUIDs are still used in many large distributed setups that cannot be easily migrated to uniqueMember style groups without major modifications to all components involved.
So how do you estimate the complexity of adding this extension to dynlist-attrset?
Probably easy. Patches are always welcome.
dynlist-attrset<group-oc> <URL-ad> [<member-ad>] [<result-ad>] i.e.: dynlist-attrset myposixGroup memberURL memberUid uid
E.g. a way to dynamically add a memberUid to each posixAccount that contains the same data as the uid attribute? If that works, a filter like ldap:///ou=users,dc=local,dc=site?memberUid?sub?(&(objectClass=posixAccount)(<searchfilter>))
... could work.
Or maybe another workaround could be to first add the user-account DN to the memberUid attribute using existing dynlist features and then rewrite it's value by extracting the username out of the DN using another overlay? Would this be a realistic approach?
The rewrite overlay only operates on DN-valued attributes. I don't recall if rewriting occurs before or after attribute mapping; if it occurs after then it would not work.
On 09/25/2009 10:40 AM, Alexander 'Leo' Bergolth wrote:
On 09/24/2009 08:43 PM, Howard Chu wrote:
Alexander 'Leo' Bergolth wrote:
Are there any plans to extend the dynlist overlays dynamic group feature to return not the DNs of the matched entries but an attribute of the entries?
As Andreas already posted, this has been a dynlist feature for a long time.
As explained in my previous mail, this functionality isn't covered yet for posixGroups memberUid style setups.
For the records: Actually it seems to be implemented since 2.4.9:
Added slapo-dynlist mapping to dynamic attrs generation (ITS#5466)
http://www.openldap.org/lists/openldap-bugs/200804/msg00087.html
I managed to configure a dynamic posixGroup using the following settings:
-------------------- 8< -------------------- dn: olcOverlay={0}dynlist,olcDatabase={1}bdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig olcOverlay: {0}dynlist olcDlAttrSet: {0}posixGroup labeledURI memberUid:uid -------------------- 8< --------------------
This leads to a remap of uid attributes to memberUid attributes in the dynamic posixGroup.
Now we just have to define a search filter in the labeledURI attribute of the posixGroup: -------------------- 8< -------------------- dn: cn=testposixgroup,ou=LDAPgroups,dc=wu-wien,dc=ac,dc=at objectClass: labeledURIObject objectClass: posixGroup objectClass: top cn: testposixgroup gidNumber: 9999 labeledURI: ldap:///dc=wu-wien,dc=ac,dc=at?uid?sub?(&(objectclass=posixAccount)(testattr=1)) -------------------- 8< --------------------
Cheers, --leo
openldap-technical@openldap.org
-
Alexander 'Leo' Bergolth -
Andreas Hasenack -
Howard Chu