Share via

Managed Identity Authentication Fails Between Azure OpenAI and Azure AI Search (403 / 400 Error)

Kumar, Kiran 0 Reputation points
2026-04-02T12:56:32.1966667+00:00

Hi all,

We're trying to connect Azure OpenAI to Azure AI Search using Managed Identity (no API keys), and we're running into a consistent authentication failure that I can't seem to resolve despite following the official docs closely.

Here's the full picture:

When our application calls Azure OpenAI, which in turn queries Azure AI Search using Managed Identity, the request fails with a 400 Bad Request on the OpenAI side. Digging deeper, when we test the same Managed Identity directly against the Azure AI Search endpoint, we get a 403 Forbidden, meaning the identity is reaching Search but being rejected at the authorization layer. The frustrating part is that if we swap out Managed Identity for an API key, with absolutely no other changes to the code, configuration, index, or query, everything works perfectly. This tells us the issue is isolated specifically to how Managed Identity is being authenticated or authorized against Azure AI Search, and not anything to do with the query logic or SDK setup.

We've tried both DefaultAzureCredential and ManagedIdentityCredential explicitly via the Azure SDK for .NET (C#), and both produce the same result.

The following RBAC roles have been assigned to the relevant managed identities on the Search resource (screenshots attached): Cognitive Services Contributor, Search Index Data Contributor, Search Index Data Reader, and Search Service Contributor.

We've also confirmed that Managed Identity is enabled on the Azure OpenAI resource, Azure AD-based authentication is enabled on the Search resource (not just API key mode), and the correct endpoint and index names are being used.

A few questions we're hoping the community or Microsoft team can shed light on:

  1. Is the scenario of Azure OpenAI calling Azure AI Search via Managed Identity fully supported end-to-end, or is there a known gap or limitation?
  2. Are there additional permissions or Search-specific configurations that are commonly missed and could cause a 403 even with the above roles assigned?
  3. Is there any SDK-specific setup required for Managed Identity that differs from API key authentication?
  4. Are there any known bugs or active issues related to this flow?

We're currently using API keys as a temporary workaround to keep things moving, but Managed Identity is a hard requirement for us from a security and compliance standpoint. Has anyone gotten this working successfully? A working example or even just a confirmation from the product team would go a long way. Thanks in advance!

