Configure the 389 Directory Server memberOf Plugin

Static groups store membership on the group entry through member or uniqueMember. Without memberOf, an application normally searches group entries for a member or uniqueMember value matching the user's DN. The MemberOf plug-in stores the reverse relationship on the member entry, allowing the application to retrieve group membership with a base search on that entry. SSSD ldap_access_filter rules that test memberOf depend on this plug-in; see the SSSD LDAP authentication guide for a client example. Apache Require ldap-filter against memberOf uses the same attribute; see the Apache LDAP authentication guide.

This guide covers the full reverse static-group membership workflow in 389 Directory Server:

• How member and memberOf differ
• Enabling and configuring the MemberOf plug-in
• Supporting member and uniqueMember
• Direct and nested group membership
• Included and excluded scopes
• MemberOf specific group scope in 389 DS 3.2
• Membership across separate backends
• Required object classes
• Rebuilding existing values with the fixup task
• Shared configuration
• Replication topology design
• Troubleshooting missing or incorrect memberOf values — see the memberOf troubleshooting guide

Before you start:

• Install 389 Directory Server — running instance with a suffix (this lab uses ldap1 on dc=example,dc=com)
• Manage users and groups — ou=People, ou=Groups, and static group creation
• dsconf commands — online plug-in configuration

The primary lab instance is ldap1 on ldap1.example.com with LDAP port 389. Instance ldap2 on ports 1389 and 1636 is a second supplier that holds the same replicated suffix dc=example,dc=com for shared-configuration examples later in this guide.

How the memberOf plug-in works

The plug-in monitors membership attributes on static group entries and writes the corresponding group DN to the member entry's memberOf attribute.

Group entry
member: uid=user1,ou=People,dc=example,dc=com
        |
        | MemberOf plug-in
        v
User entry
memberOf: cn=developers,ou=Groups,dc=example,dc=com

The forward membership attribute on the group entry is the source of truth. The plug-in manages memberOf. Administrators should not normally edit memberOf directly.

The plug-in supports direct and indirect membership through nested groups, but it does not calculate membership for dynamic groups based on LDAP URL filters (memberURL). Dynamic membership remains outside this plug-in's scope.

Prepare static groups and test users

Use one consistent lab tree under dc=example,dc=com:

dc=example,dc=com
├── ou=People
│   ├── uid=user1
│   └── uid=user2
└── ou=Groups
    ├── cn=developers
    ├── cn=ops-unique
    └── cn=engineering

The lab includes:

• cn=developers — groupOfNames using member
• cn=ops-unique — groupOfUniqueNames using uniqueMember
• cn=engineering — nested parent group that will contain the Developers group DN

On my Rocky Linux 10.

Directory data changes in this section use dsidm commands.

dsidm ldap1 group create --cn developers --description "Developers groupOfNames lab group"

Successfully created developers

dsidm ldap1 uniquegroup create --cn ops-unique

Successfully created ops-unique

dsidm ldap1 group create --cn engineering --description "Engineering parent group for nested membership"

Successfully created engineering

Check and enable the MemberOf plug-in

Before enabling the plug-in, Review its current configuration and confirm whether any user entries already carry memberOf values.

dsconf ldap1 plugin memberof show

Sample output:

dn: cn=MemberOf Plugin,cn=plugins,cn=config
cn: MemberOf Plugin
memberofattr: memberOf
memberofgroupattr: member
nsslapd-pluginEnabled: off
nsslapd-pluginInitfunc: memberof_postop_init
nsslapd-pluginPath: libmemberof-plugin
nsslapd-pluginType: betxnpostoperation
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject

On a fresh instance the plug-in is usually disabled and monitors member only. The settings to review before you enable it include nsslapd-pluginEnabled, memberofgroupattr, memberofattr, memberofentryscope, memberofentryscopeexcludesubtree, memberofallbackends, memberofskipnested, memberofautoaddoc, memberOfSpecificGroupFilter, and nsslapd-pluginConfigArea.

