0

I am trying to remove the assigement for a particular object id.Below is the error I am getting. I am attaching my service principal access level in AD.

When I am trying to exectute the same command using devops pipline I am getting different errror.

To remove the access what is the permission is required to my service prinicpal in API permission section only read can work ? and why I am geeting the clould.execption errror. Any advice.

enter image description here

enter image description here

enter image description here

Kevin Lu-MSFT
  • 20,786
  • 3
  • 19
  • 28
anuj
  • 124
  • 2
  • 13

2 Answers2

2

I can reproduce your issue, the command Remove-AzRoleAssignment will call the Azure AD Graph to validate the $objectid you passed, so you need give the Application permission Directory.Read.All of Azure AD Graph(not Microsoft Graph,not Delegated permission).

enter image description here

After adding the permission, there is some delay(30m - 1h), then test the command, it works. (I test in local, the same in cloud shell)

enter image description here

Note: Except the permission in Azure AD, your service principal also need to have the permission in the subscription/specific resource scope, e.g. the servcie principal is the Owner/User Access Admin role in the Access control (IAM) of the subscription/specific resource scope(in your case, the storage account). If the service principal does not have the role, please add it as below.

enter image description here

In Azure Devops, you don't need to login with Connect-AzAccount(Actually in cloud shell, you also don’t need to login, but if you want to do so, it's also ok), it will login automatically with the service principal related to the service connection(Task version >= 4.*).

So please make sure the secret of your service principal is correct and the connection was verified. To run Remove-AzRoleAssignment, also add the permission above for the App Registration related to the service connection.

enter image description here

Then test it, it works.

enter image description here

Joy Wang
  • 39,905
  • 3
  • 30
  • 54
  • Hi Joy you are correct my service principle key is not verified. After Verification I am able to assign the roles but still Microsoft.Azure.cloud.execption error is coming from the devops pipeline.For now in devops pipeline I set the option is continue, so that after role assignment my next devOps pipeline task shouldn't stop. – anuj May 23 '20 at 07:21
  • If the api permission was granted, there may be some delay. I am sure it will work. – Joy Wang May 23 '20 at 07:56
  • Hi joy not still cloud.authenication error, I have raised a MS ticket on that issue. – anuj May 28 '20 at 07:08
0

Joy Wang is correct, but I would like to add that, you shouldn't give a service principal owner to the entire subscription if its not absolutely needed. its a security consideration. The better way would be to create a custom role in the subscription with only the permissions you need. in this case, some of the permissions you'll need to get it to work in the custom role are:

  "Microsoft.Management/managementGroups/read"
  "Microsoft.Authorization/roleAssignments/*"
  "Microsoft.Authorization/roleDefinitions/*"

Also, I tried to run get-azroleassignment without directory.read.all with a service principal, and it works as long as you have the role permissions assigned in the subscription. that leads me to believe the powershell get-add-remove-azroleassignment does not use the graph api permissions at all.

Update As joy stated, its possible that the custom role may be useless as it could technically give itself ownership, however, here is proof that you dont need api graph permissions for the service principal to do this:

enter image description here

enter image description here

Update2: proof that removing the subscription rule, and only having api permissions does not work, it can only get the role assignments for itself, (the service principal itself) nothing else. enter image description here

alphaz18
  • 2,610
  • 1
  • 5
  • 5
  • The first part is correct, actually, adding the owner is for the actions you mentioned. The second part is wrong, when you use `Get/Remove-AzRoleAssignment` with a service principal, it must need the permission in AzureAD, the API permission or directory role both ok. – Joy Wang May 21 '20 at 06:06
  • `I tried to run get-azroleassignment without directory.read.all with a service principal, and it works as long as you have the role permissions assigned in the subscription.` I suppose you test with a user account, not a service principal, the normal member user already has the permission to call this [AAD Graph](https://learn.microsoft.com/en-us/previous-versions/azure/ad/graph/api/functions-and-actions#getobjectsbyobjectids-get-objects-from-a-list-of-object-ids--), if you test with a serivice principal, you will get the error. – Joy Wang May 21 '20 at 06:06
  • BTW, actually the custom role in this case is meaningless, becasue if you assign the custom role with the `Microsoft.Authorization/roleAssignments/*` permission to the user, the user can also assign the other role e.g. `Owner` to himself. – Joy Wang May 21 '20 at 10:30
  • that's a valid good point about the assigning itself owner. But about your other comment though, no I did NOT test with a user account. its a service principal. I have screenshots to prove it. it does not need api permissions, updated my post. – alphaz18 May 21 '20 at 13:28
  • Your service principal may has a directory role, check it. – Joy Wang May 21 '20 at 13:36
  • it has a custom subscription role. with those permissions. that's the whole point. that's the permission it needs to use those specific powershell commands. not api permissions. because i tried with api permissions only without the subscription role assignment, it did not work. when i tried with custom role subscription but with no api permissions, it works. that's proof enough for me. there is also no mention in the documentation for those powershell commands that it needs any "api permissions". updated with proof – alphaz18 May 21 '20 at 13:47
  • Well, but I also test with a sp, it has the Owner role in the subscription, without the `api permission and directory role`, I reproduced the error. Anyway you can create a new sp to test again, I will keep my point. – Joy Wang May 21 '20 at 14:00