1

I have a service principal I've setup for my DevOps pipeline which I use to create service principals/apps for use by services I'm deploying via Azure CLI as follows:

az ad sp create-for-rbac --name TestAccount1 --skip-assignment

If I assign the following permissions to my DevOps service principal it works perfectly:

enter image description here

However that obviously triggers the deprecation alert but if I change the permissions to:

enter image description here

I get the following:

Directory permission is needed for the current user to register the application. For how to configure, please refer 'https://learn.microsoft.com/azure/azure-resource-manager/resource-group-create-service-principal-portal'. Original error: Insufficient privileges to complete the operation.

Am I missing a subtlety when it comes to Azure AD Graph vs Microsoft Graph aren't they just old and new APIs into the same Azure AD Tenant?

Nishant
  • 623
  • 4
  • 10
Simon
  • 1,613
  • 1
  • 12
  • 27

1 Answers1

1

Obviously this cmd az ad sp create-for-rbac is calling Azure AD Graph API in the background.

The endpoints of AAD Graph and Microsoft Graph are different.

AAD Graph endpoint: https://graph.windows.net/

Microsoft Graph endpoint: https://graph.microsoft.com/

And when you assign the Application.ReadWrite.All permission on Azure portal, you will find that this permission is actually under its corresponding endpoint.

enter image description here

enter image description here

So if you add Application.ReadWrite.All permission under Microsoft Graph, it won't allow you to call Azure AD Graph.

Allen Wu
  • 15,529
  • 1
  • 9
  • 20
  • Aren't those just end points to the same AD instance though, am I not effectively saying I want service principal X to have permissions Y and I can either use the new or old APIs to assign said permission. To be honest it definitely wasn't obvious to me that the AZ CLI commands referenced a deprecated API. Begs the question at what point will "az ad" migrate to using the new API and will things start to fail unless one also assigns the same permissions with the new API. – Simon Oct 06 '20 at 09:55
  • @Simon Sorry for that I didn't make it clear. I think it's obvious because only the AAD graph permission takes effect. Azure cli is using AAD Graph in the backend. Although AAD Graph is now deprecated, Microsoft continues to provide technical support and security updates. I'm not sure if Azure cli will use MS graph in the future, but Microsoft will ensure that you will not be affected during use. See the **Important** tip here: https://learn.microsoft.com/en-us/graph/migrate-azure-ad-graph-planning-checklist. I think the migration should be finished before June 30th, 2022. – Allen Wu Oct 07 '20 at 00:59
  • @Simon Anything else is unclear? If my answer is helpful, you can mark it as accepted. Thank you. – Allen Wu Oct 08 '20 at 09:13
  • Sorry haven't had a chance to get back to this, thanks for the prompt. I agree it's implicitly obvious because it works, would be good if MS was more explicit though! Am I right in that the permissions are effectively permissions to "do X in AD using a specific API" rather than simply permissions to "do X in AD" and that the permissions are tied to the API as well as the resource the permissions are against? – Simon Oct 08 '20 at 13:08
  • @Simon Yes. You are right. Use different APIs to do operations to the same AD. – Allen Wu Oct 09 '20 at 01:29