I'm trying to assign permissions to an Azure Managed Service Identity for my Azure Logic App, but am running into errors.
I'm using the 2.0.1.16 version of the AzureAD powershell module.
What I have done is the following:
- Create a logic app
- Generate a Azure Managed Service Identity in the workflow settings of that logic app.
- Execute the PowerShell below to assign the group.readwrite.all role the the managed service identity.
It first throws an access denied error, and subsequent tries will throw a "InvalidRequest" Error. I'm a global administrator, and have full access to the resource group (it is a basic dev tenant where I have full permissions)
I have tried it on different tenants. Has anyone been able to get this to work?
PS C:\Users\markp> $msi = Get-AzureADServicePrincipal | ?{$_.DisplayName -ieq "test"}
PS C:\Users\markp> $mai
PS C:\Users\markp> $msi
ObjectId AppId DisplayName
-------- ----- -----------
8d87a1f9-fab0-45a9-a6f3-1e93b2d99b52 032c3c1c-2530-4eae-b390-153e3b0eb3c6 TEST
PS C:\Users\markp> $graph = Get-AzureADServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"
PS C:\Users\markp> $graph
ObjectId AppId DisplayName
-------- ----- -----------
5a634981-6bbe-4c81-9aef-185a71df56f7 00000003-0000-0000-c000-000000000000 Microsoft Graph
PS C:\Users\markp> $role = $graph.AppRoles | ?{$_.Value -imatch "group.read.all" }
PS C:\Users\markp> $role
AllowedMemberTypes : {Application}
Description : Allows the app to read group properties and memberships, and read the calendar and conversations f
or all groups, without a signed-in user.
DisplayName : Read all groups
Id : 5b567255-7703-4780-807c-7be8301ae99b
IsEnabled : True
Value : Group.Read.All
PS C:\Users\markp> New-AzureADServiceAppRoleAssignment -ObjectId $msi.ObjectId -PrincipalId $msi.ObjectId -Id $role.Id -ResourceId $graph.ObjectId
New-AzureADServiceAppRoleAssignment : Error occurred while executing NewServicePrincipalAppRoleAssignment
Code: Authorization_RequestDenied
Message: Insufficient privileges to complete the operation.
HttpStatusCode: Forbidden
HttpStatusDescription: Forbidden
HttpResponseStatus: Completed
At line:1 char:1
+ New-AzureADServiceAppRoleAssignment -ObjectId $msi.ObjectId -Principa ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [New-AzureADServiceAppRoleAssignment], ApiException
+ FullyQualifiedErrorId : Microsoft.Open.AzureAD16.Client.ApiException,Microsoft.Open.AzureAD16.PowerShell.NewServ
icePrincipalAppRoleAssignment
PS C:\Users\markp> New-AzureADServiceAppRoleAssignment -ObjectId $msi.ObjectId -PrincipalId $msi.ObjectId -Id $role.Id -ResourceId $graph.ObjectId
New-AzureADServiceAppRoleAssignment : Error occurred while executing NewServicePrincipalAppRoleAssignment
Code: Request_BadRequest
Message: One or more properties are invalid.
RequestId: 57ef7908-dd8b-4a21-b48e-f2692d324264
DateTimeStamp: Fri, 28 Sep 2018 14:36:55 GMT
HttpStatusCode: BadRequest
HttpStatusDescription: Bad Request
HttpResponseStatus: Completed
At line:1 char:1
+ New-AzureADServiceAppRoleAssignment -ObjectId $msi.ObjectId -Principa ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [New-AzureADServiceAppRoleAssignment], ApiException
+ FullyQualifiedErrorId : Microsoft.Open.AzureAD16.Client.ApiException,Microsoft.Open.AzureAD16.PowerShell.NewServ
icePrincipalAppRoleAssignment
Initial Setup
I setup a new logic app named "test" in my trial subscription just like you have explained above and enabled the MSI for it through workflow settings. Then I used the exact same PowerShell commands that you have above.
Explanation of two most important things that are happening
First Run - Even though you get error with Code: Authorization_RequestDenied, the operation of adding new role assignments has actually done it's work. New permissions have been added. (I'll give a little evidence on this in section below)
Subsequent Runs after the first run - You get an error with Code: Request_BadRequest, because the permissions/role assignments you're trying to add had already been added in the first run.
Evidence
PowerShell Scripts exactly from your post.
These queries worked for me only from Azure AD Graph Explorer (and NOT the new Microsoft Graph Explorer). Also, queries are case sensitive, so even a small difference will effect.
You can basically look at the role assignments for the Service Principal, before and after running your PowerShell script the first time to see that the required permissions actually get added (I created a new logic app with nothing in it and just MSI enabled to test this part)
Azure AD Graph Query:
Azure AD Graph Query: https://graph.windows.net/{tenant Id}/servicePrincipals/{MSI Service Principal ID}/appRoleAssignments
{MSI Service Principal ID} is 8d87a1f9-fab0-45a9-a6f3-1e93b2d99b52 in your case.
Role Assignments for the MSI Service Principal BEFORE the first run of New-AzureADServiceAppRoleAssignment using above query.
Role Assignments for the MSI Service Principal AFTER the first run of New-AzureADServiceAppRoleAssignment using above query.
Another SO Post which is related but slightly different
This SO post mentions almost the same PowerShell scripts that you are using. Interesting thing being it looks like scripts worked without error for many people as well. But notice the last comment by user Olandese
Currently the behavior hasn't been changed yet.
- First time bogus authentication error
- 2nd time Bad Request
However you can now also confirm the changes being applied through the new beta endpoint of MS Graph, after executing the Powershell commands.
navigate to https://developer.microsoft.com/en-us/graph/graph-explorer & authenticate with your user (should be indicated in the left sidebar)
You can then query the applied roles through: https://graph.microsoft.com/beta/servicePrincipals/{msi.ObjId}/appRoleAssignedTo
来源：https://stackoverflow.com/questions/52557766/assigning-microsoft-graph-permissions-to-azure-managed-service-identity