How to Find LDAP Groups

Query LDAP group objects and memberships across common schemas, including direct and nested membership patterns in Active Directory and OpenLDAP.

Type
Tutorial
Level
Intermediate
Technologies
LDAP, Active Directory, OpenLDAP
On this page

What Is an LDAP Group?

In LDAP (Lightweight Directory Access Protocol) directories, a group is a special kind of entry used to represent a collection of users or other directory entities. Groups play a crucial role in access control, authorization, and directory-driven workflows. Understanding the structure, schema, and correct querying methods for groups is essential, especially because directory schemas and conventions are not always consistent across deployments.

Identifying groups reliably requires knowledge of the specific objectClasses and membership attributes as defined by directory standards such as RFC 4519 and associated documentation. Methods that work in one LDAP environment (e.g., Microsoft Active Directory) may not work in others (such as OpenLDAP or custom schemas), so a schema-precise and platform-neutral approach is critical.

LDAP Group Objects: The Schema Foundation

LDAP group entries are typically structured according to definitions in the directory schema. The most widely used standard objectClasses for groups are:

  • groupOfNames: As defined in RFC 4519, this objectClass uses the multi-valued 'member' attribute to list the distinguished names (DNs) of group members.
  • groupOfUniqueNames: Similar in purpose, but uses the 'uniqueMember' attribute to list DNs.

A canonical groupOfNames entry looks like this:

ldif
dn: cn=admins,ou=groups,dc=example,dc=com
objectClass: groupOfNames
cn: admins
member: uid=alice,ou=people,dc=example,dc=com
member: uid=bob,ou=people,dc=example,dc=com

There may be other objectClasses in use—some directories define custom schemas—but groupOfNames and groupOfUniqueNames are the reference point in standards-compliant deployments.

How Group Membership Is Stored: member and uniqueMember

Group membership is explicitly recorded within group entries. Two attributes serve this purpose:

  • member: Used with groupOfNames, each value is a DN of a group member. Can include users, groups, or other directory objects.
  • uniqueMember: Used with groupOfUniqueNames. Also stores DNs, and may include an optional unique identifier within the value.

For example, a groupOfNames entry:

ldif
dn: cn=projectX,ou=groups,dc=example,dc=com
objectClass: groupOfNames
cn: projectX
member: uid=carol,ou=people,dc=example,dc=com
member: uid=dan,ou=people,dc=example,dc=com

The member attribute's values are complete DNs of group members, not just usernames or simple identifiers. Any resolution of membership requires knowing or looking up these DNs.

Searching for Groups: Building Effective LDAP Filters

To find all LDAP groups in your directory, the most reliable method is to query for entries possessing the specific group objectClass. For canonical groups, use the following filter in your LDAP search:

text
(objectClass=groupOfNames)

or, depending on your schema,

text
(objectClass=groupOfUniqueNames)

Use these filters to match all entries categorized as groups. The scope and base DN for the search will determine which parts of the directory tree are included in the results.

Finding Members of a Group

Listing all members of a group involves retrieving the group's directory entry and inspecting its membership attribute:

  • For groupOfNames, read the member attribute.
  • For groupOfUniqueNames, read the uniqueMember attribute.

Each value will be a DN of a member. For example:

text
member: uid=carol,ou=people,dc=example,dc=com
member: uid=dan,ou=people,dc=example,dc=com

Be aware that group membership attributes can reference user entries, but may also include the DNs of other groups (nested groups) if your directory supports this.

Finding All Groups for a User: The Reverse Lookup

To determine which groups a particular user belongs to, use the user’s DN in a search filter targeting group entries. For example, if the user's DN is:

text
uid=carol,ou=people,dc=example,dc=com

The filter to find all groups where this user is a member would be:

text
(&(objectClass=groupOfNames)(member=uid=carol,ou=people,dc=example,dc=com))

This approach is standards-compliant and works in any directory that uses member (or, analogously, uniqueMember). It is important to note that, outside certain vendor implementations, there is no attribute on the user entry listing their groups—this relationship is maintained only within the group objects.

Active Directory Special Case: member vs. memberOf

In Microsoft Active Directory (AD), both group and user entries participate in group membership management:

  • The member attribute is present on group entries and lists the DNs of member objects.
  • The memberOf attribute exists on user (and group) entries and lists the DNs of groups to which the entry belongs.

However, memberOf is not part of the standard LDAP schema. AD computes and maintains this attribute for convenience, but its existence and accuracy are guaranteed only in AD and certain directory implementations that explicitly support it. In standard LDAP (e.g., OpenLDAP), memberOf may not exist, or may not be reliably maintained. The authoritative source of group membership is always the member (or uniqueMember) attribute on group objects.

Distinguishing Between User and Group Objects

LDAP directories distinguish users and groups by their objectClass attribute values:

  • Groups: Often have objectClass=groupOfNames or objectClass=groupOfUniqueNames.
  • Users: Typically have objectClass=person, objectClass=inetOrgPerson, or similar.

For example, a user entry:

ldif
dn: uid=carol,ou=people,dc=example,dc=com
objectClass: inetOrgPerson
uid: carol
...

A group entry:

ldif
dn: cn=admins,ou=groups,dc=example,dc=com
objectClass: groupOfNames
cn: admins
...

Searching and filtering by the correct objectClass is the foundation for accurately classifying entries as users or groups.

CategoryCommon objectClassTypical membership attribute
Userperson, inetOrgPerson(none—group membership tracked in groups)
GroupgroupOfNames, groupOfUniqueNamesmember, uniqueMember

Caveats and Common Pitfalls

  • 'memberOf' as a universal solution: Many expect 'memberOf' to always exist, but it is unique to AD and certain schema extensions. Do not rely on it in standard LDAP.
  • Schema variability: Not all directories use the same group objectClass or membership attributes. Always inspect your schema before designing filters.
  • Reverse lookups require DNs: Searching for a user’s group membership requires the user’s full DN, not just a username or common name.
  • Nested groups: If the 'member' or 'uniqueMember' attributes reference group DNs, membership may be indirect. Standard LDAP does not automatically resolve this nesting; applications must handle it if necessary.
  • Group membership containing non-user entries: The 'member' or 'uniqueMember' attributes may reference other types of directory objects, not just users, further complicating simplistic queries for "all user members."
  • Incomplete or manually maintained attributes: In some directories, administrative errors or lack of automation may cause group membership attributes to become stale.

Authoritative References and Further Reading

For definitive details and schema definitions on group objects and LDAP directory structure, consult:

  • RFC 4519: Defines core LDAP schema including 'groupOfNames', 'member', and related attributes.
  • OpenLDAP Administrator’s Guide: Offers practical guidance on searching, querying, and troubleshooting LDAP entries.
  • RFC 2256: Summarizes standard directory user and group schemas, particularly for compatibility.
  • draft-daboo-vcard4-ldap-mapping-00: Describes standard group objectClasses and attributes in portable schema terms.

Sources

Related resources