Check whether users already contain memberOf values:

ldapsearch -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -W -b "ou=People,dc=example,dc=com" "(memberOf=*)" dn memberOf

Sample output:

# numEntries: 0

An empty result is expected when the plug-in has not yet maintained reverse membership.

Enable the plug-in next:

dsconf ldap1 plugin memberof enable

Enabled plugin 'MemberOf Plugin'

Restart the instance so the plug-in loads:

dsctl ldap1 restart

The restart completes silently when the instance returns to the running state.

Verify the enabled state:

dsconf ldap1 plugin memberof show

Sample output:

nsslapd-pluginEnabled: on
nsslapd-pluginId: memberof
memberofgroupattr: member

The nsslapd-pluginEnabled: on line confirms the plug-in is active. New group membership changes will begin updating memberOf from this point forward, but existing memberships are not repaired automatically.

Configure group membership attributes

By default the plug-in reads member only. If your directory uses both groupOfNames and groupOfUniqueNames, configure both member and uniqueMember. Many deployments standardize on only one group type.

dsconf ldap1 plugin memberof set --groupattr member uniqueMember

Successfully changed the cn=MemberOf Plugin,cn=plugins,cn=config

Restart the instance after changing MemberOf configuration:

dsctl ldap1 restart

Verify the configuration:

dsconf ldap1 plugin memberof show

Sample output:

memberofgroupattr: member
memberofgroupattr: uniqueMember

The memberOfGroupAttr setting is multi-valued, so one plug-in configuration can monitor multiple static-group membership attributes. Configuring only member is a common reason groupOfUniqueNames changes appear to be ignored.

Test direct and nested group membership

Direct membership

Add user1 to the Developers group. Save the LDIF as add-user1-developers.ldif:

dn: cn=developers,ou=Groups,dc=example,dc=com
changetype: modify
add: member
member: uid=user1,ou=People,dc=example,dc=com

Apply the change:

ldapmodify -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -W -f add-user1-developers.ldif

modifying entry "cn=developers,ou=Groups,dc=example,dc=com"

Verify the group entry:

ldapsearch -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -W -b "cn=developers,ou=Groups,dc=example,dc=com" -s base member

Sample output:

member: uid=user1,ou=People,dc=example,dc=com

Verify the user entry:

ldapsearch -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -W -b "uid=user1,ou=People,dc=example,dc=com" -s base memberOf

Sample output:

memberOf: cn=developers,ou=Groups,dc=example,dc=com

The plug-in added the reverse membership automatically.

Add user2 to the groupOfUniqueNames group through uniqueMember. Save add-user2-ops-unique.ldif:

dn: cn=ops-unique,ou=Groups,dc=example,dc=com
changetype: modify
add: uniqueMember
uniqueMember: uid=user2,ou=People,dc=example,dc=com

Apply it:

ldapmodify -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -W -f add-user2-ops-unique.ldif

modifying entry "cn=ops-unique,ou=Groups,dc=example,dc=com"

Verify user2:

ldapsearch -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -W -b "uid=user2,ou=People,dc=example,dc=com" -s base memberOf

Sample output:

memberOf: cn=ops-unique,ou=Groups,dc=example,dc=com

Both member and uniqueMember updates produced memberOf values once uniqueMember was included in memberOfGroupAttr and the instance was restarted.

Nested membership

Nested layout for this lab:

cn=developers,ou=Groups,dc=example,dc=com
        member of
cn=engineering,ou=Groups,dc=example,dc=com

When Developers is a member of Engineering and user1 is a member of Developers, user1 should receive both group DNs:

memberOf: cn=developers,ou=Groups,dc=example,dc=com
memberOf: cn=engineering,ou=Groups,dc=example,dc=com

A group that is itself placed inside another group must allow the plug-in to add memberOf. For nested groups, add the auxiliary extensibleObject object class to the child group entry. In this example, cn=developers is the child group and therefore must include extensibleObject.

Check the Developers entry first:

