azure function ManagedIdentity request exception during GetToken

Question

Since 28. April some of our azure functions suddenly started to get the following exception when calling the system-assigned ManagedIdentity getToken endpoint using the ManagedIdentityCredentials class.

ManagedIdentityCredential authentication unavailable. Multiple attempts failed to obtain a token from the managed identity endpoint.

The error does not occur always, in our development environment it occurs in 1 out of 10 requests. Playing around with the retry policy (as suggested by the error message) did not fix the problem.

Azure.Identity.CredentialUnavailableException: ManagedIdentityCredential authentication unavailable. Multiple attempts failed to obtain a token from the managed identity endpoint. ---> MSAL.NetCore.4.67.2.0.MsalServiceException: ErrorCode: managed_identity_request_failed Microsoft.Identity.Client.MsalServiceException: Retry failed after 6 tries. Retry settings can be adjusted in ClientOptions.Retry or by configuring a custom retry policy in ClientOptions.RetryPolicy. (An attempt was made to access a socket in a way forbidden by its access permissions. (169.254.169.254:80))

Multiple azure functions that are untouched since multiple months show this behaviour as well as newly created ones.

Expected behavior: ManagedIdentityCredential should successfully get the token and proceed with execution.

Actual behavior: The token cant be aquired leading to an exception and a failed operation.

Reproduction Steps

We use Azure.DigitalTwins.Core 1.4.0 to get data from the Azure Digital Twins service. The DigitalTwinsClient is registered as singleton and gets an instance of ManagedIdentityCredential as TokenCredential new DigitalTwinsClient(new Uri(url), new ManagedIdentityCredential(), ... Later on the client.GetDigitalTwin method is called which triggers the getToken

Environment

Details regarding our DEV environment:

Azure function(s):

• .net 8 isolated
• 32bit
• using system assigned managed identity

OS:

• Windows
• Location: West Europe
• Runtime version: 4.1038.300.25164

App service plan:

• Pricing: Y1
• Zone redundant: Disabled
• Consumption

Answer 1

Hi, this is not an issue with your code; it’s actually a platform bug that was introduced at the end of April. Specifically, it affects Windows Functions running in Consumption or Y1 plans on 32-bit. What happens is that the process responsible for exposing the Managed Identity endpoint (the sidecar that listens on 127.0.0.1) sometimes starts too late, or doesn’t start at all.

When this process fails, the IDENTITY_ENDPOINT environment variable ends up missing. At that point, the SDK (ManagedIdentityCredential) tries to fall back to IMDS by calling <removed address>, but since this IP is blocked on Windows App Service, you get the typical "socket in a way forbidden..." exception.

This is a known issue, already being tracked on GitHub in issues #10189 and #10238 for the Functions runtime.

If you want to confirm whether you're hitting this exact problem, you can open Kudu (Console) while the error is happening and simply run echo %IDENTITY_ENDPOINT%. If it returns empty, you’re indeed facing this specific bug.

The easiest way to get around it is to switch your app to run in 64-bit mode — in that configuration, the sidecar always starts correctly. Alternatively, moving the app to a Linux Consumption or Premium plan also avoids the issue, since Linux directly uses IMDS and doesn’t rely on this sidecar process. There’s also a patch rolling out: if you update your FUNCTIONS_EXTENSION_VERSION to ~4.1045 or newer, that should fix the problem as well. In the meantime, adding some retry logic can help mitigate the symptoms, even if it doesn’t solve the root cause.

As general advice, it’s a good idea to reuse a single instance of DigitalTwinsClient or HttpClient per process, to avoid exhausting available ports, and make sure Always On is enabled if you're using Dedicated or Premium plans. Lastly, I’d recommend keeping an eye on Azure Service Health and the GitHub thread to follow the official progress on the fix.

Once you switch to 64-bit (or to Linux), token requests should go back to 100% success and the exception will disappear.

Let me know if you need help applying the workaround.

Answer 2

Hi Patrick,

If you’ve already moved your Azure Functions to 64-bit and are still seeing Managed Identity errors, the next thing to try is updating your function app to the latest version of the Azure Functions runtime. In the Azure Portal, set FUNCTIONS_EXTENSION_VERSION to the newest value available, for example ~4.1045 or higher. After making this change, make sure to restart your function app completely. A full restart is important to load the new runtime and properly set up Managed Identity.

If updating and restarting don’t fix it, consider switching your function app to a Premium plan (like EP1). Premium plans keep your app running all the time and usually avoid these Managed Identity issues and cold start delays.

Also, check your function app’s configuration for any special networking settings, like VNet integration or outbound restrictions. Sometimes these settings can block access to the Managed Identity endpoint and cause token errors.

If you do these steps and the problem still happens, try logging the values of IDENTITY_ENDPOINT and IDENTITY_HEADER when your function starts. If those values are missing, it shows there’s an Azure platform problem with Managed Identity for the app instance.