Azure-sdk-for-net: [BUG] External Azure account failing when used for Managed Identity in Visual Studio

Created on 5 Nov 2019  路  4Comments  路  Source: Azure/azure-sdk-for-net

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:

  • Use an external user in Azure, for me it shows the user Source as Microsoft Account
    image
  • Grant this user access to the service bus through RBAC, I gave it the permission Azure Service Bus Data Receiver
  • Attempt to interact with the service bus

Code 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):

  • IDE : Visual Studio 2019 16.3.7
  • Version of the Library used: Tested on Microsoft.Azure.ServiceBus package versions 3.4.0 and 4.1.0

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

  • [x] Bug Description Added
  • [x] Repro Steps Added
  • [x] Setup information Added
Client Service Attention Service Bus bug

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.

All 4 comments

@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.

Was this page helpful?
0 / 5 - 0 ratings