Describe the bug
I am using Managed Identities to connect to Azure Service Bus using the Service Bus SDK. To do this I use TokenProvider.CreateManagedIdentityTokenProvider(); as my token provider. In my Visual Studio settings I set the Azure account I use which has RBAC access to my Service Bus.
When I use my external Azure account (which is a Microsoft account) this connection fails, if I create a new user within my Azure tenant and connect with this instead it works. In Azure's RBAC the user name shows up slightly differently name#EXT#@mytenant.onmicrosoft.com rather than the usual [email protected]
Exception or Stack Trace
When using an external Azure account the exception is Microsoft.Azure.ServiceBus: Put token failed. status-code: 401, status-description: InvalidIssuer: Token issuer is invalid.
To Reproduce
Steps to reproduce the behavior:

Azure Service Bus Data ReceiverCode Snippet
var tokenProvider = TokenProvider.CreateManagedIdentityTokenProvider();
var messageReceiver = new MessageReceiver(endpoint, queueName, tokenProvider);
await messageReceiver.PeekAsync();
Expected behavior
I would expect any form of user in Azure to be able to interact with Service Bus with managed identities when RBAC has been configured in the same way.
Setup (please complete the following information):
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report
@EwanNoble , thank you for reporting this issue. We are doing some investigation and we should be providing you with our findings/recommendations.
I am experiencing the same issue when using the new Azure.Messaging.EventHubs library.
The token is created with DefaultAzureCredential.
Long story short: While doing some tests I was receiving a 401 Unauthorized error with the description "Issuer is not valid".
The issuer of a token in AAD is usually something like "https://sts.windows.net/{tenantId}/". My default tenant has "guid A" as its id, the tenant were my EventHub/ServiceBus is placed is "guid B".
What happens is that Visual Studio is going to obtain a token valid for the default AAD tenant and not the tenant we are actually using and targeting.
I was using Visual Studio Code before and I did not notice this issue. That's because Visual Studio Code is using Azure CLI as default authentication mechanism and in the CLI I was signed in and set the default subscription to the one where EH was.
The quick fix for me is then using AzureCli, login there and set the default subscription to be the one we are using.
We will then need to then set the Environment Variable "AzureServicesAuthConnectionString" to be "RunAs=Developer; DeveloperTool=AzureCli" as specified here: https://docs.microsoft.com/en-us/azure/key-vault/service-to-service-authentication#connection-string-support
The real fix would be having the Visual Studio team let the customers decide which AAD tenant should be used as default one.
Please review the sample for MSI and RBAC. That should fix the issue.
If it's still an issue, I recommend opening a ticket with the Visual studio repository.
Most helpful comment
Long story short: While doing some tests I was receiving a 401 Unauthorized error with the description "Issuer is not valid".
The issuer of a token in AAD is usually something like "https://sts.windows.net/{tenantId}/". My default tenant has "guid A" as its id, the tenant were my EventHub/ServiceBus is placed is "guid B".
What happens is that Visual Studio is going to obtain a token valid for the default AAD tenant and not the tenant we are actually using and targeting.
I was using Visual Studio Code before and I did not notice this issue. That's because Visual Studio Code is using Azure CLI as default authentication mechanism and in the CLI I was signed in and set the default subscription to the one where EH was.
The quick fix for me is then using AzureCli, login there and set the default subscription to be the one we are using.
We will then need to then set the Environment Variable "AzureServicesAuthConnectionString" to be "RunAs=Developer; DeveloperTool=AzureCli" as specified here: https://docs.microsoft.com/en-us/azure/key-vault/service-to-service-authentication#connection-string-support
The real fix would be having the Visual Studio team let the customers decide which AAD tenant should be used as default one.