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.
Anyway, memberUIDs are still used in many large distributed setups
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
Probably easy. Patches are always welcome.
> dynlist-attrset<group-oc> <URL-ad>
> 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
>> ... 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/