ldapsearch -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -W -b "cn=developers,ou=Groups,dc=example,dc=com" -s base objectClass

Sample output:

objectClass: top
objectClass: groupOfNames

If extensibleObject is absent, add it before creating the nested relationship. Save developers-extensibleObject.ldif:

dn: cn=developers,ou=Groups,dc=example,dc=com
changetype: modify
add: objectClass
objectClass: extensibleObject

Apply it:

ldapmodify -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -W -f developers-extensibleObject.ldif

modifying entry "cn=developers,ou=Groups,dc=example,dc=com"

Add the Developers group DN to Engineering. Save nest-developers-in-engineering.ldif:

dn: cn=engineering,ou=Groups,dc=example,dc=com
changetype: modify
add: member
member: cn=developers,ou=Groups,dc=example,dc=com

Apply it:

ldapmodify -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -W -f nest-developers-in-engineering.ldif

modifying entry "cn=engineering,ou=Groups,dc=example,dc=com"

Verify user1 still has direct membership and now also has indirect membership:

ldapsearch -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -W -b "uid=user1,ou=People,dc=example,dc=com" -s base memberOf

Sample output:

memberOf: cn=developers,ou=Groups,dc=example,dc=com
memberOf: cn=engineering,ou=Groups,dc=example,dc=com

First, remove the nested relationship. Save remove-developers-from-engineering.ldif:

dn: cn=engineering,ou=Groups,dc=example,dc=com
changetype: modify
delete: member
member: cn=developers,ou=Groups,dc=example,dc=com

Apply it:

ldapmodify -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -W -f remove-developers-from-engineering.ldif

modifying entry "cn=engineering,ou=Groups,dc=example,dc=com"

Verify user1:

ldapsearch -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -W -b "uid=user1,ou=People,dc=example,dc=com" -s base memberOf

Sample output:

memberOf: cn=developers,ou=Groups,dc=example,dc=com

The indirect Engineering membership was removed while direct Developers membership remained.

Before the scope and skipnested exercises, re-apply nest-developers-in-engineering.ldif so user1 carries both memberships again.

Scope, nesting, and backend options

Several plug-in settings control how widely membership is calculated: nested expansion, subtree scope, cross-backend searches, and specific-group filters introduced in 389 DS 3.2.

Skip nested group processing

When only direct membership should be maintained:

dsconf ldap1 plugin memberof set --skipnested on

Restart the instance:

dsctl ldap1 restart

On my lab host, with --skipnested on, user1 retained memberOf: cn=developers,... but lost the indirect cn=engineering,... value after I removed and re-added the nested relationship.

Restore the default behavior before continuing:

dsconf ldap1 plugin memberof set --skipnested off

dsctl ldap1 restart

After restoring memberOfSkipNested to off, run the MemberOf fixup task to rebuild indirect memberships using the updated configuration:

dsconf ldap1 plugin memberof fixup --wait "dc=example,dc=com"

Alternatively, remove and then re-add the nested relationship to trigger recalculation through a new group modification.

The plug-in maintains direct and indirect memberships by default when memberOfSkipNested is off. Re-applying nest-developers-in-engineering.ldif while the forward member value already exists can fail with Type or value exists (20).

Included and excluded scopes

Limit the plug-in to the example suffix:

dsconf ldap1 plugin memberof set --scope "dc=example,dc=com"

Exclude a private subtree:

dsconf ldap1 plugin memberof set --exclude "ou=Private,dc=example,dc=com"

A few scope rules apply:

• Both the group and the member must fall within the effective plug-in scope.
• Excluded subtrees take precedence over the included scope.
• Moving an entry outside the scope can remove the associated membership references.

I created ou=Private,dc=example,dc=com with a groupOfNames group and a test user. After adding the user to the private group, the user entry had no memberOf attribute because the subtree was excluded. A user under ou=People inside the included scope continued to receive memberOf values normally.

Membership across separate backends

By default the plug-in searches for members only in the same backend as the group. When users and groups are stored in separate backends, enable cross-backend searches:

