Pierangelo Masarati pisze:
You can't put in the filter information that has to be generated dynamically, like dynamic group membership. Or, you could, but then any search would need to be split into:
- search the whole database for (objectClass=*) to trigger dynamic
expansion of data; then
- search the (at this point, unindexed) dynamically generated data.
This could be implemented, but probably it's not what users want...
I thought that it works exactly like this, and I think this is what users want and expect (e.g. see the post "Dynamic Group overlay with ldapsearch for uniquemember oddity" from march 2006 by Michael Heep).
Groups are almost unusable if they don't work both ways since the necessary operations for a group-based authorization subsystem are both: mapping a group to member users and mapping a user to groups he's a member of.
For example, see Zope/Plone LDAP Multi Plugin (http://plone.org/products/ploneldap): it needs the following functionalities for LDAP groups to work properly (the names should be self-explanatory): enumerateGroups, getGroupsForPrincipal, enumerateUsers.
I believe that nss_ldap also does both types of search.
I imagined that OpenLDAP maintained a cache for dynamic groups (that's how I understood "this exploits slapd group caching capabilities" in the FAQ) in order to do a search on (member=member'sDN). Such a cache would only need updating in only two cases:
1. when there's a change in an object's DN if the object has an attribute used in any memberURL 2. when there's a change in any object in any attribute that's used in a filter in any memberURL in the directory (sorry for convoluted sentence, but it's a convoluted subject...).
When I think about it, this data should be permanent, so it should be kept in an index, not in memory cache.
Yes, there's some complex logic involved here (e.g. there needs to be a list kept updated with names of all the attributes that are used in memberURL filters) and it cannot posibly work for non-local memberURLs (those that specify a different LDAP server). But this is theoretically possible and would make dynlist usable for group memberships, not only for mail aliases (like currently).