Azure OpenAI in Foundry Models

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. SRILAKSHMI C 19,195 Reputation points Microsoft External Staff Moderator
    2026-04-06T16:39:21.0066667+00:00

    Hello Kumar, Kiran,

    What’s really happening

    You’re trying to make:

    Azure OpenAI → Azure AI Search using Managed Identity

    The Managed Identity is valid

    Azure AI Search is reachable

    But Search returns 403 (authorization failure)

    OpenAI wraps it as 400 Bad Request

    Switching to API key works instantly

    This proves:

    • Query logic is correct
    • Index + schema are correct
    • SDK usage is correct
    • Issue is specifically with Managed Identity in this integration path

    Key point

    End-to-end Managed Identity support for Azure OpenAI → Azure AI Search (built-in retrieval / “On Your Data”) is NOT fully supported today

    Even though:

    • Azure AI Search supports AAD + RBAC
    • Managed Identity works with Search directly
    • Your roles are correctly assigned

    The Azure OpenAI retrieval/cognitive search integration currently expects an API key, not Managed Identity.

    So what you’re hitting is not a misconfiguration it’s a product limitation / gap.

    Why you still see 403

    When you test MI directly against Search:

    • Token reaches Search
    • But request is rejected with 403

    This typically happens because:

    • The request path used by OpenAI’s retrieval feature does not fully honor MI-based auth yet
    • Or it doesn’t pass the token in the expected way for Search data-plane authorization

    So even with correct RBAC Search treats it as unauthorized

    If MI were fully supported, this is what would matter

    These are still valid checks

    1. Search configuration
    • Enable RBAC mode (AAD auth), not just API keys
    • Ensure data-plane access is allowed via AAD
    1. Role assignments

    Assign to Azure OpenAI Managed Identity

    • Search Index Data Reader - for queries
    • Search Index Data Contributor - if indexing
    • Scope - Search resource level
    • Allow ~5–10 mins for propagation
    1. Identity validation
    • Confirm System-assigned MI is enabled on OpenAI
    • Ensure the same identity has roles on Search
    1. Token audience

    Must be:

    https://search.azure.com/

    Wrong audience - 403 even if roles are correct

    1. SDK usage
    • DefaultAzureCredential is correct
    • No special handling required for Managed Identity
    • Keep SDKs updated:
      • Azure.AI.OpenAI ≥ 2.1.0
      • Azure.Search.Documents ≥ 11.x

    There’s no major bug in Azure AI Search rejecting valid tokens

    The gap is:

    Azure OpenAI’s built-in retrieval / “On Your Data” pipeline does not yet expose or fully support Managed Identity authentication to Search

    That’s why:

    • Direct MI usage - fails
    • API key - works

    Recommended approach

    1.Continue using Search API key for OpenAI - Search, Keep everything else unchanged

    2.Introduce a small middle layer:

    Azure OpenAI → Azure Function (Managed Identity) → Azure AI Search
    • Azure Function uses Managed Identity to call Search
    • OpenAI calls the Function instead of Search directly
    • No API keys exposed
    • Fully compliant with MI-based security

    This is the most common workaround in enterprise setups

    Answers to your questions

    Is end-to-end MI supported?

    Not for Azure OpenAI retrieval / Search integration today

    Supported only when you call Search directly yourself

    Are permissions missing?

    Based on your description: No, Roles and setup look correct

    Any SDK-specific requirement?

    No special configuration beyond DefaultAzureCredential -Just ensure latest SDK versions

    Known issues?

    Not a bug, but a known product limitation / gap - Documentation is fragmented, which causes confusion

    Please refer this

    Configure Search to use MI (system vs. user): https://learn.microsoft.com/azure/search/search-how-to-managed-identities

    Search RBAC client-code troubleshooting: https://learn.microsoft.com/azure/search/search-security-rbac-client-code#troubleshoot-common-errors

    OpenAI MI authentication guide: https://learn.microsoft.com/azure/ai-foundry/openai/how-to/managed-identity

    I Hope this helps. Do let me know if you have any further queries.

    Thank you!

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-04-02T12:57:07.5966667+00:00
    1. The scenario of Azure OpenAI calling Azure AI Search using Microsoft Entra ID/managed identity is supported.

    Azure AI Search supports connections to Azure OpenAI and Foundry via managed identities for skills and vectorizers, including the Azure OpenAI embedding skill and Azure OpenAI vectorizer. This is explicitly listed as a supported scenario for AI Search service connections using managed identities.

    Connections to Azure OpenAI, Foundry, and Azure Functions via skills/vectorizers include: Azure OpenAI embedding skill and Azure OpenAI vectorizer, among others.

    Configure a search service to connect using a managed identity – Supported scenarios

    So the end-to-end pattern (OpenAI → Search using Entra ID) is supported, but it is sensitive to RBAC and Search configuration.

    1. Common causes of 401/403 and what to verify

    From the documented troubleshooting for identity-based access to Azure AI Search and for Foundry/agents tools (which use the same RBAC model), the following are the key checks:

    a. RBAC roles on the Search resource

    For keyless (managed identity) access to an index:

    • For querying only: Search Index Data Reader
    • For indexing or write operations: Search Index Data Contributor
    • For service-level operations: Search Service Contributor

    If a 403 is returned, the most common cause is missing or insufficient roles:

    • 403 Forbidden → Identity lacks required role. Solution: assign the appropriate role (Search Index Data Reader for queries, Search Index Data Contributor for indexing). Role assignments can take up to 10 minutes to propagate.

    Connect your app to Azure AI Search using identities – Troubleshoot common errors

    For Foundry agents using Azure AI Search as a tool (same RBAC model):

    • Tool can’t access the index (401/403) → Missing RBAC roles (keyless auth). Resolution: assign Search Index Data Contributor and Search Service Contributor roles to the project’s managed identity.

    Connect an Azure AI Search index to Foundry agents (python) – Troubleshooting

    In the described setup, the managed identity already has Search Index Data Contributor, Search Index Data Reader, and Search Service Contributor, which are the correct roles. Ensure:

    • The roles are assigned on the correct Azure AI Search resource (same subscription/tenant, same service name as the endpoint being called).
    • The roles are assigned to the exact managed identity that the OpenAI resource is using (system-assigned vs user-assigned identity mismatch is a common pitfall).
    • At least 10–15 minutes have passed since role assignment to allow propagation.

    b. RBAC must be enabled on the Search service

    A 401/403 can also occur if RBAC is not enabled on the Search service:

    • 401 Unauthorized → RBAC not enabled on search service. Solution: enable role-based access in the Azure portal under Settings > Keys > Role-based access control.

    Connect your app to Azure AI Search using identities – Troubleshoot common errors

    In addition, if only RBAC is enabled and API keys are disabled, portal-based querying may fail unless configured correctly. One documented case of “no results” in Search Explorer was resolved by enabling API keys under Settings/Keys when only RBAC was enabled.

    Query on AI Search index (portal search explorer) returns nothing – Microsoft Q&A

    For the OpenAI → Search flow, ensure:

    • Role-based access control is enabled on the Search service.
    • If testing via portal or other tools, API keys may still need to be enabled for those tools, but the OpenAI integration should use Entra ID.

    c. Endpoint and index name correctness

    A 403 can also mask configuration issues; verify:

    • The endpoint used by OpenAI is exactly the Search service URL (https://<service-name>.search.windows.net).
    • The index name matches exactly (case-sensitive) the index in the Search service.

    If the endpoint or index name is wrong, other errors like ResourceNotFoundException are typical, but misconfigurations can complicate troubleshooting.

    Connect your app to Azure AI Search using identities – Troubleshoot common errors

    1. SDK-specific setup differences between API key and Managed Identity

    From the documented patterns:

    • API key authentication uses a key passed in headers or client options.
    • Managed identity uses Azure AD tokens via DefaultAzureCredential or ManagedIdentityCredential.

    The key SDK-specific requirements for managed identity are:

    • Ensure the environment where the code runs has a valid identity (system-assigned or user-assigned) and that the credential type used (DefaultAzureCredential or ManagedIdentityCredential) can resolve it. A CredentialUnavailableException indicates no valid credential found.
    • Ensure the Azure account/identity has access to the subscription and Search resource.

    Connect your app to Azure AI Search using identities – Troubleshoot common errors

    There is no additional Search-specific SDK setup beyond:

    • Using the correct endpoint.
    • Using an Entra ID credential instead of an API key.
    • Having RBAC enabled and roles correctly assigned.
    1. Other configuration and network considerations

    From the indexer and managed identity troubleshooting guidance:

    • If the Search service is configured with network restrictions (private endpoints, IP restrictions), ensure that the identity-based access is allowed and that network/firewall rules do not block the OpenAI resource or its outbound IPs.
    • If key authorization has been disabled on dependent resources, ensure that all connections use managed identity and that role-based permissions are in place.

    Error: Credentials provided in the connection string are invalid or have expired. – Troubleshooting common indexer errors

    1. Summary checklist for this scenario

    To get Azure OpenAI → Azure AI Search via managed identity working:

    1. On the Azure AI Search service:
      • Enable Role-based access control under Settings > Keys.
      • Optionally keep API keys enabled for non-OpenAI tools, but OpenAI should use Entra ID.
    2. On the managed identity used by Azure OpenAI (system-assigned or user-assigned):
      • Assign at least Search Index Data Reader for query-only scenarios.
      • Assign Search Index Data Contributor and Search Service Contributor if the integration needs write/index operations.
      • Confirm assignments are on the correct Search resource and allow time for propagation.
    3. In the client/OpenAI integration:
      • Use the correct Search endpoint (https://<service-name>.search.windows.net).
      • Use the exact index name (case-sensitive).
      • Use DefaultAzureCredential or ManagedIdentityCredential in a context where the identity is resolvable.
    4. Network and configuration:
      • Ensure no firewall or network restrictions block the Search service from being accessed by the OpenAI resource.

    If all of the above are satisfied, the documented behavior is that managed identity-based access to Azure AI Search should succeed, and 403 errors typically indicate either missing RBAC roles, RBAC not enabled on the Search service, or identity/endpoint mismatch.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.