MSI with ADLS gives invalid resource

[rahuldutta90]

Description

Usi MSI with ADLS gives an error with an invalid resource

Script/Steps for Reproduction

1. Go to https://rc.portal.azure.com.
2. Click the top right powershell-looking icon to launch Cloud Shell:
   o
3. If you see a Bash window open at the bottom, toggle from Bash to PowerShell.
4. Try running the following cmdlet:
   o $files = Get-AdlStoreChildItem -Account sandboxadl -Path / -Debug
5. Observe the error output

Module Version

Current version

Get-Module -ListAvailable

Environment Data

$PSVersionTable

Debug Output

PS Azure:\> $jobs = Get-AdlCatalogItem -Account sandbox -ItemType Database -Debug
DEBUG: 8:43:29 PM - GetAzureDataLakeAnalyticsCatalogItem begin processing with ParameterSet '__AllParameterSets'.
 
Confirm
Continue with this operation?
[Y] Yes  [A] Yes to All  [H] Halt Command  [S] Suspend  [?] Help (default is "Y"): A
DEBUG: 8:43:32 PM - using account id 'MSI@50342'...
DEBUG: [Common.Authentication]: Authenticating using Account: 'MSI@50342', environment: 'AzureCloud', tenant: '72f988bf-86f1-41af-91ab-2d7cd011db47'
DEBUG: [HttpClientOperations]: Adding Header 'Metadata'
DEBUG: [Common.Authentication]: Authenticating using Account: 'MSI@50342', environment: 'AzureCloud', tenant: '72f988bf-86f1-41af-91ab-2d7cd011db47'
DEBUG: [HttpClientOperations]: Adding Header 'Metadata'
DEBUG: [Common.Authentication]: Authenticating using Account: 'MSI@50342', environment: 'AzureCloud', tenant: '72f988bf-86f1-41af-91ab-2d7cd011db47'
DEBUG: [HttpClientOperations]: Adding Header 'Metadata'
DEBUG: Checking Cache request http://localhost:50342/oauth2/token?resource=https%3A%2F%2Fdatalake.azure.net&api-version=2018-02-01
DEBUG: ============================ HTTP REQUEST ============================
 
HTTP Method:
GET
 
Absolute Uri:
http://localhost:50342/oauth2/token?resource=https%3A%2F%2Fdatalake.azure.net&api-version=2018-02-01
 
Headers:
Metadata                      : true
 
Body:
 
 
 
Get-AdlCatalogItem : The operation was canceled.
At line:1 char:9
+ $jobs = Get-AdlCatalogItem -Account sandbox -ItemType Database -Debug
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : CloseError: (:) [Get-AzDataLakeAnalyticsCatalogItem], TaskCanceledException
+ FullyQualifiedErrorId : Microsoft.Azure.Commands.DataLakeAnalytics.GetAzureDataLakeAnalyticsCatalogItem

Investigation as copied from email

The ADLS/ADLA commandlet calls AuthenticationFactory (https://github.com/Azure/azure-powershell-common/blob/75e99f8571291238893d16eed3b30ce17f1c4788/src/Authentication/Factories/AuthenticationFactory.cs#L275 ) to get the ServiceClientCredential.

Based on the targetendpoint which is “AzureEnvironment.Endpoint.AzureDataLakeStoreFileSystemEndpointSuffix” in case of ADLS or “AzureEnvironment.Endpoint.AzureDataLakeAnalyticsCatalogAndJobEndpointSuffix” in case of ADLA the token audience returned is of endpoint “AzureEnvironment.Endpoint.DataLakeEndpointResourceId” (https://github.com/Azure/azure-powershell-common/blob/75e99f8571291238893d16eed3b30ce17f1c4788/src/Authentication.Abstractions/Extensions/AzureEnvironmentExtensions.cs#L288 ).

Based on the screenshot Anders shared. Value of “DataLakeEndpointResourceId” is https://datalake.azure.net without the trailing slash.

Base on the settings of AzureCloud, this is set to “"https://datalake.azure.net"” in AzureEnvironment (https://github.com/Azure/azure-powershell-common/blob/75e99f8571291238893d16eed3b30ce17f1c4788/src/Authentication.Abstractions/AzureEnvironment.cs#L50 )

So whatever Anders is seeing should be expected. But the problem is not there. Because in my powershell session, when I login using serviceprincipal I see the resource sent it has a trailing “/” added but for MSI that is not the case.

Not sure but I think the reason is here:

For the serviceprincipal we get the resource as Uri which adds the trailing “/” to the resource (https://github.com/Azure/azure-powershell-common/blob/75e99f8571291238893d16eed3b30ce17f1c4788/src/Authentication/Factories/AuthenticationFactory.cs#L321 )

For MSI though we send the resource as a string here: https://github.com/Azure/azure-powershell-common/blob/75e99f8571291238893d16eed3b30ce17f1c4788/src/Authentication/Factories/AuthenticationFactory.cs#L337 thus no trailing “/” is added. Probable solution is to use Uri to get the normalized resource. Not sure why this was not hit before.

Also I think we should change wherever we are using the constant “http://datalake.azure.net” to “http://datalake.azure.net/” so that we do not hit this issue again. I think there are 3 places, AzureEnvironmentConstants.cs, AddAzureEnvironment.cs and SetAzureRmEnvironment.cs.

Also in SetAzureRMEnvironment.cs (

azure-powershell/src/ResourceManager/Profile/Commands.Profile/Environment/SetAzureRMEnvironment.cs

Line 333 in edd6562

newEnvironment.SetEndpoint(endpoint, MyInvocation.BoundParameters[key] as string);

) it would be better if we add trailing “/” at SetEndPointIfBound if the given endpoint does not have trailing “/”. This will prevent users passing wrong resourceid urls.

[markcowl]

Description

• Add trailing '/' to azure data lake resource id endpoints in built-in environments
• Verify that this resolves the issue in CloudShell

Cost: 1

[cormacpayne]

This has been fixed and will be available in the next release (2018-11-06)

[rahuldutta90]

@cormacpayne We are hitting this issue in Az module in the SPI path also (which I am not sure why). I think we need this fix for Az datalake module to work.

[rahuldutta90]

@cormacpayne I figured out why it started breaking.

Looks like this PR: https://github.com/Azure/azure-sdk-for-net/pull/4218/files changed the way to retrieve token audience from "settings.TokenAudience.ToString();" to "settings.TokenAudience.OriginalString;" (https://github.com/Azure/azure-sdk-for-net/blame/psSdkJson6/src/SdkCommon/Auth/Az.Auth/Az.Authentication/ApplicationTokenProvider.cs#L474 ). For the former code, it would add a trailing "/" to the url string but for the later code it wont.

Looks like for azureRm you were using "package id="Microsoft.Rest.ClientRuntime.Azure.Authentication" version="2.3.1" targetFramework="net452" ", but for Az you have updated it to 2.3.6 which contains this above change. I have added a mitigation in this issue: #8141
But let me know when you want to fix this.

[rahuldutta90]

@cormacpayne Any status regarding this fix?

[cormacpayne]

This should be fixed in the next release of Az (2019-01-29)