Create Groups in OpenLDAP

Create OpenLDAP groups with the correct object class, membership attributes, LDIF entries, directory placement, and consistent schema choices.

Type
Tutorial
Level
Intermediate
Technologies
OpenLDAP, LDAP
On this page

Understanding Groups in OpenLDAP

In OpenLDAP, a group is a directory entry that represents a collection of users or other directory objects. Groups simplify access management by allowing you to assign permissions, policies, or system roles to the group as a whole, rather than to each user individually. They are essential in authentication workflows, directory-integrated applications, and identity management, especially when managing user access to resources or implementing group-based access controls.

Groups in LDAP are not fixed to a single schema. Their structure is governed by the objectClass value you assign, which determines the required attributes and the way membership is expressed. The correct understanding and selection of group schema are central to ensuring interoperability, proper ACL behavior, and manageability.

Group ObjectClasses: posixGroup vs groupOfNames

The objectClass you choose for your group dictates its compatibility and the technical details of membership management. The two principal schemas in OpenLDAP are:

posixGroup

  • Purpose: Intended for Unix/Linux system integration, compatible with NSS/PAM and similar subsystems.
  • Membership: Tracked by the memberUid attribute, which contains user IDs (simple string values like "alice").
  • Required attributes: Must include cn (common name) and gidNumber (group ID).
  • Schema basis: Defined in RFC 2307.
  • Usage: Essential when LDAP is the source of Unix group information, as Unix clients expect posixGroup semantics.

groupOfNames

  • Purpose: General-purpose LDAP grouping, especially suited for directory-native management and integration with LDAP ACLs.
  • Membership: Tracked by the member attribute, which contains one or more fully qualified distinguished names (DNs), such as uid=alice,ou=Users,dc=example,dc=com.
  • Required attributes: Must include cn and at least one member.
  • Schema basis: Defined in RFC 4519.
  • Usage: Necessary where membership by actual DN is needed, or when using group entries in OpenLDAP's group-based ACLs.

Other group objectClasses, such as groupOfUniqueNames, are variants with similar attributes but are less common in modern deployments.

Choosing between these schemas depends on your environment. Use posixGroup for Unix system compatibility; use groupOfNames for LDAP-native directory access control and management. Some environments use both, combining schemas for hybrid compatibility.

Creating Group Entries in OpenLDAP

To create a group, you must construct a valid LDIF (LDAP Data Interchange Format) entry that matches your schema's requirements.

posixGroup LDIF Skeleton

ldif
dn: cn=admins,ou=Groups,dc=example,dc=com
objectClass: posixGroup
cn: admins
gidNumber: 1001
memberUid: alice
memberUid: bob
  • cn: Group name (required)
  • gidNumber: Numeric group ID (required)
  • memberUid: Zero or more usernames (UID strings, optional for an empty group)

groupOfNames LDIF Skeleton

ldif
dn: cn=mygroup,ou=Groups,dc=example,dc=com
objectClass: groupOfNames
cn: mygroup
member: uid=alice,ou=Users,dc=example,dc=com
member: uid=bob,ou=Users,dc=example,dc=com
  • cn: Group name (required)
  • member: One or more DNs of members (required; must supply at least one)

A common source of LDIF import failure is omitting required attributes. For example, a groupOfNames entry without at least one member is invalid.

Hybrid Group Entries

You can assign both posixGroup and groupOfNames objectClasses to the same group, storing both memberUid and member attributes. This approach allows you to support Unix systems and LDAP DN-based membership simultaneously, ensuring compatibility with a broader range of applications and access control patterns.

Managing Group Membership

Modifying group membership means adjusting the associated member attributes:

  • For posixGroup: Add or remove memberUid values. These are plain usernames or UIDs.
  • For groupOfNames: Add or remove member values. Each must be the DN of the member (e.g., a user's DN).

Remember:

  • memberUid in posixGroup must be a valid user ID (string), and is not suitable for DNs.
  • member in groupOfNames must be a valid DN of a user or member object.

Mixing these up—for example, adding a DN as memberUid or a username as member—will break group logic or cause application/ACL failures. Hybrid entries with both objectClasses must maintain both memberships explicitly.

Adding and removing members can be accomplished using tools like ldapmodify, by editing the LDIF entry and re-importing, or via a directory management interface.

Groups and Access Control in OpenLDAP

Groups are often leveraged in OpenLDAP’s access control lists (ACLs) to simplify and optimize permission management. For ACL rules to grant access based on group membership, both your group and the ACL syntax must align:

  • For groupOfNames: ACLs check member attributes using DNs. For example, an ACL might grant access if the binding user is a member of a specific group by DN.
  • For posixGroup: ACLs referencing memberUid compare the user’s UID attribute against group memberUid values.

The syntax in the ACL must match the membership attribute type (member vs memberUid). If you use a groupOfNames group, referencing a username (UID) will not match; similarly, memberUid groups will not match user DNs.

Using groups in ACLs makes managing permissions for large or shifting user populations far simpler, as adding/removing members only updates the group entry, not the ACL rules themselves.

Advanced Patterns: Hybrid Groups, Overlays, and Limitations

Hybrid Groups

In mixed environments, a group entry can simultaneously carry both posixGroup and groupOfNames objectClasses, with both memberUid and member attributes. This hybrid pattern is practical when you need both Unix compatibility and DN-based LDAP group support.

However, managing hybrid groups requires diligence:

  • Both membership lists must be kept in sync where needed.
  • Applications and ACLs must refer to the correct membership attribute.

Overlays: memberOf and Dynamic Group Patterns

OpenLDAP's memberOf overlay automatically adds a memberOf attribute to user entries, reflecting any groups (with DN-based member or similar attributes) to which a user belongs. This is especially useful for searching "which groups does this user belong to?" and is often essential for applications that require reverse group lookups.

Dynamic groups (e.g., using the dynlist overlay) allow group membership to be defined by filters rather than static lists. This is outside the standard group schemas and requires specialized configuration.

Nested Groups and Limitations

OpenLDAP does not natively support nested groups, where a group is a member of another group. While it is possible to list another group's DN as a member, OpenLDAP's access control evaluation does not expand nested memberships by default. Resolving nested groups typically requires application-side logic or directory overlays/extensions.

Similarly, dynamic and computed groups (where membership is calculated from LDAP filters or criteria) are possible via overlays but are not part of the core schema.

Best Practices and Troubleshooting

  • Always supply all required attributes in your LDIF group entries—missing required fields (such as member for groupOfNames) will prevent import.
  • Match your ACL syntax to your group schema's membership attribute.
  • Do not mix membership attribute types: use usernames for memberUid, and DNs for member or uniqueMember.
  • For maximal compatibility in mixed environments, use hybrid group entries with both relevant objectClasses and attributes.
  • To reflect group membership in user objects automatically, enable and configure the memberOf overlay.
  • If group membership changes do not appear reflected in searches or ACL behavior, verify attribute values, ensure proper group schema use, and confirm overlay functionality.
  • Avoid assuming nested groups will just work in ACLs—test and validate behavior in representative scenarios.

Summary

Creating and managing groups in OpenLDAP is a matter of schema selection, correct LDIF structure, and attention to required attributes and membership conventions. By understanding the distinctions between posixGroup and groupOfNames, using hybrid groups when necessary, and integrating overlays (like memberOf) for usability, directory administrators and developers can confidently implement robust group-based access control and interoperable directory architectures. Always consult the authoritative OpenLDAP documentation and relevant RFCs for schema details and overlay configuration to ensure standards-compliant and problem-free group management.

Sources

Related resources