[QUERY] Azure Identity logging with `IsAccountIdentifierLoggingEnabled`

[spowser]

trafficstars

Library name and version

Azure.Identity 1.8.2

Query/Question

I am attempting to use the IsAccountIdentifierLoggingEnabled option to troubleshoot a 403 issue when authenticating via the DefaultAzureCredential and I'm not seeing any log output that has the information suggested by that option.

What I am expecting to see but DO NOT is any of these items

• The Application or Client Identifier
• User Principal Name
• Tenant Identifier
• Object Identifier of the authenticated user or application

What I DO see in the log output

[Informational] Azure-Identity: DefaultAzureCredential.GetToken invoked. [Informational] Azure-Identity: VisualStudioCredential.GetToken invoked. [Informational] Azure-Identity: VisualStudioCredential.GetToken succeeded. [Informational] Azure-Identity: DefaultAzureCredential.GetToken succeeded.

Here is the test code I am using atm using library versions:

Azure.Data.AppConfiguration: 1.2.0 Azure.Identity: 1.8.2 Azure.Security.KeyVault.Secrets: 4.4.0

using AzureEventSourceListener listener = 
AzureEventSourceListener.CreateConsoleLogger(System.Diagnostics.Tracing.EventLevel.LogAlways);

DefaultAzureCredentialOptions options = new DefaultAzureCredentialOptions
{
	Diagnostics =
	{
		LoggedHeaderNames = { "*" },
		LoggedQueryParameters = { "*" },
		IsAccountIdentifierLoggingEnabled = true,
		IsLoggingContentEnabled = true,
	},
	ExcludeManagedIdentityCredential = true,
	ExcludeAzureCliCredential = true,
	ExcludeAzurePowerShellCredential = true,
	ExcludeEnvironmentCredential = true,
	ExcludeSharedTokenCacheCredential = true,
	ExcludeVisualStudioCodeCredential = true
	
};
var _configUri = "https://someappconfig.azconfig.io";
var kvUri = "https://somekeyvault.vault.azure.net/";
var azureCredential = new DefaultAzureCredential(options);
var keyVaultClient = new SecretClient(new Uri(kvUri), azureCredential);
var configClient = new ConfigurationClient(new Uri(_configUri), azureCredential);

var keyVaultSecret = keyVaultClient.GetSecret("Test").Value;

SecretReferenceConfigurationSetting configReference = new("Web:Test", keyVaultSecret.Id, "SomeLabel");
var addedConfigReference = configClient.SetConfigurationSetting(configReference, true).Value;

Is this a bug or am I missing something?

Environment

Windows 10 .NET Framework 4.8 and also tested on .NET 6.0.13 IDE: Visual Studio 17.4.3

[jsquire]

//cc: @schaabs

[jsquire]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[christothes]

Hi @spowser - I'm unable to reproduce this. When I set the option, I get the following output (with values redacted):

[Informational] Azure-Identity: Client ID: <guid>. Tenant ID: <guid>. User Principal Name: <email> Object ID: <guid>

Do you see the expected output with other credentials such as AzureCliCredential?

[spowser]

Hello @christothes I switched to just using AzureCliCredential and I see I am getting a token here

AzureCliCredential.GetToken succeeded. Scopes: [ https://myappconfig.azconfig.io/.default ] ParentRequestId: 5e0f0e51-1591-4d5e-8905-7b1a89cc51c0 ExpiresOn: 2023-02-18T08:37:01.0000000+00:00

but not seeing any output that resembles the description of what you're seeing

[christothes]

That's strange. Just to make sure there isn't something slightly different betwen what we are doing, here is my repro code -

using var logger = AzureEventSourceListener.CreateConsoleLogger();
var cred = new AzureCliCredential(
		new AzureCliCredentialOptions { Diagnostics = { IsAccountIdentifierLoggingEnabled = true } });
var kvUri = "https://foo.vault.azure.net/";
var secretName = "mySecret";
var keyVaultClient = new SecretClient(new Uri(kvUri), cred);
var keyVaultSecret = keyVaultClient.GetSecret(secretName);

[spowser]

That works great. So the difference seems to be between the classes DefaultAzureCredential and AzureCliCredential

[spowser]

I realize I could have been clearer when I said I switched to AzureCliCredentials. I simply excluded VisualStudioCredential and made the AzureCliCredentials the only thing being considered by DefaultAzureCredential

[spowser]

Further testing also shows that the logging for VisualStudioCredential is working if I use it rather than DefaultAzureCredential.

[christothes]

Great - thanks for confirming. It seems we have a bug in how this option is being passed down from DefaultAzureCredential to the selected credential.

[spowser]

Not to muddy the waters here (this might need a new ticket) but....my original need for this feature was to troubleshoot a 403 error with credentials I know have permissions to this particular resource. AzureCliCredential: Works in the OP code. configClient.SetConfigurationSetting() succeeds VisualStudioCrendential: 403 during the call to App Config configClient.SetConfigurationSetting(). Key Vault call works fine.

Compared both outputs from IsAccountIdentifierLoggingEnabled and the credentials match excluding the client id which I assume is because the client being used is in fact different between those two classes.

[christothes]

I believe we may have fixed this in the latest version through some refactoring to improve options cloning between credentials. Would you mind trying out that version?

[spowser]

Still getting a 403 while using VisualStudioCredential when I try 1.9.0-beta.2. I also attempted to confirm that my environment wasn't the cause by verifying with two others that also have proper permissions on the App Config resource.

For completeness, I tested:

• Explicit AzureCliCredential : 200
• Explicit VisualStudioCredential: 403
• DefaultAzureCredential with AzureCliCredential as the only option: 200
• DefaultAzureCredential with VisualStudioCredential as the only option: 403

[christothes]

I was referring to the original issue if seeing the effect of IsAccountIdentifierLoggingEnabled. The 403 is probably related to the different clientId as you mentioned.

[spowser]

Ah! Apologies! Yes, I can confirm I see the proper IsAccountIdentifierLoggingEnabled logging output using DefaultAzureCredential on 1.9.0-beta.2