Get-AzureRmRoleAssignment | Access denied to the specified API version | when running as Service Principal

[danielstocker]

Cmdlet(s)

Get-AzureRmRoleAssignment

PowerShell Version 5.1.14393.693

Module Version

2.7.0 AzureRM.Profile
3.7.0 AzureRM.Resources

OS Version

10.0.14393.693

Description

When running as a Service Principal Get-AzureRmRoleAssignment yields a cloud exception.
This is due to a 401 coming from the graph API when Get-AzureRmRoleAssignment calls https://graph.windows.net//getObjectsByObjectIds?api-version=1.6-internal

Returned content:
{"odata.error":{"code":"Authentication_Unauthorized","message":{"lang":"en","value":"Access denied to the specified API version."}}}

This does not happen when doing the same call on api-version=1.6

Example run in the same context:

# Get an Oauth 2 access token based on client id, secret and tenant domain
$body = @{grant_type="client_credentials";resource=$resource;client_id=$ClientId;client_secret=$ClientSecret}
$oauth = Invoke-RestMethod -Method Post -Uri ("https://login.windows.net/" + $TenantDomain + "/oauth2/token?api-version=1.0") -Body $body

$assignmentObject = $assignment.object  
$body = @"
{
  "objectIds": [
    "$assignmentObject"
  ],
  "includeDirectoryObjectReferences": true
}
"@
 
$authHeader = @{"Authorization"= $oauth.access_token;"Content-Type"="application/json";"ContentLength"=$body.length }
$url = "https://graph.windows.net/" + $TenantDomain + "/getObjectsByObjectIds?api-version=1.6"
$content = Invoke-WebRequest -Headers $authHeader -Uri $url -Method Post -Body $body 

Debug Output

Example request body:

{
"objectIds": [
<object Id's populated by Get-AzureRmRoleAssignment>
],
"includeDirectoryObjectReferences": true
}

Repro Script

Add-AzureRmAccount -ServicePrincipal -Credential $creds -TenantId $TenantId
Get-AzureRMRoleAssignment

Workaround (partial)

In some circumstances Set-AzureRMRoleAssignment can be run which will return a 409 if the role is already set in a certain context. 409 can be caught to substitute some of the Get-* behaviour.

[markcowl]

Duplicate of #3407. Note that you can work around this be rewriting the api version in a DelegatingHandler, by providing the delegating Handler to the client factory like this:

Add-Type -Path .\MyDelegatingHandler.dll
$handler = New-Object -TypeName MyDelegatingHandler
[Microsoft.Azure.Commands.Common.Authentication.AzureSession]::ClientFactory.AddHandler($handler)

Here is a sample delegating handler that shows the method - the detection mechanism for requests that need to be rewritten could be more selective:

using System;
using System.Net.Http;
using System.Threading;
using System.Threading.Tasks;

namespace RewritingDelegatingHandler
{
    public class RewritingDelegatingHandler : DelegatingHandler, ICloneable
    {

        public object Clone()
        {
            return new RewritingDelegatingHandler();
        }

        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            if (request.RequestUri.Authority.Contains("graph"))
            {
                var requestBuilder = new UriBuilder(request.RequestUri);
                requestBuilder.Query = "api-version=1.6";
                request.RequestUri = requestBuilder.Uri;
            }
            return base.SendAsync(request, cancellationToken);
        }
    }
}

Note that, this is due for a permanent fix when the next graph api version is available, which is supposed to be in time for the next release.