{isLoaded && `
}} />}
Powered by Lucidworks Agent Studio
;
};
[localhost link]: http://localhost:3000/docs/5/fusion/reference/config-ref/pipeline-stages/query-stages/security-trimming-query-stage
[mintlify link]: https://doc.lucidworks.com/docs/5/fusion/reference/config-ref/pipeline-stages/query-stages/security-trimming-query-stage
[old doc.lw link]: https://doc.lucidworks.com/fusion/5.9/272
**Important**
This stage is deprecated in Fusion 5.9.0. The [Graph Security Trimming stage](/docs/5/fusion/reference/config-ref/pipeline-stages/query-stages/security-trimming-graph-query-stage), introduced in Fusion 5.6.0, uses a single filter query for all data sources instead of one filter query per data source.
This describes how to migrate your pre-Fusion 5.8 Graph Security Trimming query pipeline stage setup to Fusion 5.8 or later. It applies to deployments using:
* SharePoint Optimized V2 connector v1.1.0 or later
* LDAP ACLs V2 connector v1.4.0 or later to crawl Active Directory in Azure
* The LDAP ACLs V2 connector v1.2.0 or later to crawl Active Directory in LDAP
## Migration
To migrate a deployment that is crawling Active Directory to Fusion 5.8 or later, follow these steps.
### Update the datasource configurations
The SharePoint Optimized V2 and LDAP ACLs V2 datasources must index the content documents and ACL documents to the same collection. Ensure both datasources use the same value, `contentCollection`, for the field **ACL Collection ID**.
#### If using SharePoint-Optimized and LDAP-ACLs \< v2.0.0
Update the **ACL Collection Id** in the datasource configuration.
The SharePoint-Optimized and LDAP-ACLs datasources must index their `content_documents` and `acl_documents` to the same collection. Make sure the property **Security** -> **ACL Collection** in both datasources have the same value. In both datasources, SharePoint-Optimized and LDAP-ACLs, check the property **Security** -> **ACL Collection Id** and make sure it points to the same content-collection.
1. Navigate to **Indexing > Datasources**.
2. Open your SharePoint Optimized V2 or LDAP ACLs V2 datasource.
3. Under **Security**, update the configuration to use `contentCollection` as the **ACL Collection ID**. The **Security** checkbox must be checked for this field to appear.
4. Save the configuration.
Repeat this process for all required datasources.
#### If using SharePoint-Optimized and LDAP-ACLs >= v2.0.0
Recreate or update the datasources. If only updated, it is not possible to go back to the configuration of a previous plugin version.
By default, the LDAP-ACLs and SharePoint-Optimized V2 datasources will index the `content_documents` and `acl_documents` to the same collection.
1. Navigate to **Indexing > Datasources**.
2. Open your SharePoint Optimized V2 or LDAP ACLs V2 datasource.
3. Under **Graph Security Filtering Configuration**, select **Enable security trimming**.
Repeat this process for all required datasources.
### Clear the datasources and perform a full crawl
1. Navigate to **Indexing > Datasources**.
2. Open your SharePoint Optimized V2 or LDAP ACLs V2 datasource.
3. Click the **Clear Datasource** button, and choose yes.
4. Navigate to **Collections > Collections Manager**.
5. Verify that the `job_state` collection is empty.
6. Return to your datasource.
7. Click **Run > Start** to reindex your data.
Repeat this process for all required datasources.
The Security Trimming query pipeline stage restricts query results according to the user ID. While indexing the content, the Fusion connectors service stores security ACL metadata associated with the crawled items and indexes them as fields. The Security Trimming stage matches this information against the ID of the user running the search query.
This stage supports [asynchronous processing](/docs/5/fusion/getting-data-out/query-basics/query-pipelines/overview).
## Query pipeline stage condition examples
Stages can be triggered conditionally when a script in the **Condition** field evaluates to true.
Some examples are shown below.
Run this stage only for mobile clients:
```js wrap theme={"dark"}
params.deviceType === "mobile"
```
Run this stage when debugging is enabled:
```js wrap theme={"dark"}
params.debug === "true"
```
Run this stage when the query includes a specific term:
```js wrap theme={"dark"}
params.q && params.q.includes("sale")
```
Run this stage when multiple conditions are met:
```js wrap theme={"dark"}
request.hasParam("fusion-user-name") && request.getFirstParam("fusion-user-name").equals("SuperUser");
!request.hasParam("isFusionPluginQuery")
```
The first condition checks that the request parameter "fusion-user-name" is present and has the value "SuperUser".
The second condition checks that the request parameter "isFusionPluginQuery" is not present.
## Learn more
This topic describes how to troubleshoot issues with the Security Trimming query pipeline stage.
One of the most common issues that occurs when working with Fusion is that users do not see the search results expected from security trimming for one reason or another. This issue can show itself in two ways:
* Users see documents that they **should not** see.
* Users **do not see** documents that they **should** see.
## An Explanation of the Security Trimming Stage
The Security Trimming stage starts with a user ID. This ID can be a Windows user principal name, a Windows logon ID, an email address, an LDAP user ID, or any other type of identification that represents a search user.
Next, the stage sends your ID to all of the datasources in your application and returns a solr filter query that will trim the data for the specific user.
For example: You give Alfresco the user ID `admin` and the Security Trimming stage will return a filter query such as:
`+({!terms f=acls_ss}ADMIN__cmis_read,GROUP_Engineering,GROUP_SustainingEngineering__cmis_read,guest__cmis_read)`
Since Alfresco documents store the users/groups who have permission to view the document in a special solr field called `acls_ss`, this filter will only return a document if one of the values in the filter matches the `acls_ss` on the document.
## Troubleshooting
If you do not receive the expected results from the Security Trimming stage, use the following steps to troubleshoot:
1. Add `&debug=true` to your query so that you get the debug output that will contain the filters that were used when querying.
2. Obtain the filter query that was used for your query. This will contain the groups/user IDs that were matched against the `acl` field for your datasource’s documents in order trim your results.
3. Obtain a subset of the documents that were or were not supposed to be returned in your search results, and save the `acl` field for those results. For example, `acls_ss` from the previous section.
4. Compare the `acl` values that were in the filter query to the `acl` values that are on the documents. Search results are only shown when one or more of the `acl` values from the filter match the `acl` values of the documents.
* If the `acl` values on the document do not match what you expect from your datasource. For example, an Alfresco document gives permission to group XYZ, but that group does not appear in the `acls_ss` field:
* Make sure the datasource is up to date. It may have a stale index and need a fresh crawl.
* If the `acls_ss` is still incorrect, open a ticket with [Lucidworks Support](https://support.lucidworks.com/hc/en-us) for further assistance.
* If the ACL values in the filter query seem inaccurate. For example, you see groups you should not see or are missing groups you should see:
* Go into your source system and check that the users are actually in the groups that you are expecting them to belong to.
* If you are sure that the correct groups are not being returned for a user, open a ticket with [Lucidworks Support](https://support.lucidworks.com/hc/en-us) for further assistance.
## Configuration
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.