microsoft / microsoft/AzureStorageExplorer
Azure Stack: Sign-in broken for guest accounts, and discovery process "intractable"
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 452
- Forks
- 92
- Avg merge
- 15h 20m
- Merged PRs (30d)
- 3
Description
When adding a custom environment (Azure Stack) the storage explorer application assumes the login account used should be used with the home directory. This is not correct, and will result in the following error:
{
"message": "\"Unexpected token format: urn:ietf:wg:oauth:2.0:oob?error=access_denied&error_description=AADSTS65005%3a+Invalid+resource.+The+client+has+requested+access+to+a+resource+which+is+not+listed+in+the+requested+permissions+in+the+client%27s+application+registration.+Client+app+ID%3a+04b07795-8ddb-461a-bbee-02f9e1bf7b46.+Resource+value+from+request%3a+https%3a%2f%2fadminmanagement.msazurestack.onmicrosoft.com%2f9f4c9261-e5d2-4e83-bc6c-763f54de5046.+Resource+app+ID%3a+42547758-86d7-45f3-81f8-183181e67712.+List+of+valid+resources+from+app+registration%3a+.%0d%0aTrace+ID%3a+7428aebd-5a29-451c-aae4-611389842b00%0d%0aCorrelation+ID%3a+7ecb73fb-6508-4f0c-abad-d4987af5e641%0d%0aTimestamp%3a+2018-12-11+23%3a36%3a42Z\""
}
Above happens when you use an account which is only a guest in the "home" directory of an Azure Stack. The storage explorer code assumes they can use the common login endpoint and acquire a token for the target ARM application in that directory. This is a permission that has to be manually granted when a directory is onboarded to Azure Stack (we create permission grants for Azure PowerShell and Azure CLI applications to acquire a token against the specific ARM instance, and it looks like Storage Explorer is using the app ID for Azure CLI).
Additionally, the discovery process used is extremely inefficient and resulted in over 40K+ requests in the background, consuming 100% CPU and only terminating when the access tokens expired, which caused it to restart the process over again. When a custom environment is added, there should not be any enumeration of SPs in the authenticated directory, and instead only the ARM resource as advertised at the metadata endpoint should be used to acquire a token, and then subsequently call the /subscriptions API at that endpoint.
Below image shows how tokens are repeatedly acquired for resources in many different directories and tenant details are queried. This process essentially continues forever consuming maximum resources in the background. While this is occurring, the accounts tab has a spinning icon indicating to the user it is trying to load their subscriptions. To seems to have been developed with accounts that do not belong to many directories, and to directories without many Azure Stack instances registered to them.

Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.