The client with object id does not have authorization to perform action 'Microsoft.DataFactory/datafactories/datapipelines/read' over scope

Question

I was trying to invoke data factory pipeline from azure function programmatically. Its throwing following error.

link: http://eatcodelive.com/2016/02/24

Answer 1

Solution:

1. Step 1: Register an app in Azure Active directory.
   
2. Step 2: Assign 'Data Factory Contributor' role to the same app. we can achieve this by using power shell.
   

The below code works for me. Please try out in power shell after logged in with Azure credential.
Implementation:

1. Step 1: $azureAdApplication = New-AzureRmADApplication -DisplayName <AppName> -HomePage <URL> -IdentifierUris <URL with domain> -Password <Password>
2. Step 2: New-AzureRmRoleAssignment -RoleDefinitionName "Data Factory Contributor" -ServicePrincipalName $azureAdApplication.ApplicationId

Answer 2

Follow this post : https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal

In this post , Role is given as "Reader" which should be "Owner" instead otherwise it would give permission error on deployment.

Answer 3

I solved by following this post: https://www.nwcadence.com/blog/resolving-authorizationfailed-2016 with the command in PowerShell:

Get-AzureRmResourceProvider -ListAvailable | Select-Object ProviderNamespace | Foreach-Object { Register-AzureRmResourceProvider -ProviderName $_.ProviderNamespace}

Answer 4

I solved by finding the Enterprise Application > Object ID. (it is weird that it does not use App Reg > Application Id)

https://jeanpaul.cloud/2020/02/03/azure-data-factory-pipeline-execution-error/

Answer 5

You get the error that you are not authorized to perform action 'Microsoft.DataFactory/datafactories/datapipelines/read' over scope of pipeline because you don't have the relevant permissions on the datafactory.

You either need to have "Contributor" /"DataFactoryContributor" permissions to create & manage data factory resources or child resources. More details of the azure RBAC roles in the following link:

https://docs.microsoft.com/en-us/azure/active-directory/role-based-access-built-in-roles

Since the customer is trying to use the ADF client from inside Azure Function, the recommendation is to use AAD application and service principal for authentication of ADF client. You can find the instructions for creating AAD application and service principal here:

https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-authenticate-service-principal

Please follow the instructions on how to create the Active Directory application, service principal, and then assign it to the Data Factory Contributor role in the following link and the code sample for using service principal with ADF client.

Answer 6

SEE Common problem when using Azure resource groups & RBAC https://blogs.msdn.microsoft.com/azure4fun/2016/10/20/common-problem-when-using-azure-resource-groups-rbac/

This issue is more likely to happen in newer subscriptions and usually happens if a certain resource type has never been created before in that subscription.

Subscription admins often fix this issue by granting resource group owners contributor rights on the subscription level which contradicts with their strategy of isolating access down to the level of resource group level not the subscription level.

Root cause

Some admins say, that some resources require access to the subscription level to be able to create these resources and that ‘owner’ rights on a resource group level is not sufficient. That is not true.

Let’s take a step back to understand how this all works first.

To provision any resources in azure (using the resource manager model) you need to have a resource provider that supports the creation of that resource. For example, if you will provision a virtual machine, you need to have a ‘Microsoft.Compute’ resource provider available in the subscription first before you can do that.

Resource providers are registered on the level of the subscription only.

Luckily, the Azure Resource Manager (ARM) is intelligent enough to figure that out for you. When a new Azure resource gets provisioned, if the resource provider required for that resource type is not registered in the subscription yet, ARM will attempt to register it for you. That action (resource provider registration) requires access to the subscription level.

By default, any new azure subscription will be pre-registered with a list of commonly used resource providers. The resource provider for IoTHub for instance, is not one of them.

When a user is granted owner rights only on a specific resource group, if that user tries to provision a resource that requires registering a resource provider for the first time, that operation will fail. That is what happened in our case above when trying to provision IoThub.

So the bottom line is, we DO NOT need to grant access permissions to the subscription level for users to be able to create resources like HDInsight, IotHub and SQLDW …etc within their resource groups that they have owner rights on, as long as the resource providers for these resources is already registered.