Azure AI Search (2026-05-01-preview): query-time SharePoint site-group resolution fails "No matching identity found for federated credential ID"

Question

Azure AI Search (2026-05-01-preview): query-time SharePoint site-group resolution fails "No matching identity found for federated credential ID"

Harishsingh Kandwal 0

I've been stuck on this for a few days and I'm fairly sure I've exhausted the config side, so hoping someone from the product team can take a look.

I'm using the preview SharePoint site-group enforcement at query time - sharePointConnectorAppRegistration on the index plus x-ms-query-source-authorization on the query, API version 2026-05-01-preview. Whenever a query actually triggers SharePoint group resolution, I get:

HTTP 400 Failed to authenticate with SharePoint using managed identity.No matching identity found for federated credential ID '<fic-id>'.Confirm that the federated credential exists on the Entra application registration and is linked to a system-assigned or user-assigned managed identity on this search service.

The frustrating part is that the indexer authenticates to SharePoint through the exact same managed identity → connector app federation and runs to success — it pulls content and the spg: ACLs without any issue. So the trust itself clearly works. It only breaks on the query-time path.

The <fic-id> in the error is exactly the FIC referenced by the index's sharePointConnectorAppRegistration.

What I can prove is working (this is the frustrating part):

Ingestion works. The SharePoint indexer runs to success and the managed-identity sign-in logs show a successful AAD Token Exchange — so the MI → connector-app federation is functional.
ACLs are correctly ingested onto every chunk. An elevated-read query (x-ms-enable-elevated-read: true) returns documents where each chunk has spg:-prefixed values in GroupIds (e.g. spg:https://<tenant>.sharepoint.com/sites/<site>:52), a populated SharePointSiteUrl, and UserIds. So the data and index projections are right.
The permission filter works. A query with no query-source header returns HTTP 200 with zero results (everything trimmed, as expected with no identity supplied); elevated read returns the documents. So trimming is active and correct.

What fails: only the query-time SharePoint site-group resolution. The moment a valid same-tenant end-user token (audience https://search.azure.com) is passed via x-ms-query-source-authorization, I get the 400 above. The message is the search service authenticating to SharePoint via the MI/FIC — before the caller's membership is evaluated — so it's not user-specific and reproduces with any valid same-tenant token.

Configuration (matches the docs):

Search service on Basic, single tenant, no Conditional Access.
Index: permissionFilterOption: "enabled", UserIds/GroupIds permission-filter fields, SharePointSiteUrl field with sharepointSiteUrl: true (projected onto every chunk via index projections; two-index parent + chunk pattern).
sharePointConnectorAppRegistration = { applicationId: <connector app client ID>, federatedCredentialId: <FIC object ID>, tenantId: <SharePoint tenant ID> }.
Connector app: SharePoint User.Read.All + Sites.Selected, Graph Files.Read.All + Sites.Selected, admin-consented. Explicit per-site grant on the target site at FullControl (via Grant-PnPEntraIDAppSitePermission) — the same grant the indexer uses successfully to ingest content and spg: ACLs.
Federated credential: issuer .../{tenant}/v2.0, subject = search service MI principal ID, audience api://AzureADTokenExchange.

Already ruled out:

federatedCredentialId is the FIC's object ID (not app object ID, app client ID, MI principal ID, or FIC display name) — verified against Graph.
Reproduced with both system-assigned and user-assigned MI (indexer confirmed running through the UAMI); no change.
Waited >10 hours, plus disable/re-enable of the identity with subject updated; no change.
No Conditional Access on the tenant.
Per-site access is not the issue - the app holds a FullControl grant on the target site, and the indexer proves that grant works by ingesting content and spg: ACLs through it.The <fic-id> in the error is exactly the FIC referenced by the index's sharePointConnectorAppRegistration. What I can prove is working (this is the frustrating part):
- Ingestion works. The SharePoint indexer runs to success and the managed-identity sign-in logs show a successful AAD Token Exchange — so the MI → connector-app federation is functional.
- ACLs are correctly ingested onto every chunk. An elevated-read query (x-ms-enable-elevated-read: true) returns documents where each chunk has spg:-prefixed values in GroupIds (e.g. spg:https://<tenant>.sharepoint.com/sites/<site>:52), a populated SharePointSiteUrl, and UserIds. So the data and index projections are right.
- The permission filter works. A query with no query-source header returns HTTP 200 with zero results (everything trimmed, as expected with no identity supplied); elevated read returns the documents. So trimming is active and correct.
What fails: only the query-time SharePoint site-group resolution. The moment a valid same-tenant end-user token (audience https://search.azure.com) is passed via x-ms-query-source-authorization, I get the 400 above. The message is the search service authenticating to SharePoint via the MI/FIC — before the caller's membership is evaluated — so it's not user-specific and reproduces with any valid same-tenant token. Configuration (matches the docs):
- Search service on Basic, single tenant, no Conditional Access.
- Index: permissionFilterOption: "enabled", UserIds/GroupIds permission-filter fields, SharePointSiteUrl field with sharepointSiteUrl: true (projected onto every chunk via index projections; two-index parent + chunk pattern).
- sharePointConnectorAppRegistration = { applicationId: <connector app client ID>, federatedCredentialId: <FIC object ID>, tenantId: <SharePoint tenant ID> }.
- Connector app: SharePoint User.Read.All + Sites.Selected, Graph Files.Read.All + Sites.Selected, admin-consented. Explicit per-site grant on the target site at FullControl (via Grant-PnPEntraIDAppSitePermission) — the same grant the indexer uses successfully to ingest content and spg: ACLs.
- Federated credential: issuer .../{tenant}/v2.0, subject = search service MI principal ID, audience api://AzureADTokenExchange.

Is this a known defect in the 2026-05-01-preview query-time SharePoint site-group resolution path or is there an additional binding required specifically for the query-time path — beyond the FullControl site grant and the managed-identity → connector-app federation that ingestion already uses successfully? issue1

elevated

Harishsingh Kandwal 0 Reputation points

2026-08-11T12:22:15.51+00:00

Hi @Ajay Rathod

Thanks for commenting.

We don't have any Conditional Access policies for the user I'm testing with. I've verified this on two different tenants, and neither has Conditional Access configured for the user but it's not working on either tenant.
Ajay Rathod 445 Reputation points Microsoft External Staff Moderator

2026-08-17T02:29:25.2833333+00:00

Hi @Harishsingh Kandwal

Thanks for update, we are looking into and we will get back to you.

2 answers

Your answer

Harishsingh Kandwal 0 Reputation points

2026-08-11T12:22:15.51+00:00

Hi @Ajay Rathod

Thanks for commenting.

We don't have any Conditional Access policies for the user I'm testing with. I've verified this on two different tenants, and neither has Conditional Access configured for the user but it's not working on either tenant.
Ajay Rathod 445 Reputation points Microsoft External Staff Moderator

2026-08-17T02:29:25.2833333+00:00

Hi @Harishsingh Kandwal

Thanks for update, we are looking into and we will get back to you.

Answer 1

Allan Solomon Mejia 9,000

Hello @Harishsingh Kandwal

Thank you for raising this question.

Based on the Azure AI Search preview API behavior, queryTime (or similar timing information returned in query responses) is intended as diagnostic telemetry to help measure the execution time of an individual search request. It is not documented as a value that is shared or synchronized across concurrent queries or sessions.

If you're observing queryTime values that appear to be identical or shared between requests when using the 2026-05-01-preview API, it would be helpful to clarify a few details:

Are the requests executed concurrently or sequentially?
Are they targeting the same search service, same index, and same replica configuration?
Are you using semantic, hybrid, or vector search?
Can you share a minimal request/response example (with sensitive information removed) showing the identical queryTime values?

It's also worth verifying whether the observed value is:

The actual end-to-end query execution time,
A server-side processing metric,
Or a cached/aggregated diagnostic value introduced in the preview API.

Since this behavior is specific to the 2026-05-01-preview API version, there may be implementation differences from generally available API versions. Preview APIs can introduce new fields or change telemetry behavior before general availability.

If you can reproduce the behavior consistently with a minimal sample, it would help determine whether this is:

Expected behavior for the preview API,
A documentation gap,
Or a potential issue that should be reviewed by the Azure AI Search engineering team.

A minimal reproducible example, including the request payload, response, and whether the behavior occurs only with 2026-05-01-preview or also with the latest GA API version would help confirm whether this is expected preview behavior or a service issue.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Harishsingh Kandwal 0 Reputation points

2026-08-11T12:27:25.12+00:00

Hi @Allan Solomon Mejia

Thanks for the reply, but I think this is answering a different question- mine isn't about a queryTime telemetry field or timing values.

The issue is that query-time SharePoint site-group resolution fails with HTTP 400: "Failed to authenticate with SharePoint using managed identity. No matching identity found for federated credential ID".

You can also see the error in the attached screenshots.
Allan Solomon Mejia 9,000 Reputation points

2026-08-11T15:01:01.9033333+00:00
Hi @Harishsingh Kandwal

Thank you for the clarification, and you're correct. My previous response addressed a different issue.

Based on the configuration and testing you've provided, this appears to be isolated specifically to the query-time SharePoint site-group resolution path in the 2026-05-01-preview API.

Microsoft documents that SharePoint site-group enforcement at query time requires:

permissionFilterOption: "enabled"

UserIds and GroupIds permission-filter fields

spg:-prefixed SharePoint group IDs

A SharePointSiteUrl field with sharepointSiteUrl: true

sharePointConnectorAppRegistration containing the application ID, tenant ID, and federated credential object ID

The caller's token supplied through x-ms-query-source-authorization

From what you've shown, those requirements appear to be satisfied. Microsoft also states that the search service uses sharePointConnectorAppRegistration server-side to resolve the caller's SharePoint group memberships.

The key point here is that your indexer successfully authenticates using the same managed identity/federated credential and successfully ingests the spg: ACL metadata, while authentication fails only when Azure AI Search tries to perform SharePoint group resolution during a query.

There is also another Microsoft Q&A case reporting the same "No matching identity found for federated credential ID" behavior with 2026-05-01-preview. In that case, Microsoft staff similarly narrowed the issue to query-time SharePoint site-group resolution and requested service details and request/correlation IDs for further investigation.

Given that you've also ruled out Conditional Access, I don't see an additional documented binding that should be required beyond the configuration you've already described.

However, it was confirmed by @Ajay Rathod (comment above) that this is a product limitation.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Answer 2

Ajay Rathod 445 Microsoft External Staff Moderator

Thanks for reaching out to Q&A

Could you please confirm if you are using Conditional Access policies.
Currently, the SharePoint Indexer does not support Microsoft Entra ID Conditional Access policies. As a result, when Conditional Access is enabled on the tenant, the SharePoint connector is unable to authenticate successfully, preventing SharePoint ACL ingestion and query-time permission evaluation.

At this time, this is a product limitation and there is no supported workaround that allows the SharePoint Indexer to authenticate while Conditional Access policies are enforced.

0 comments