dsconf ldap1 plugin memberof set --allbackends on

Example layout when People and Groups are separate databases:

People backend:
ou=People,dc=example,dc=com

Groups backend:
ou=Groups,dc=example,dc=com

Different OUs do not automatically mean different backends. This option is required only when the People and Groups subtrees are mapped to separate Directory Server databases. If both OUs are stored in the same backend for dc=example,dc=com, leave memberOfAllBackends disabled.

The plug-in normally processes members in the group's database. memberOfAllBackends=on extends that search across configured databases. Use it only when the directory layout requires it, because cross-backend searches increase search work on large directories.

Limit processing to specific groups (389 DS 3.2)

389 Directory Server 3.2 adds memberOfSpecificGroupFilter, memberOfExcludeSpecificGroupFilter, and memberOfSpecificGroupOC so the plug-in can include or exclude individual groups by LDAP filter.

Choose either an include-filter model or an exclude-filter model. The following examples are alternatives and should not be applied sequentially.

Include-filter lab workflow. limit processing to Developers and Engineering:

dsconf ldap1 plugin memberof set --specific-group-filter "(cn=developers)"

Add another included filter without replacing existing values:

dsconf ldap1 plugin memberof add-attr --specific-group-filter "(cn=engineering)"

Alternative: exclude-filter model. use this only when no include filters exist:

dsconf ldap1 plugin memberof set --exclude-specific-group-filter "(cn=internal-group)"

To switch from include filters to an exclude model, remove the existing include filters first:

dsconf ldap1 plugin memberof del-attr --specific-group-filter "(cn=developers)" "(cn=engineering)"

Restrict which object classes identify a group entry:

dsconf ldap1 plugin memberof set --specific-group-oc groupOfNames groupOfUniqueNames

A few rules apply to MemberOf specific group scope:

• Do not configure include and exclude group filters simultaneously. An include filter already excludes all unmatched groups.
• set replaces existing values where the option is multi-valued.
• Use add-attr and del-attr when adding or removing individual filters.
• Restart the instance and run fixup after changing which groups participate.

Restart and verify combined scope settings

After changing scope, backend, or specific-group settings, restart the instance:

dsctl ldap1 restart

Verify the active configuration:

dsconf ldap1 plugin memberof show

Sample output:

memberofgroupattr: member
memberofgroupattr: uniqueMember
memberofentryscope: dc=example,dc=com
memberofentryscopeexcludesubtree: ou=Private,dc=example,dc=com
memberofallbackends: on
memberofskipnested: off
memberofspecificgroupfilter: (cn=developers)
memberofspecificgroupfilter: (cn=engineering)
memberofspecificgroupoc: groupOfNames
memberofspecificgroupoc: groupOfUniqueNames

Only the lines that match your enabled configuration should appear in your environment.

New entries in this section are added with the ldapadd command.

Configure required object classes

The member entry must have an object class that permits the memberOf attribute. By default, when the plug-in needs to write memberOf to an entry that lacks a compatible object class, it adds nsMemberOf. This is independent of whether the entry was created with dsidm, ldapadd, an import, or another LDAP client.

Official documentation lists nsMemberOf as the default automatically added object class, with inetUser, inetAdmin, and inetOrgPerson as alternatives that already permit the attribute.

Configure another supported object class where required:

dsconf ldap1 plugin memberof set --autoaddoc inetUser

Restart the instance:

dsctl ldap1 restart

Verify the setting:

dsconf ldap1 plugin memberof show

Sample output:

memberofautoaddoc: inetuser

If the plug-in cannot add a compatible object class and the entry schema does not allow memberOf, the modify fails with an object class violation:

Object class violation (65)

Choose an alternative object class with memberOfAutoAddOC only when your deployment standard requires it.

Rebuild memberOf values with the fixup task

Enabling the plug-in does not retroactively repair memberships that already existed. Run the fixup task when:

