[BUG] - AAD Guest account with DeveloperTool=VisualStudio - Login failed for user '<token-identified principal>' (Microsoft.Azure.Services.AppAuthentication using AzureServiceTokenProvider )

[felickz]

Describe the bug
When using AAD Guest Account (home tenant different then azure subscription tenant) to authenticate to SQL Server using the default constructor AzureServiceTokenProvider() or AzureServiceTokenProvider("RunAs=Developer; DeveloperTool=VisualStudio") getting error:
Login failed for user '<token-identified principal>'.

When overriding AzureServiceTokenProvider connection string to use RunAs=Developer; DeveloperTool=AzureCli - the issue is gone. Assuming the default constructor is using RunAs=Developer; DeveloperTool=VisualStudio - as this gives same connection problems.

Looking at the access tokens generated for each mechanism, the working token has attributes

• altsecid
• email
• home_oid
• idp
• rh

The non working token is missing all the above and has"uti". Interesting also, each has different OIDs... the bad token OID doesnt even exist as user in the directory. The good OID is the proper id for the guest user.

This same issue is not present when using same library to access Azure Keyvault... only reproducable for Azure SQL Server

Expected behavior
Authentication works for VisualStudio authentication same as CLI. Confirmed good using SSMS (using Universal with MFA with same guest user). NOTE: SSMS v.17 does not work with guest accounts only v18+

Actual behavior (include Exception or Stack Trace)
Login failed for user ''

To Reproduce
Steps to reproduce the behavior (include a code snippet, screenshot, or any additional information that might help us reproduce the issue)

1. Grant group based AAD access to an Azure SQL Server
2. Login to Visual Studio 2019 with Azure Service Authentication
3. Connect to SQL using Microsoft.Azure.Services.AppAuthentication to get Access Token

Environment:

• Microsoft.Azure.Services.AppAuthentication 1.5.0
• Windows 10.0.17763
• .NET CORE 3.1.3.1
• Visual Studio 2019 16.6.2 (ASA Service Provider - 1.0)

[nonik0]

@felickz Thank you for reporting. You are correct that by default Visual Studio authentication is attempted before Azure CLI, which explains why the default case is also failing.

So based off your information that Azure CLI tokens are working for you, this looks like a potential issue with the Visual Studio's token service. Let me follow up on this and I can update once I know more.

[nonik0]

@felickz Could you try setting tenantId when requesting the access token? E.g:
azureServiceTokenProvider.GetAccessTokenAsync(<resourceId>, <tenantId>);

It seems like the guest account would be the cause of those missing claims since its home tenant is different from the tenant you are authenticating against. Explicitly setting the tenantId when using VS auth can resolve that. Please let me know!

[ericsampson]

@nonik0 our team has been affected by this as well. It does seem to be an issue with the VS token service. Would you be able to help route the ticket to the right place? Thanks!!

[nonik0]

@ericsampson Does setting the tenantId as described above not work for your scenario, or could you elaborate on the specifics of what isn't working for you?

[engenb]

any update on this issue? my company has several contracted developers that we have added to our directory as guest accounts and we've experienced this same issue.

I first tried resolving this by setting AzureServicesAuthConnectionString to RunAs=Developer;DeveloperTool=VisualStudio;TenantID=<my tenant id>; but this did not resolve the issue.

we've worked around this by setting the environment variable AzureServicesAuthConnectionString to RunAs=Developer;DeveloperTool=AzureCli;

[anaismiller]

@engenb setting AzureServicesAuthConnectionString to RunAs=Developer;DeveloperTool=VisualStudio;TenantID=<my tenant id>; is not a considered setting. Settings are listed here and code here where decoding happens.

Can you try instead
AzureServiceTokenProvider("RunAs=Developer; DeveloperTool=VisualStudio").GetAccessTokenAsync(<resourceId>, <tenantId>); ?

[ericsampson]

@nonik0 I can try setting the tenant ID and see if that makes it work.

I just really want to avoid doing this, as there are hundreds of places across of our codebases that I would have to go make this fix.
It seems like a bug in the VS auth system, because it works fine when the Azure CLI handles the auth without me having to explicitly set a tenant. So that's why I'm trying to find out if I should file a bug with VS somehow, or here... Thanks!

[engenb]

Just to follow up, my team has worked around this by having contractor (guest user) developers set a windows environment variable AzureServicesAuthConnectionString: RunAs=Developer;DeveloperTool=AzureCli;.

