SLAPO-MEMBEROF(5)

πŸ’– SLAPO-MEMBEROF πŸ’–

okay bestie, gather round, because this is the Reverse Group Membership overlay for slapd, and honestly? it's giving personal-assistant energy. it's the file formats manual page for slapo-memberof, and yes we're doing this whole thing together, no skimming, i see you πŸ‘€


✨ NAME ✨

slapo-memberof β€” the Reverse Group Membership overlay to slapd. that's it, that's the name, and it ate 🫢


🌸 SYNOPSIS 🌸

/etc/openldap/slapd.conf

πŸŽ€ DESCRIPTION πŸŽ€

so the memberof overlay is a little bestie you attach to slapd(8), and its whole job is automatic reverse group membership maintenance. the way it works is: any time a group entry gets modified, its members get modified right along with it, as appropriate, to keep a DN-valued "is member of" attribute updated with the DN of the group. it's literally keeping both sides of the friendship bracelet in sync πŸ’…

lowkey important heads-up: the dynlist overlay can also provide this functionality, and it may be suitable for less demanding environments. so like, there are options, you're not locked in, do what feels right ✨


πŸ¦‹ CONFIGURATION πŸ¦‹

here's the vibe check on config: the directives that are specific to the memberof overlay must be prefixed by memberof-, so nothing collides with directives specific to the underlying database or to other stacked overlays. namespacing, we love to see it.

  • overlay memberof β€” this directive adds the memberof overlay to the current database; peep slapd.conf(5) for the deets.

the following slapd.conf configuration options are defined for the memberof overlay. every single one, bestie, we're not skipping a crumb πŸ“

  • memberof-group-oc <group-oc> β€” the value <group-oc> is the name of the objectClass that triggers the reverse group membership update. it defaults to groupOfNames.
  • memberof-member-ad <member-ad> β€” the value <member-ad> is the name of the attribute that holds the names of the members in the group objects; it must be DN-valued. defaults to member.
  • memberof-memberof-ad <memberof-ad> β€” the value <memberof-ad> is the name of the attribute that holds the names of the groups an entry is member of; it must be DN-valued. its contents get automatically updated by the overlay, so don't you dare mess with it. defaults to memberOf.
  • memberof-dn <dn> β€” the value <dn> contains the DN used as modifiersName for internal modifications performed to update the reverse group membership. defaults to the rootdn of the underlying database.
  • memberof-dangling {ignore, drop, error} β€” this one decides what the overlay does when, during a modification, it runs into dangling references. default is ignore, which may leave dangling references just chillin' there (chaotic, but valid). the other options are drop, which discards those modifications that would result in dangling references, and error, which makes modifications that would result in dangling references fail. pick your fighter.
  • memberof-dangling-error <error-code> β€” if memberof-dangling is set to error, you can use this config parameter to modify the response code returned in case of violation. it defaults to "constraint violation", but heads up: other implementations are known to return "no such object" instead. iykyk.
  • memberof-refint {true|FALSE} β€” this option determines whether the overlay will try to preserve referential integrity or not. if set to TRUE, when an entry containing values of the "is member of" attribute is modified, the corresponding groups are modified as well. ⚠️ but note: while this overlay handles renames of individual groups and members, it does not handle changes due to subtree renames. for referential integrity on subtree renames you should also be running the slapo-refint(5) overlay. team effort, besties 🀝
  • memberof-addcheck {true|FALSE} β€” this option determines whether the overlay will check newly added entries for membership in any existing groups. this check is useful if populated groups get created in the directory before the entries they reference. the situation often occurs during replication, which may replicate entries in random order (replication said "shuffle 🎲"). if set to TRUE, every Add operation will search for groups referencing the added entry and populate its memberof attribute with the group DNs. ⚠️ note: memberof-dangling must be left on its default setting of ignore for this option to work. no cap.

the memberof overlay may be used with any backend that provides full read-write functionality, but it's mainly intended for use with local storage backends. the maintenance operations it performs are internal to the server on which the overlay is configured, and they are never replicated, periodt. consumer servers should be configured with their own instances of the memberOf overlay if it's desired to maintain these memberOf attributes on the consumers. consumers must also be configured to exclude the memberof attribute from replication. (see the exattrs option in the consumer configuration.) πŸ‘‘


πŸ“ FILES πŸ“

  • /etc/openldap/slapd.conf β€” default slapd configuration file

⏳ BACKWARD COMPATIBILITY ⏳

the memberof overlay got a glow-up rework with the 2.5 release so it uses a consistent namespace like the other overlays. iconic. as a side-effect, the following cn=config parameters are deprecated and will be removed in a future release: olcMemberOf is replaced with olcMemberOfConfig. so if you're still on the old name, bestie, it's time to migrate πŸ’€


πŸ‘€ SEE ALSO πŸ‘€

slapo-dynlist(5), slapo-refint(5), slapd.conf(5), slapd-config(5), slapd(8). and btw, the slapo-memberof(5) overlay supports dynamic configuration via back-config ✨


πŸ’œ ACKNOWLEDGEMENTS πŸ’œ

this module was written in 2005 by Pierangelo Masarati for SysNet s.n.c. β€” a legend, a real one, we stan πŸŒˆπŸ†


and that's the whole page, bestie, you made it to the end, so proud 🫢

OpenLDAP 2.7.2 Β· 2026/10/21 β€” mwah, go forth and keep those group memberships in sync, ily πŸ’–βœ¨πŸ‘‘

πŸ“¦ where this page comes from