Full_Name: Quanah Gibson-Mount Version: 2.3 and higher OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) The slapo-memberOf overlay is not safe to use in a replicated environment due to the way in which replication occurs. In particular, slapo-memberOf works fine as long as all user objects are created before any group objects. As soon as there are user objects that are members of a group where the user object was created after the group, breakage will occur if any consumer falls back into REFRESH mode. This is particularly trivial to reproduce by simply setting up a new empty consumer and allowing it to populate via REFRESH. This limitation should be clearly noted in the man page and the admin guide documentation. It is possible to set up slapo-dynlist to operate as a replacement for slapo-memberOf, and it is safe in a replicated environment. The tricky part of using slapo-dynlist is that membership information must be maintained by updating user objects rather than by updating group objects, which may be difficult for end users depending on how they perform group management. Example configuration: .... include "/opt/symas/etc/openldap/schema/memberof.schema" include "/opt/symas/etc/openldap/schema/dyngroup.schema" .... moduleload dynlist.la .... database mdb .... index memberOf ... overlay dynlist dynlist-attrset groupOfUrls memberURL member Then in the database: dn: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com objectClass: memberOfOC memberOf: cn=testgroup,ou=Group,dc=example,dc=com root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com cn=testgroup dn: cn=testgroup,ou=Group,dc=example,dc=com objectClass: groupOfURLs cn: testgroup memberURL: ldap:///dc=example,dc=com??sub?(memberOf=cn=testgroup,ou=Group,dc=e xample,dc=com) member: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com The memberOf schema I came up with on the fly. It would need a different OID for the objectClass, and possibly a different objectClass name, as I stole those from ppolicy for testing purposes: attributetype ( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that the entry belongs to' EQUALITY distinguishedNameMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' ) objectclass ( 1.3.6.1.4.1.42.2.27.8.2.1 NAME 'memberOfOC' SUP top AUXILIARY MUST ( memberOf ) )
quanah@openldap.org wrote: > root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H > ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com cn=testgroup > dn: cn=testgroup,ou=Group,dc=example,dc=com > objectClass: groupOfURLs > cn: testgroup > memberURL: ldap:///dc=example,dc=com??sub?(memberOf=cn=testgroup,ou=Group,dc=e > xample,dc=com) > member: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com For this particular use-case it would be nice if memberURL could automagically reference the group entry itself. Something similar to the set syntax: memberURL: ldap:///dc=example,dc=com??sub?(memberOf=*this/entryDN*) Well, a simple plugin class in web2ldap will also do... :-) Ciao, Michael.
--On Thursday, March 09, 2017 12:54 AM +0000 quanah@openldap.org wrote: > It is possible to set up slapo-dynlist to operate as a replacement for > slapo-memberOf, and it is safe in a replicated environment. The tricky > part of using slapo-dynlist is that membership information must be > maintained by updating user objects rather than by updating group > objects, which may be difficult for end users depending on how they > perform group management. It's also possible to do this in the reverse direction. I.e., normal static groups that will populate memberOf in the user entry. To do this, you have to hack the dyngroup schema, changing groupOfURLs from STRUCTURAL to AUXILIARY. In the slapd config, the dynlist config looks like: dynlist-attrset groupOfUrls memberURL memberOf Then we can create some groups: root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com "cn=testgroup" dn: cn=testgroup,ou=Group,dc=example,dc=com objectClass: groupOfNames cn: testgroup member: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com "cn=alttestgroup" dn: cn=alttestgroup,ou=Group,dc=example,dc=com objectClass: groupOfNames cn: alttestgroup member: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com The user entry looks like: root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com "cn=Marice McCaugherty" objectClass memberOf memberURL dn: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: groupOfURLs memberURL: ldap:///dc=example,dc=com??sub?(member=cn=Marice McCaugherty,ou=Pro duct Testing,dc=example,dc=com) memberOf: cn=testgroup,ou=Group,dc=example,dc=com memberOf: cn=alttestgroup,ou=Group,dc=example,dc=com Doing it this way means that people currently using memberOf wouldn't need to change how group management is done. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
moved from Incoming to Documentation
changed notes changed state Open to Test
changed notes changed state Test to Release
Fixed in master Fixed in RE25 Fixed in RE24 (2.4.45)
changed notes changed state Release to Closed