After logging in with Azure CLI and selecting the correct subscription, everything works as expected. This way, we don't have to accommodate this via code or config in the project and this can be configured once in one spot. Previously, devs had to update this connection string value in each project they were working on. Ideally, this would natively work as expected with Visual Studio, but this is a perfectly adequate workaround.

[anaismiller]

@ericsampson @felickz have you resolved this?

[ericsampson]

@anaismiller the following workaround is not acceptable for us because it would mean we'd need to make this change in hundreds of repositories where we use AAD tokens:
AzureServiceTokenProvider("RunAs=Developer; DeveloperTool=VisualStudio").GetAccessTokenAsync(<resourceId>, <tenantId>);

We need a solution that works OOTB with Visual Studio.

[engenb]

@ericsampson , take a look at my previous comment. You don't necessarily need to make changes in each project. If you set an OS environment variable it will get picked up by the framework and take precedent over other configs. We develop primarily on Windows so we were able to set the environment variable in Windows (not via VS launchSettings.json) and it worked great with no changes to projects needed. I will admit there are details about your situation I'm likely not aware of, but maybe this will work for you as well.

[ericsampson]

@engenb sure I understand how that works, but trying to get every developer in our org to set that env var is a workaround, not a solution. Or spend time with IT trying to get the setting pushed out via GPO. It's a waste of our time for something that just needs to be fixed :)

[ericsampson]

The reason I say these things are a workaround is that this problem doesn't exist when using the Azure CLI token service. It's just the VS token service that has this issue.

[anaismiller]

@crmann1 for VS awareness

[ghost]

Hi @felickz. Thank you, for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

[ericsampson]

cc @anaismiller @crmann1 , bumping this so that the bot doesn't close it out. Any updates? Thanks

[felickz]

Hi @felickz. Thank you, for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

Unfortunately I have switched all my teams to use the AzureCli - having hundreds of developers not working in 30+ repos was not an option for me :(

[anaismiller]

@ericsampson Do you also only have this issue when working with Azure SQL and not with Azure KeyVault?

One possible explanation is that with VS auth, if no tenantId is provided, then it uses the default tenant when requesting the token and in this case, it is not the one from the Azure subscription, but the one from the guest account. On the other hand, AzureCli authentication does not have this tenant parameter.
However, this does not explain why it works with KV and not SQL.

[ericsampson]

@anaismiller we experience the issue with Key Vault.

The Azure CLI token works flawlessly for us, and the VS (and VSCode) ones do not.

When using Azure Identity, we have to do this everywhere:

var azureCredential = new DefaultAzureCredential(new DefaultAzureCredentialOptions
{
    ExcludeVisualStudioCredential = true,
    ExcludeVisualStudioCodeCredential = true
});

and the equivalent connection string for AzureServiceTokenProvider

Thank you for continuing investigating!! The difference between the two that you noticed sounds promising.

[ericsampson]

For us, our default tenant is definitely not where our Azure SaaS resources live, so what VS does isn't going to work for us.

[engenb]

Yes, this is what I have seen as well. Visual Studio is picking up the "default" tenant for guest accounts which is not our corporate directory. I've worked around this with a little helper class

public static class TokenCredentialFactory
{
    public static TokenCredential Get(IHostEnvironment env, string tenantId) =>
        env.IsDevelopment()
            ? new DefaultAzureCredential(new DefaultAzureCredentialOptions
            {
                SharedTokenCacheTenantId = tenantId,
                VisualStudioTenantId = tenantId
            })
            : new DefaultAzureCredential();
}

using this has resolved the issue for our developers with guest accounts

[ericsampson]

For us, the challenge would be adding that kind of workaround to 50 repos (or pulling in a little nuget library to do it, same difference), or trying to get the env var to every dev's workstation.

So if the fix is as easy as changing a couple lines of code in VS and VSCode, that would be awesome.

[engenb]

yup. I get it. you could spend the time updating to use the workaround or you could spend the time waiting for microsoft to fix the issue. I can bet you which would be faster ;)

[anaismiller]

Thanks @engenb for the suggestion! However, isn't that basically the same as calling AzureServiceTokenProvider("RunAs=Developer; DeveloperTool=VisualStudio").GetAccessTokenAsync(<resourceId>, <tenantId>); as you still have to explicitly put in the tenantId when you request the token?

[ericsampson]

[ericsampson]

I just like to keep working towards every affected VS/CSCode user benefitting by not having to hit and workaround this :) But yeah

[anaismiller]

I have created a bug internally on VS to enable all tokens returned for all tenants when requesting a token to have a similar experience as AzureCli.

[ericsampson]

@anaismiller thank you very much, but VSCode is affected as well. Can we create a ticket for it too?