Cribl Stream LDAP Group Membership Resolution Ignores a Configured Group Search Filter When memberOf Is Present

Symptom

An administrator configures LDAP group-based role mapping in Cribl Stream — setting Group search base, Group search filter (for example (&(objectclass=group)(member={dn}))), Group member field, and Group membership attribute — expecting Cribl to actively search group objects to resolve the logged-in user's group membership. Role mapping does not behave as the configured filter implies: users get roles that suggest a different group-resolution path was used, or cribl.log shows no group-search query was ever issued for the auth channel, even though the filter is present and looks syntactically correct.

This is common when migrating an LDAP configuration from OpenLDAP (where group search is typically required) to Active Directory (where it typically is not), or when copying a group-search example from documentation into an AD environment.

Environment

• Cribl Stream, all versions with LDAP authentication support
• Self-managed deployment
• Active Directory or OpenLDAP as the LDAP backend
• Applies to LDAP role/group mapping (groups.mapping in cribl.yml, or the LDAP provider's group settings in Settings > Global > Access Management > Authentication)

Resolution

The decision is not a configuration setting — it is a runtime check

After Cribl successfully authenticates the user (bind with the user's DN and password), it fetches the user's group memberships using exactly one of two mechanisms, chosen by a single runtime condition:

If the authenticated user's LDAP object has a memberOf attribute that is present (even if empty), Cribl uses Mode A. Otherwise, if a Group search base is configured, Cribl falls back to Mode B.

There is no checkbox or field in Cribl that lets an administrator force Mode B while memberOf is present. The presence of a memberOf attribute on the authenticated user's LDAP object always wins, regardless of the other group-search settings.

A memberOf attribute that is present but returns no values still counts as "present" and triggers Mode A — the user simply resolves to zero groups. Mode B is only reached when memberOf is absent from the LDAP response entirely.

Why this causes confusion: Active Directory returns memberOf by default

Active Directory implements memberOf as a constructed (operational) attribute and returns it on a user lookup whenever the attribute is requested, without any special configuration on the AD side. Because of this, most AD-backed Cribl LDAP configurations end up in Mode A automatically, whether or not the administrator intended it.

If an admin configures a Group search filter intending Mode B (for example, following an OpenLDAP example that requires active group search), but the AD user query returns memberOf with values, Cribl silently uses Mode A instead — the Group search filter is never evaluated, and any troubleshooting done against that filter directly will not explain the observed role mapping.

OpenLDAP directories, by contrast, do not populate memberOf unless the memberof overlay is explicitly configured — so OpenLDAP setups more often land in Mode B by default.

Verify which mode is active

Query the authenticated user's DN directly for memberOf, the same way Cribl does at login:

ldapsearch -x -H ldap://<server>:389 \ -D "<bind-DN>" -W \ -b "<user-DN>" "(objectClass=*)" memberOf

• memberOf returned with one or more values → Mode A is active. The configured Group search base, Group search filter, Group member field, and Group membership attribute have no effect for this user.
• memberOf absent or attribute not returned at all → Mode B is active, and the group-search parameters apply.

Cross-check with Cribl's own logs:

1. Go to Settings > Global > System > Logging > Levels and set the LDAPMapper and auth channels to debug.
2. Reproduce the login.
3. Search cribl.log for the "External groups found" log line. It lists the exact group DNs Cribl resolved (from either mode), which can be compared directly against the LDAP group memberships expected for that user.
4. If a group search was performed (Mode B), a corresponding LDAP group-search query will also be logged on the auth channel. Its absence, with a login that still succeeds and resolves a role, is itself evidence that Mode A was used instead.

If Mode B is required

There is no supported way to force Mode B while memberOf is present on the user object. Options are:

• Accept Mode A and rely on memberOf for role mapping — this is the simpler, better-supported path on Active Directory and requires no Group search settings.
• Have your AD/LDAP administrator suppress memberOf from the attributes returned to Cribl's bind account, if your directory policy and any other consumers of that account allow it (uncommon, and not a Cribl-side setting).

Cause

Cribl's LDAP group-resolution logic checks whether the authenticated user's LDAP object carries a memberOf attribute immediately after authentication. When it does, Cribl uses those values directly and returns — the group-search query (built from Group search base, Group search filter, Group member field, and Group membership attribute) is never constructed. Only when memberOf is absent does Cribl build and execute the active group-search query.

This is confirmed in the official Cribl blog post on LDAP integration: "The existence of the memberOf attribute will supersede searching for any groups even if the Group search base setting is defined... a search for groups will not be conducted if memberOf exists."

Because Active Directory returns memberOf as a default, always-available constructed attribute, AD-backed configurations land in Mode A far more often than administrators expect — especially when the configuration was written or copied with OpenLDAP-style active group search in mind.

Related mechanic: Group name field is a DN parse, not an attribute lookup

Regardless of which mode resolves the group DNs, Cribl never reads an attribute from the group object to get its name. It parses the group's DN string into RDN key/value pairs and looks up the value under the key matching Group name field. This lookup is case-sensitive on the key: for a DN like CN=StreamAdmins,OU=Groups,DC=example,DC=com, Group name field must be CN (uppercase) to match — the default value cn (lowercase) will return no match against an AD-style DN. OpenLDAP DNs typically use lowercase cn=, so cn is correct there. This is a separate, independently-failing gotcha from the memberOf/group-search decision above.

AD vs. OpenLDAP quick reference

Additional Information

For more information, see Cribl’s Authentication documentation.