What Are LDAP Wildcard Filters?
LDAP wildcard filters are search constructs that use the asterisk (*) as a special character to match patterns within attribute values rather than requiring exact matches. This technique is fundamental in directory queries when the full value is unknown, partial matching is required, or a flexible search experience is expected—such as matching users by incomplete names, email addresses, or other directory fields.
A typical use case might be retrieving all users whose common name begins with "Jo". The filter (cn=Jo*) returns entries where the cn (common name) attribute starts with "Jo", matching "John", "Joanna", and so on. Wildcards in LDAP filters allow for searching “begins with,” “ends with,” “contains,” or even just “has a value” (the attribute presence filter).
Wildcards are commonly employed to broaden search results. They are especially useful in user interfaces that implement directory lookups or address auto-completion. However, their use must be guided by the attribute’s schema, server performance considerations, and security best practices to avoid misconfigurations or vulnerabilities.
Filter Syntax: How the Wildcard Operator Works
Wildcard filtering in LDAP uses the asterisk (*) as a substring operator within filters, supporting flexible pattern matching on attribute values. The general LDAP filter syntax employing wildcards follows this pattern:
(attribute=pattern)
Where pattern can include zero or more asterisks:
(cn=Jo*)— matches "Jo", "John", "Joanna", etc. (values starting with "Jo")(mail=*example.com)— matches any email ending with "example.com"(cn=*doe*)— matches any value containing "doe" anywhere
Multiple asterisks are allowed, enabling more complex searches (e.g., (cn=Jo*n) matches values starting with "Jo" and ending with "n"). Wildcards can be at the beginning (leading), end (trailing), or both. The filter (attribute=*) is a special case called a “presence filter”—it matches any entry where the attribute is present with any value.
It's important to note that the asterisk is only treated as a wildcard in certain filter constructions; in other contexts, it is a literal character.
Schema Constraints: When Wildcards Are Allowed (and When They’re Not)
Wildcard filtering is possible only on attributes whose schema includes a substring matching rule. Most string-valued attributes (such as cn, sn, mail) support wildcards. However, some attributes—particularly operational attributes or those storing complex structures—do not. For example:
- Wildcard filters on
distinguishedNameormemberOfin Active Directory are not supported, because these attributes lack the required substring matching rule in their schema. - Attempting
(memberOf=*)or(distinguishedName=*admin*)will either match nothing or result in an error, even if the attribute appears to contain a string.
Distinguishing which attributes support wildcards requires examining the directory schema or consulting documentation. Attributes with substring matching rules (as defined in their schema) are search-capable with wildcards; those without only support equality searches or are not filterable at all.
A common pitfall is assuming that all text-looking attributes can be searched with wildcards. For instance, a dynamic group membership attribute may appear string-like but reject substring filters due to schema constraints.
Performance Implications: Efficient vs. Expensive Filters
LDAP directories optimize search performance using indexes. The type and construction of the filter determine whether indexes can be used efficiently:
- Equality filters (e.g.,
(sn=Smith)) are often highly efficient, leveraging attribute indexes. - Trailing wildcard filters (e.g.,
(cn=Jo*)) can use substring indexes if configured, remaining relatively fast. - Leading wildcards (e.g.,
(mail=*bob)) usually cannot be indexed, forcing the server to scan all entries and evaluate the substring after the wildcard. This degrades performance, especially in large directories.
For servers like OpenLDAP and Active Directory, the default indexes typically include equality and sometimes substring types. Leading wildcards and broad presence filters (such as (mail=*)) are inherently more expensive, so their use should be restricted in high-traffic environments or when operating on large datasets.
The impact is practical: while searching for users by prefix (as with autocomplete) is performant and scalable, searching by arbitrary substring or with leading wildcards can cause directory operations to become slow or resource-intensive.
Security Considerations: How Wildcards Affect Risk
Unrestricted wildcard use increases both security and information leakage risks:
- LDAP Injection: Injecting untrusted user input directly into filters—especially when wildcards are involved—may allow attackers to alter filter logic, potentially exposing more data than intended or accessing sensitive attributes. If input is not sanitized, attackers can craft input such as
*)(|(objectClass=*)to manipulate the filter logic. - Excessive Data Exposure: Broad wildcard filters, such as
(cn=*)or(mail=*), may return all directory entries or large sets of sensitive information, violating the principle of least privilege. - Resource Exhaustion Attacks: Overly broad or leading-wildcard filters can be abused to force the directory server to process expensive searches, leading to denial of service.
Mitigation starts with strict input validation, never allowing untrusted input (with wildcards or other filter operators) to be embedded directly into filter strings. Use of access controls that limit unnecessary attribute exposure is equally important.
Troubleshooting: Why Your Wildcard Search Didn’t Work
Common reasons why wildcard LDAP filters produce empty or unexpected results include:
- Schema Constraints: Attempting a wildcard filter on an attribute without a substring matching rule, such as
memberOfordistinguishedName, yields no matches even if data exists. - Incorrect Filter Syntax: Misplaced wildcards, missing parentheses, or invalid patterns result in failed queries.
- Indexing Limitations: Non-indexed attributes combined with leading wildcards (e.g.,
(sn=*Smith)) may cause searches to time out or fail to complete in time. - Access Controls: Directory ACLs may silently prevent access to attributes or entries, leading to an empty result.
To verify if an attribute supports wildcard searching, consult the directory’s schema or examine official documentation. Presence filters that return no results are often a sign of a schema or ACL limitation, not an empty directory or an error in filter construction.
Best Practices for Secure and Effective Wildcard Filters
To use LDAP wildcard filters safely and efficiently:
- Prefer equality or trailing-wildcard searches on indexed, schema-permitted attributes.
- Avoid leading-wildcard filters in production or large environments due to performance risks.
- Validate and sanitize user input, strictly limiting where wildcards can be introduced—never interpolate raw user input directly into LDAP filters.
- Check schema definitions to determine which attributes support substring filters before deploying queries.
- Monitor and audit directory access, paying special attention to filter patterns that might indicate overbroad searches or attempted injection attacks.
- Configure directory indexes appropriately if substring filters are required for high-traffic attributes (but weigh the administrative and performance overhead).
By designing filters with schema, security, and performance in mind, developers can provide flexible, reliable directory search capabilities while protecting both resources and data integrity.
Sources:
- OpenLDAP Software 2.4 Administrator's Guide
- Can more indexes improve performance? (OpenLDAP FAQ)
- ldap_search_s(3) - OpenLDAP Programming Manual
- Access Control (OpenLDAP 2.4 and 2.7 Admin Guides)