Looking for the old docs site? You can still view it for a limited time here.

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.

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 username@fqdn.com, 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 username@lucidworks.com. 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}id:username@lucidworks.com

This query will traverse the Active Directory tree as follows:

Active Directory Traversing

The result will be:

username@lucidworks.com
CN=username,OU=users,DC=lucidworks,DC=com
CN=developers,OU=groups,DC=lucidworks,DC=com
CN=engineering,OU=groups,DC=lucidworks,DC=com
CN=employees,OU=groups,DC=lucidworks,DC=com

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.