4 a.m.
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
--
e-mail ::: Leo.Bergolth (at) wu.ac.at
fax ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria
6:01 a.m.
On Thu, Sep 24, 2009 at 08:00, Alexander 'Leo' Bergolth
<leo(a)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
9:09 a.m.
On 09/24/2009 03:01 PM, Andreas Hasenack wrote:
On Thu, Sep 24, 2009 at 08:00, Alexander 'Leo' Bergolth
<leo(a)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
--
e-mail ::: Leo.Bergolth (at) wu.ac.at
fax ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria
11:43 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1:40 a.m.
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
--
e-mail ::: Leo.Bergolth (at) wu.ac.at
fax ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria
3:02 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:41 a.m.
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
--
e-mail ::: Leo.Bergolth (at) wu.ac.at
fax ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria
5109
days inactive
5178
days old
openldap-technical@openldap.org
6 comments
3 participants
participants (3)
-
Alexander 'Leo' Bergolth -
Andreas Hasenack -
Howard Chu