-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG]Azure.Identity 1.13 Breaks DefaultAzureCredential On DevBox #46679
Comments
Thank you for your feedback. Tagging and routing to the team member best able to assist. |
This is possibly related to #46653 |
We're also running into this error running on our DevBox. We're using the Azure.Identity in combination with the
And its complete StackTrace:
|
Thanks for reporting - I am investigating. |
Hi @keggster101020 Also, could you enable logging and share that with me for the failure scenario? For console output, you would just need to add the following line to your program. using AzureEventSourceListener listener = AzureEventSourceListener.CreateTraceLogger(); If you need to log the output somewhere other than the console, this is described in these docs. var options = new DefaultAzureCredentialOptions
{
ExcludeEnvironmentCredential = true,
ExcludeWorkloadIdentityCredential = false,
ExcludeManagedIdentityCredential = false,
ExcludeAzureDeveloperCliCredential = true,
ExcludeSharedTokenCacheCredential = true,
ExcludeVisualStudioCredential = true,
ExcludeVisualStudioCodeCredential = true,
ExcludeAzureCliCredential = true,
ExcludeAzurePowerShellCredential = true,
ExcludeInteractiveBrowserCredential = false
};
var cred = new DefaultAzureCredential(options); |
Same issue is happening from Azure DevOps pipelines while connecting to an Azure SQL Database within an AzureCli@2 task. Pipeline is executing EF Core SQL migrations executable against Azure SQL connecting as the pipeline identity (federated ARM service connection). Upgrading to 1.13.0 breaks with a very similar error. Downgrading back to 1.12 resolves the issue. Not sure which token source is being picked up in 1.12 but sounds like it should use
|
@christothes I can look to grab a more official repro when I get some time (I tore down the devbox as part of the testing). However, part of my scenario was also access key vault using configuration builder extensions and the error @rdvanbuuren-gasunie posted above should be reflective of the error that I saw as well. Also, I did test the DefaultAzureCredential scenario disabling all providers except VS and interactive and I can confirm that that did resolve my issue. However, I still see this as a regression since prior to 1.13.0 the logic was as I described above: failures wouldn't break the entire chain they would only be thrown back if nothing in the chain resolved. |
@keggster101020 I totally agree that a change of behavior would be a regression, I was only asking about the alternative config for troubleshooting purposes since I cannot reproduce this locally. When I fetch a token using |
Hi @keggster101020. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue. |
@keggster101020 or @rdvanbuuren-gasunie - could you share the relevant parts of your configuration for the credential that reproduces the error in that scenario? |
Yes, of course! We're runnig a .NET 4.8 website using IISExpress on a DevBox, with the following configuration in the Web.config: <configuration>
<configSections>
<section name="configBuilders" type="System.Configuration.ConfigurationBuildersSection, System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" restartOnExternalChanges="false" requirePermission="false" />
</configSections>
<configBuilders>
<builders>
<add name="AzureKeyVault" vaultName="${KEY_VAULT_NAME}" type="Microsoft.Configuration.ConfigurationBuilders.AzureKeyVaultConfigBuilder, Microsoft.Configuration.ConfigurationBuilders.Azure, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</builders>
</configBuilders>
<appSettings configBuilders="AzureKeyVault">
<!-- From KeyVault -->
<add key="ClientSecret" value="" />
</appSettings>
</configuration> This should load the ClientSecret from the KeyVault secrets into the appSetting. If you need anymore information, I'm happy to help! |
@christothes for the Azure DevOps Workload/Federated Identity issue (see my comment above), shall I open a new issue or keep it in this thread? |
I believe that issue is fixed by #46711 |
Library name and version
Azure.Identity 1.13
Describe the bug
My code is using
DefaultAzureCredential(true)
to authenticate to remote azure resources. After upgrading Azure.Identity to 1.13 a handful of users are noting that they are getting the following error when running inside of Microsoft DevBox:There are no assigned identities to these DevBoxes (we are using the
devbox.microsoft.com
instances not selfhosted). Downgrading to 1.12 seems to have resolved this issue but putting this bug here as it seems like the detection logic aroundDefaultAzureCredential
may be incorrect in 1.13.I was under the impression that
DefaultAzureCredential
was a chained credential and that any failures in the chain would only be thrown back to the user if none of the credentials in the chain succeeded. However, the interactive popup never showed up, also some users have the VSCredential and the MI credential error happens seemingly as soon as it fails.Expected behavior
Using
DefaultAzureCredential(true)
inside a DevBox VM with no managed identity would attempt other credentials in the chain before throwing an exception back to the user.Actual behavior
DefaultAzureCredential(true)
throws an exception on DevBoxes if there is no MSI attached to the devbox and doesn't attempt any further credential operations.Reproduction Steps
new DefaultAzureCredential(true).GetTokenAsync(<some token request context>)
Environment
Microsoft Devbox (https://devbox.microsoft.com/)
The text was updated successfully, but these errors were encountered: