AAD and LocalAuthentication should not be mutually exclusive.

[zyofeng]

Currently if SetAzureTokenCredential is called, then TelemetryClient will include a bearer token when calling AI /v2.1/track endpoint, and even if local authentication is still enabled the endpoint will return 403 unless Metrics publisher role is granted.

This makes it harder to migrate existing apps to AAD because switching from local auth to AAD requires a code change/deployment using SetAzureTokenCredential on top of adding the roles in Azure.

Ideally something similar to Microsoft.Data.SqlClient where we can specify authentication method in the Connectionstring like this and avoid code change that would be great.
InstrumentationKey=xxxxxx-xxxx-xxx-xxx-xxxxxxx;IngestionEndpoint=https://xxxxxxxx.in.applicationinsights.azure.com/;LiveEndpoint=https://xxxxxx.livediagnostics.monitor.azure.com/;**Authentication=Active Directory Default**;

Alternatively if we can make local authentication work despite calling SetAzureTokenCredential.

[Piedone]

Where do you see a bearer token being included in the /track request? I'm debugging a 401 with that, getting it when I disable local auth, despite calling SetAzureTokenCredential and having a Managed Identity properly set up with the Monitoring Metrics Publisher role (and server-side tracking, as well as the Live Metrics control channel, work).

[Piedone]

I've opened an issue about this: #2893.

[zyofeng]

Where do you see a bearer token being included in the /track request? I'm debugging a 401 with that, getting it when I disable local auth, despite calling SetAzureTokenCredential and having a Managed Identity properly set up with the Monitoring Metrics Publisher role (and server-side tracking, as well as the Live Metrics control channel, work).

Im using wireshark to inspect the call from a .net console app.

[Piedone]

Ah OK, so you're not doing JavaScript client-side tracking. That makes sense, not sure why I thought that. Thanks!