Azure Files permissions
Azure Files uses application permissions to retrieve content and permission metadata. Glean then uses the supported Azure share permissions, file-system access rules, and mapped identities to build search permissions for each item.
Separate application access from user access
The parent Microsoft 365 application's Azure roles let the connector read storage resources and files. The privileged read role lets the application retrieve content and permission information independently of an individual end user's file access.
Those application grants don't make the content visible to every Glean user. User and group permissions are evaluated separately. Assign the application roles as described in Set up Azure Files, rather than granting broader roles to end users.
Understand the access rules
The connector combines the following information when processing an item:
| Permission information | How Glean uses it |
|---|---|
| Azure role-based access control | Processes applicable user and group role assignments and the read capabilities in their role definitions |
| Default share permission | Uses a supported storage-account default share permission when configured. This supplies share-level access, not a bypass of file-system restrictions |
| New Technology File System (NTFS) access-control lists | Processes supported allow and deny entries for the file or folder |
| Azure deny assignments | Applies supported deny assignments and their exclusions to the mapped user set |
| Microsoft 365 identities | Resolves users, group memberships, and supported NTFS security identifier mappings through the associated parent connection |
A resolved deny removes access from the computed user set. File ownership is metadata, not an additional search-access grant. A supported default share permission doesn't override NTFS restrictions or applicable denies.
For user access granted through Azure role assignments, Glean requires both share-read control-plane and file-read data permissions. For Server Message Block (SMB) shares, examples are the Reader and Storage File Data SMB Share Reader roles, respectively. The crawl.enforceControlPlaneActionForRead flag controls the control-plane check and defaults to true. Setting it to false removes only that check. NTFS restrictions and applicable deny assignments still apply.
Keep identity information available
The parent Microsoft 365 connection must provide the identities and memberships needed for permission mapping. Azure role principals use Microsoft Entra identities, while file-system entries can use security identifiers that must be mapped to those identities.
If the required permission data or identity mapping isn't available, an item may be absent from search even when a user can open it in Azure. Check the parent identity crawl and the item's source permissions before changing any grants.
Review access-control limitations
The connector doesn't implement every Azure or Windows access-control feature. Standard NTFS allow and deny entries are supported, but object-specific and conditional entries can prevent permission processing or leave affected items without search grants.
Confirm compatibility before using shares that depend on advanced access-control entries, conditional Azure role assignments, or unusual deny-inheritance rules. Don't assume that a successful source-side access check proves equivalent behavior in Glean, and don't remove deny rules to make a test pass.
Hidden files and folders receive no search grants. This doesn't mean their content is never retrieved or retained, or that every descendant of a hidden folder is excluded.
Validate access before broader use
Test representative source permissions after the initial crawl and permission processing complete:
- Choose files with known allowed and denied users, including examples granted through groups.
- Confirm that an allowed user can find the expected file in Glean.
- Confirm that a user without source permission can't find the same file.
- Repeat the checks after a representative permission change and the relevant crawls and processing.
Azure Files content, share permissions, and Microsoft 365 identities refresh through different processing paths. Don't assume that a permission change is reflected immediately. If observed visibility differs from the intended source permissions, contact Glean Support before expanding use of the connection.
See also
- Azure Files overview describes indexed content, metadata, and result links.
- Troubleshooting provides checks for missing content and permission-mapping issues.