Active Directory Connector for ACLs

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. See How to use the Active Directory ACL collection.

This connector is used for security purposes. It does not crawl the Active Directory for data. The output of this connector is not affected by any index profile and will not be visible in queries.

Platform versions

Starting in Fusion 5.1.0, the Active Directory Connector for ACLs is available in V2 platform version.

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.

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.