Skip to main content
Sign in

Configure ACL indexing for SharePoint Optimized v2 with Azure AD using Microsoft Graph

  • Updated

Goal

Enable security trimming and ACL indexing in Fusion when using the SharePoint Optimized v2 connector in conjunction with Azure Active Directory via Microsoft Graph.

This guide also clarifies required permissions, connector behaviors, and expected output in Fusion 5.9.14+ when indexing ACL documents using SharePoint and LDAP connectors.

 

Environment

  • Fusion 5.9.14

  • SharePoint Optimized v2 connector (version 2.1.0, build 70)

  • LDAP ACLs v2 connector

  • Kubernetes (EKS)

  • Microsoft Azure Active Directory (Azure AD)

  • Microsoft Graph API

 

Guide

Ensure proper connector versions

Verify the installed connector versions using the blob manifest. Ensure that:

  • The lucidworks.sharepoint-optimized connector is installed with version 2.1.0

  • The connector SDK version is 4.2.0

  • The Enable security trimming option is checked

  • A valid ACL collection is specified in the ACL Collection ID field

Note: If the ACL collection field is missing in the connector UI, it may indicate the connector version is outdated. Upgrade to a version where this field is present.

 

Configure SharePoint and LDAP connectors in the same application

To enable graph-based ACL indexing:

  • Create a SharePoint Optimized v2 datasource

  • Create a corresponding LDAP ACLs v2 datasource

  • Configure both datasources to use the same output collection (ACLs and content must be indexed into the same collection)

  • Add a Graph Security Trimming stage in the query pipeline that references this collection

 

Grant required Microsoft Graph permissions

To enable Azure AD authentication and ensure successful indexing of users and groups, the Azure application must have the following Application (not Delegated) permissions:

  • Directory.Read.All

  • Group.Read.All

  • User.Read.All

After adding these permissions:

  1. Navigate to Azure Portal → Azure Active Directory → App registrations → [Your App] → API permissions

  2. Click Add a permission > Microsoft Graph > Application permissions

  3. Select the permissions listed above

  4. Click Grant admin consent to apply them

Note: GroupMember.Read.All is not required if Group.Read.All or Directory.Read.All is already granted.

 

Validate successful indexing

After permissions are granted:

  • Run the LDAP ACLs connector

  • Review logs for errors such as 403 Forbidden or Insufficient privileges

  • Confirm that /users/delta and /groups endpoints are returning data

  • Check for consistent and complete indexing of user and group ACL documents in Fusion

  • Compare the number of documents indexed with Azure AD’s reported totals

Note: Initial indexing may take several hours depending on volume. For example, indexing 400K users and 350K groups may take up to 24 hours.

 

Handle document duplication from aliases

If duplicate ACL documents appear for the same user, this may be due to multiple identity formats such as UPN, email, or Graph identity. Each alias is treated as a distinct identity in Microsoft Graph.

To reduce duplication:

  • Use JavaScript pipeline stages to filter duplicate ACL entries

  • Retain only a single identity format such as UPN or user mail

  • Log and inspect values using logger.info() in the stage script

 

Optional: Separate user and group indexing

To improve crawl performance:

  • Use separate LDAP ACLs connectors for users and groups

  • This enables scoping and may reduce crawl time and memory usage

Note: Microsoft Graph does not support native filtering in Graph calls for specific groups or users at the connector level. Scoping must be managed using Azure-level configurations such as dynamic groups or separate app registrations.

 

Proxy configuration format

If using a proxy, ensure the proxy URL is in the correct format:

proxy-host:port

Example:

proxy-dmz.intel.com:912

Incorrect formats such as //proxy-dmz.intel.com will result in parsing errors and connector validation failure.

 

Expected connector behaviors

  • Datasource execution state may show Aborted during early runs with insufficient permissions. Once corrected, the state should change to Running and eventually Successful

  • Each connector crawl indexes all documents (not just deltas), but once permissions are in place, counts between runs should remain consistent

 

Related documentation

Let me know if you’d like a follow-up article on using logger.info in JavaScript stages or filtering techniques for duplicate ACL documents.

Related articles

Powered by Zendesk