Active Directory Connector for ACLs Connector and Datasource Configuration

The Active Directory Connector for ACLs indexes Active Control List (ACL) information into a configured "sidecar" Solr collection, so that it can be used by other connectors.

Once the users and groups are indexed into the ACL collection, the information is used during security trimming to determine all of the groups and nested groups to which a user belongs. With this information, a connector filters documents based on their ACL metadata. This ensures search results will only contain documents that user has permission to view.

During the security trimming stage, the ACL collection is queried using a Solr graph query, which creates a graph of the results using nodes from one document to another.

Graph Query

The ACL collection contains a lookup for all users and groups within your LDAP server.

This is used by the graph query to span out into all nested group relationships of a certain user. The graph query also allows your security trimming stage to input different forms of a username, including the user’s LDAP DN, domain\username, and, while still being able to fetch the user’s groups.

To use a graph query, it is essential to understand and adhere to graph query limitations.

For example, the graph parser only works in single node Solr installations or with SolrCloud collections that use exactly one shard. This means that the ACL collection must have exactly one shard, and the ACL collection must have exactly {num solr nodes} replicas. Failure to adhere to these limitations will result in incomplete user ACLs, and users will not see documents they expect to see.


Let’s say you want to run a security trimmed query for the user This type of username is called a "user principal name" in Active Directory. In order for the security trimming stage to run, it will need to use the following graph query:

{!graph from=inbound_ss to=outbound_ss}

This query will traverse the Active Directory tree as follows:

Active Directory Traversing

The result will be:

The returned IDs can now be used as a Solr filter (fq) to match against a document’s ACL metadata field and ensure the user only sees what they have access to.

The graph query can further traverse the Active Directory field. For example, it can map ldapGroup-dn to ldapGroup-sid, so you can match groups such as S-1-5-21-3623811015-3361044348-30300820-1013. This functionality is especially relevant for SharePoint and SMB2 connectors.

How to use the ACL collection

You need to provide the inputs:

Input Description Example

Start Links

Each LDAP or LDAPS URL that is crawled.


LDAP User Principal

The user principal account that crawls LDAP.

LDAP User Password

The password of the user that crawls LDAP.


LDAP Search Base

The base DN that performs the crawl.


LDAP User Base (optional)

A list of users that are permitted to access a specific LDAP base.


LDAP Group Base (optional)

A list of groups that are permitted to access a specific LDAP base.


LDAP User Filter (optional)

A custom attribute filter that finds user records in LDAP.


LDAP Group Filter (optional)

A custom attribute filter that finds group records in LDAP.


SOLR ACL Collection Name

The name of the ACL collection.


Index sAMAccountName Users (Active Directory only)

When active, a document is created in the ACL collection representing a user with an ID of sAMAccountName. This allows security trimming on the domain\username version of the username.


Index userPrincipalName Users (Active Directory only)

When active, a document is created in the ACL collection representing a user with an ID of userPrincipalName. This allows security trimming on the version of the username.


Handling a multi-domain Active Directory

For applications involving multi-domain Active Directory, you need one LDAP data source per domain. Here is an example of a multi-domain Active Directory:

Domain Type

parent domain

child domain

child domain

child domain

In this example, you must have several data sources:

Base DN: DC=na,DC=lucidworks,DC=com

Base DN: DC=can,DC=lucidworks,DC=com

Base DN: DC=sa,DC=lucidworks,DC=com

Please note that querying the Active Directory Global Catalog to have a single LDAP ACL datasource does not work, as the global catalog does not replicate the memberOf attribute of person objects. Doing so results in users not able to see the expected documents.

However, you may be able to set up Active Directory to replicate that attribute. This would allow you to use a single global catalog for your entire Active Directory forest, if desired.

Incremental Crawls

After a crawl has been finished successfully, all subsequent crawls are “incremental crawls”. Incremental crawls are only supported on Active Directory.

An incremental crawl uses the whenChanged attribute in order to fetch only records that have changed since the previous crawl(s). Additionally, the CN=Deleted Objects Active Directory location is queried to identify objects deleted since the last crawl.

Incremental crawls are typically run with a scheduled jobs in order to keep the ACL collection up-to-date. Because the crawls are incremental, these jobs should run very quickly.


When entering configuration values in the UI, use unescaped characters, such as \t for the tab character. When entering configuration values in the API, use escaped characters, such as \\t for the tab character.


The connector classic log directory, $FUSION_HOME/fusion/var/log/connectors/connectors-classic/ by default, contains the log file <ds-name>.log. Look here for diagnostic information to help with troubleshooting. This file is created the first time a crawl is started with the AD ACL connector.