Azure AI Search SharePoint ACL query fails with HTTP 404 "User cannot be found" for the whole index when the querying user is not in a site's user list

The HTTP 404 is a known query-time SharePoint permission-filtering issue in the 2026-08-01-preview path, but no documented setting currently changes “user not found on this site” into “no SharePoint groups”; capture the failed request’s correlation data and open a Microsoft Support case for service-side investigation. ^1^

Answers to the specific questions

• Intended behavior or defect?
  The 404 User cannot be found failure is documented as a known issue for this preview query-time permission-filtering path. The general ACL contract also says evaluation failures do not produce partially filtered results, although its documented generic failure response is 5xx rather than your observed SharePoint-originated 404. ^2^ Therefore, the all-or-nothing result is consistent with the security model, but the specific 404 for a user absent from one site should be handled as a preview-feature issue requiring Microsoft investigation—not treated as proof that your ACL ingestion is wrong.
• Can an unknown user be treated as having no groups on that site?
  That behavior would require a service-side change. SharePoint site-group memberships are resolved by Azure AI Search at query time, using sharePointConnectorAppRegistration and each candidate document’s SharePointSiteUrl; the client does not perform or control that lookup. ^2^
• Is there a supported skip setting?
  No per-site or “ignore missing user” setting is documented. The same x-ms-query-source-authorization token activates both Microsoft Entra and SharePoint site-group enforcement when SharePoint group support is configured. ^3^
• Does this explain a five-distinct-site limit?
  The documented mechanism confirms that membership resolution is scoped by the site URL stored on candidate documents, so query-time work is site-specific. However, the available product documentation does not establish that this lookup causes a five-site limit. Treat those as separate issues unless Microsoft Support confirms the relationship.

Evidence to attach to the support case

For one failing user and one successful user against the same index, collect:

1. API version and UTC timestamp.
2. Index name and sanitized request body.
3. HTTP status, response body, response headers, and request/correlation ID.
4. Number of distinct SharePointSiteUrl values involved.
5. Whether the failing user exists in each affected site’s user list.
6. Results of an elevated-read diagnostic selecting document keys, UserIds, GroupIds, and SharePointSiteUrl.
7. Confirmation that an accessible document appears under elevated read but the delegated query fails.

Do not include delegated tokens, API keys, secrets, user email addresses, tenant-specific site URLs, or other identifiers in shared diagnostics. Elevated read requires Search Index Data Contributor or equivalent and must be used only for investigation, never to return unrestricted results to end users. ^1^

A minimal reproduction should isolate permission enforcement from ranking and agentic retrieval:

POST {{endpoint}}/indexes/{{index}}/docs/search?api-version=2026-08-01-preview
Authorization: Bearer {{search-request-token}}
x-ms-query-source-authorization: {{delegated-user-token}}
Content-Type: application/json

{
  "search": "*",
  "select": "key,SharePointSiteUrl,GroupIds",
  "top": 5
}

This also avoids the knowledge-base layer silently swallowing the source failure. Capture the direct Search response first, then provide the corresponding agentic-retrieval timestamp and correlation information.

Conditional checks

Only if they have not already been validated:

• Compare stored SharePointSiteUrl values with the exact source-site URLs. A URL mismatch is a documented cause in this path.
• For projected chunks, verify every chunk contains the ACL fields and SharePointSiteUrl through indexProjections.mappings.
• Confirm spg: values exist only where SharePoint site-group permissions apply.

The feature remains preview, is not covered by an SLA, and is not recommended for production workloads. For scenarios requiring the full SharePoint permission model and out-of-box security trimming, Microsoft documents a remote SharePoint knowledge source as the alternative architecture. ^3^

References

1. Troubleshoot SharePoint Permission Filtering - Azure AI Search
2. Query-Time ACL and RBAC Enforcement - Azure AI Search
3. Use a SharePoint Indexer to Ingest Permission Metadata - Azure AI Search