CODEWITHSUNDEEP
asp.netazurevisual-studio-2022c#-7.0defaultazurecredential
Ross Brasseaux
Ross Brasseaux

Reputation: 4150

ManagedIdentityCredential authentication failed: Access to the path ... is denied

My web application retrieves its secrets from our company's shared Azure Key Vault, and the permissions for that are granted via RBAC (role-based access control). This works great normally, but on my new computer I am getting the following error....

Exception thrown: 'Azure.Identity.AuthenticationFailedException' in System.Private.CoreLib.dll

An unhandled exception of type 'Azure.Identity.AuthenticationFailedException' occurred in System.Private.CoreLib.dll

ManagedIdentityCredential authentication failed: Access to the path 'C:\ProgramData\AzureConnectedMachineAgent\Tokens\20f36e17-204a-4e08-b190-bda27a9402cb.key' is denied.

The credentials instance is being loaded via the following code:

credentials = new DefaultAzureCredential(new DefaultAzureCredentialOptions()
            {
                VisualStudioTenantId = tenantId,
                SharedTokenCacheTenantId = tenantId,
                VisualStudioCodeTenantId = tenantId,
                InteractiveBrowserTenantId = tenantId,
            });

Strangely, this only happens on my new computer. My kneejerk response is to run VS2022 as administrator, but other developers are running it as themselves and are not having this issue.

Anyone run into this before?

Upvotes: 4

Views: 7989

Answers (2)

Jaxidian
Jaxidian

Reputation: 13511

I'm posting this as an alternative solution for those who are running into this problem for the same reasons that the OP was running into them. Here are a few things to look at, as well as the documentation that might suggest why this unexpected behavior is happening and how you might also be able to control/manipulate it:

  1. You might actually have a Managed Identity assigned for your local machine! Yes, I know, this sounds silly, but there are some ways this can happen. I'm not sure of all of them, but Azure Arc is one possible way this might happen and might be a possible reason why your new workstation has this problem but older ones (that presumably were not provisioned with Arc) do not.
  2. There is an order-of-operations that DefaultAzureCredential attempts to check, where Managed Identity is #3 in that list (as of Feb 2024). This might help you understand what options are still options if you want to just rely on this order-of-operations to manipulate the situation.
  3. If you want to short-circuit the Managed Identity behavior, you could always fall back to local.settings.json, which is #1 in that order-of-operations list. I know you don't want to hardcode your secrets in there and you want to dynamically get them from KV, but that's still an option here. You could have a line that looks like this inside of your Values object in there to dynamically pull the value at runtime for your dev environment. If you do this, be sure to also set AZURE_TENANT_ID and AZURE_CLIENT_ID for the client side of your handshakes. This will use your VS credentials to access KV, so there are still some permission things at play there (which is a good thing, but is a variable to consider).
    "AZURE_CLIENT_SECRET": "@Microsoft.KeyVault(VaultName=kv-name-goes-here;SecretName=secret-name-goes-here)",

Just to document the order-of-operations (in case URLs break or something), as of Feb 2024, DefaultAzureCredential pulls things in this order (copied from the above link, source goes to learn.microsoft.com):

  1. Environment - The DefaultAzureCredential will read account information specified via environment variables and use it to authenticate.
  2. Workload Identity - If the application is deployed to an Azure host with Workload Identity enabled, the DefaultAzureCredential will authenticate with that account.
  3. Managed Identity - If the application is deployed to an Azure host with Managed Identity enabled, the DefaultAzureCredential will authenticate with that account.
  4. Visual Studio - If the developer has authenticated via Visual Studio, the DefaultAzureCredential will authenticate with that account.
  5. Visual Studio Code - Currently excluded by default as SDK authentication via Visual Studio Code is broken due to issue #27263. The VisualStudioCodeCredential will be re-enabled in the DefaultAzureCredential flow once a fix is in place. Issue #30525 tracks this. In the meantime Visual Studio Code users can authenticate their development environment using the Azure CLI.
  6. Azure CLI - If the developer has authenticated an account via the Azure CLI az login command, the DefaultAzureCredential will authenticate with that account.
  7. Azure PowerShell - If the developer has authenticated an account via the Azure PowerShell Connect-AzAccount command, the DefaultAzureCredential will authenticate with that account.
  8. Azure Developer CLI - If the developer has authenticated via the Azure Developer CLI azd auth login command, the DefaultAzureCredential will authenticate with that account.
  9. Interactive browser - If enabled, the DefaultAzureCredential will interactively authenticate the developer via the current system's default browser. By default, this credential type is disabled.

Upvotes: 4

Ross Brasseaux
Ross Brasseaux

Reputation: 4150

I managed to resolve the error, at least in this instance, by excluding Managed Identity Credential from the list of sources when instantiating the DefaultAzureCredential class. You can do this via the DefaultAzureCredentialOptions class like so:

credentials = new DefaultAzureCredential(new DefaultAzureCredentialOptions()
            {
                VisualStudioTenantId = tenantId,
                SharedTokenCacheTenantId = tenantId,
                VisualStudioCodeTenantId = tenantId,
                InteractiveBrowserTenantId = tenantId,
                ExcludeManagedIdentityCredential = true // <-- added this line
            });

Still not sure what actually causes the issue though.

Upvotes: 4

Related Questions