• Groups existed before the plug-in was enabled
• Users were imported with inconsistent memberOf values
• Someone manually edited memberOf
• Scope, nesting, group-attribute, or specific-group settings changed
• A consumer initialization or total update left locally calculated memberOf values missing or inconsistent in your chosen replication design

Run one fixup task at a time and schedule large rebuilds during a maintenance window. Nested groups and multiple configured group attributes can increase processing time.

Run the task against the suffix:

dsconf ldap1 plugin memberof fixup --wait "dc=example,dc=com"

Sample output:

Adding fixup task entry...
Waiting for fixup task "cn=memberOf_fixup_2026-07-16T19:27:06.364120,cn=memberOf task,cn=tasks,cn=config" to complete.
Fixup task successfully completed

Use a custom filter when additional object classes must be included explicitly. Once a custom filter is supplied, it determines which entries are processed:

dsconf ldap1 plugin memberof fixup --wait -f "(|(objectClass=inetUser)(objectClass=inetAdmin)(objectClass=inetOrgPerson)(objectClass=nsMemberOf))" "dc=example,dc=com"

The documented default filter covers inetUser, inetAdmin, and nsMemberOf. A custom filter is needed when additional classes such as inetOrgPerson must be included.

On my lab host I manually deleted stale memberOf values from user1 while member values on the group entries remained unchanged, confirmed the user attribute was empty, then ran the fixup task. After completion, both cn=developers and cn=engineering appeared again on the user entry.

When you start fixup without --wait, monitor the background task with:

dsconf ldap1 plugin memberof fixup-status --watch

Display task logs when troubleshooting:

dsconf ldap1 plugin memberof fixup-status --show-log

The CLI also supports --wait, --watch, --show-log, and an optional task DN.

After fixup completes, sample a few expected users. For a broader validation pass on a small lab suffix:

ldapsearch -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -W -b "dc=example,dc=com" "(memberOf=*)" dn memberOf

This query can be expensive on a large suffix. Use it sparingly in production and prefer targeted checks on representative users and groups.

The fixup task runs locally on the server where you start it. Whether the resulting values reach other replicas depends on whether those attribute changes are replicated:

• When memberOf is excluded from replication and every server calculates it locally, run fixup on every server that needs rebuilding.
• When suppliers calculate memberOf and replicate it to read-only consumers, run fixup on the appropriate supplier and allow the result to replicate to consumers.
• A fixup on one supplier does not automatically repair another supplier when memberOf is excluded between writable servers.

Confirm reverse membership is removed on delete

After the fixup demonstration, remove user1 from Developers to confirm that reverse membership is cleared when forward membership is deleted. Save remove-user1-developers.ldif:

dn: cn=developers,ou=Groups,dc=example,dc=com
changetype: modify
delete: member
member: uid=user1,ou=People,dc=example,dc=com

Apply it:

ldapmodify -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -W -f remove-user1-developers.ldif

modifying entry "cn=developers,ou=Groups,dc=example,dc=com"

Verify the user entry:

ldapsearch -x -H ldap://ldap1.example.com:389 -D "cn=Directory Manager" -W -b "uid=user1,ou=People,dc=example,dc=com" -s base memberOf

Sample output:

dn: uid=user1,ou=People,dc=example,dc=com

The user entry returned with no memberOf attribute. That confirms the plug-in removes reverse membership when forward membership is deleted.

Share the plug-in configuration across servers

Two configuration models exist:

The shared configuration entry must reside under a suffix that is replicated and available with the same DN on every participating server. Once nsslapd-pluginConfigArea is set, the plug-in ignores the normal local settings and reads the referenced shared entry.

Create a shared configuration entry on ldap1:

dsconf ldap1 plugin memberof config-entry add "cn=shared-memberof-config,dc=example,dc=com" --attr memberOf --groupattr member uniqueMember

Successfully created the cn=shared-memberof-config,dc=example,dc=com
MemberOf attribute nsslapd-pluginConfigArea (config-entry) was set in the main plugin config

Display the shared entry:

dsconf ldap1 plugin memberof config-entry show "cn=shared-memberof-config,dc=example,dc=com"

Sample output:

dn: cn=shared-memberof-config,dc=example,dc=com
cn: shared-memberof-config
memberofattr: memberOf
memberofgroupattr: member
memberofgroupattr: uniqueMember
objectClass: top
objectClass: extensibleObject

Enable the MemberOf plug-in on ldap2 before pointing it at the shared entry. Red Hat lists enabling MemberOf on every participating server as a prerequisite for shared configuration. A disabled plug-in will not process memberships even when nsslapd-pluginConfigArea is set.

dsconf ldap2 plugin memberof enable

Enabled plugin 'MemberOf Plugin'

Point ldap2 at the same shared entry DN after dc=example,dc=com is available on that host through replication:

dsconf ldap2 plugin memberof set --config-entry "cn=shared-memberof-config,dc=example,dc=com"

Restart both instances. The official procedure requires the plug-in to be enabled and each instance restarted after setting the shared configuration:

dsctl ldap1 restart

dsctl ldap2 restart

Verify the plug-in state on the second server:

dsconf ldap2 plugin memberof show

Sample output:

nsslapd-pluginEnabled: on
nsslapd-pluginConfigArea: cn=shared-memberof-config,dc=example,dc=com

Once shared configuration is enabled, settings stored in the normal per-server plug-in entry are ignored. Manage memberOfGroupAttr, scope, specific-group filters, and related attributes on the shared config entry instead.

Configure memberOf in a replication topology

Replication and MemberOf interact because memberOf is a derived attribute. Choose one of the two supported designs and apply it consistently.

Run the plug-in on every server

• Enable the plug-in on suppliers and consumers.
• Exclude memberOf from replication.
• Let each server calculate its own values from member and uniqueMember.

Run the plug-in on supplier servers only

• Enable the plug-in on all write-enabled suppliers.
• Exclude memberOf between write-enabled suppliers.
• Replicate memberOf to read-only consumers.
• Keep the plug-in disabled on those consumers.

Do not allow both replication and local plug-in processing to update the same derived values without a deliberate design.

Verify your chosen model with:

• Group modifications on each supplier
• memberOf on every writable server
• Read-only consumer values
• Fractional replication exclusions for memberOf
• Behavior after an initialization or total update

Complete fractional-replication configuration belongs in the dedicated replication chapter. This guide documents only the two MemberOf deployment models and the attribute-exclusion requirement.

Troubleshooting and related features

These features can complement each other but are not interchangeable. Auto Membership writes forward group membership. MemberOf derives the reverse memberOf attribute. Referential Integrity cleans stale member references after entry deletion or rename.

What's next

After you complete this guide, continue with:

• Configure Referential Integrity in 389 Directory Server — cleanup when members are removed
• Automatically Add Users to Groups with 389 DS Auto Membership — rule-based group membership
• Tune Large LDAP Groups and memberOf Performance in 389 Directory Server — membership at scale
• 389 Directory Server Roles vs Groups: Differences and Use Cases — roles when membership is policy-driven
• Configure Managed Entries and Linked Attributes in 389 Directory Server — derived entry patterns

Summary

1. Enable the MemberOf plug-in and restart the instance.
2. Configure every static-group membership attribute in use (member and uniqueMember).
3. Decide whether nested groups should be expanded (--skipnested).
4. Set the correct included and excluded scopes and specific-group filters.
5. Enable all-backend searches only when groups and users are separated by database.
6. Run the fixup task for existing or imported data.
7. Choose a consistent replication topology design.
8. Verify both group membership and reverse memberOf values.

References

• Red Hat Directory Server 13 — Listing group membership in user entries
• Red Hat Directory Server 13 — memberOf attribute reference
• 389 Directory Server — MemberOf plug-in design
• 389 Directory Server — MemberOf shared configuration design
• 389 Directory Server — MemberOf specific group scoping design
• 389 Directory Server 3.2.0 release notes