(ITS#8613) slapo-memberOf documentation update (Unsafe to use with replication)

[quanah@openldap.org]

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 )
        )