Skip to main content
Sample LDAP filters for scoping which users and groups Lumos imports from Active Directory. Paste these into the Users Search Filter and Groups Search Filter fields on the connector, adapting the DNs to your environment. For the full setup steps, see Connecting Directories with Lumos.

​
Why import only a subset?

Four common reasons: a pilot or testing phase where you start with a controlled set of objects, least-privilege policies that keep out-of-scope users invisible to Lumos, performance in directories with hundreds of thousands of objects, and compliance rules that segregate which users a platform may see.

​
Including only members of specified groups

Users Search Filter:
How it works. The outer & requires both conditions: the object is a user, and it matches the membership clause. The OID 1.2.840.113556.1.4.1941 is the LDAP_MATCHING_RULE_IN_CHAIN matching rule, which includes users who are direct or nested members of the named group. The inner | makes membership in either group sufficient. objectClass=user also matches computer accounts in Active Directory. To exclude them, replace objectClass=user with objectCategory=person (see Restricting to person objects). Use cases: importing only a pilot security group, only the Finance or HR teams, or only the groups that define roles in your organization.

​
Including only specific groups

Groups Search Filter:
How it works. objectClass=group restricts the filter to group objects, and the | clause includes any group whose distinguishedName matches one of the listed DNs exactly. Use cases: managing only high-impact security groups, excluding distribution lists and legacy groups from large environments, or staging a rollout group by group.

​
Excluding disabled accounts

Add this condition to any users filter to skip disabled accounts:
The OID 1.2.840.113556.1.4.803 is a bitwise AND match, and bit 2 of userAccountControl is the disabled flag. The ! negates it, so only enabled accounts pass. As with the group-membership filter, use objectCategory=person in place of objectClass=user to also exclude computer accounts.

​
Restricting to person objects

The simplest useful users filter, excluding computers and other user-class objects:

​
Practical tips

  1. Verify group DNs. A group nested several OUs deep is easy to mistype. Confirm spelling and structure against the directory.
  2. Test filters in an LDAP browser first. LDAP Admin, Apache Directory Studio, and ADSI Edit all let you run a filter interactively and count the results before you put it in the connector.
  3. Use the matching-rule-in-chain OID deliberately. It’s what makes nested membership work, but it’s more resource-intensive on the directory. If you don’t have nested groups, omit it.
  4. Combine conditions. The clauses above compose with &. A pilot-group filter that also excludes disabled accounts is one filter, not two connections.
  5. Document your queries. Record which filters each connection uses and why, so nobody has to reverse-engineer why a user is or isn’t in Lumos.
For LDAP (non-AD) connections, the same filter syntax applies to the account search filter, minus the AD-specific OIDs and attributes. Standard clauses like (objectClass=inetOrgPerson) and attribute equality matches work on any compliant directory.