Le client avec l'ID d'objet n'a pas l'autorisation d'effectuer l'action "Microsoft.DataFactory/datafactories/datapipelines/read" sur l'étendue
J'essayais d'appeler par programmation le pipeline de la fabrique de données à partir de la fonction Azure. Son erreur de lancer suivante.
lien: http://eatcodelive.com/2016/02/24/starting-an-Azure-data-factory-pipeline-from-c-net/
AuthorizationFailed: le client 'XXXX-XXXXX-XXXX' avec l'ID d'objet 'XXX829e05'XXXX-XXXXX' n'a pas l'autorisation d'effectuer l'action 'Microsoft.DataFactory/datafactories/datapipelines/read' sur la portée '/subscriptions/XXXXXX-4bf5-84c6-3a352XXXXXX/resourcegroups/fffsrg/providers/Microsoft.DataFactory/datafactories/ADFTestFFFS/datapipelines/ADFTutorialPipelineCustom'.
essayé de rechercher des problèmes similaires, mais aucun des résultats de la recherche ne m’a apporté de solution à mon problème, pouvez-vous nous indiquer quel pourrait être le problème?
L’objectif est d’exécuter le pipeline de la fabrique de données chaque fois que le fichier est ajouté au blob. Pour obtenir le résultat souhaité, nous essayons d'appeler le pipeline de la fabrique de données à partir de la fonction Azure à l'aide du déclencheur blob.
Toute aide à cet égard est très appréciée.
Merci
Vous obtenez le message d'erreur indiquant que vous n'êtes pas autorisé à exécuter l'action "Microsoft.DataFactory/datafactories/datapipelines/read" sur l'étendue du pipeline, car vous ne disposez pas des autorisations appropriées sur le datafactory.
Vous devez disposer des autorisations "Collaborateur"/"DataFactoryContributor" pour créer et gérer les ressources de la fabrique de données ou les ressources enfants. Plus de détails sur les rôles Azure RBAC dans le lien suivant:
https://docs.Microsoft.com/en-us/Azure/active-directory/role-based-access-built-in-roles
Étant donné que le client tente d'utiliser le client ADF depuis Azure Function, il est recommandé d'utiliser l'application et le principal de service AAD pour l'authentification du client ADF. Vous pouvez trouver les instructions pour créer l'application AAD et le principal de service ici:
Suivez les instructions relatives à la création de l’application Active Directory, principal de service, puis affectez-la au rôle Data Factory Contributor dans le lien suivant et à l’exemple de code permettant d’utiliser le principal de service avec le client ADF.
Nous avons récemment eu ce problème avec le même message et nous avons constaté qu'il était dû à la connexion de l'utilisateur avec un autre abonnement (nous en avons 2). Utiliser az login --subscription a résolu le problème pour nous.
J'ai résolu en suivant cet article: https://www.nwcadence.com/blog/resolving-authorizationfailed-2016
Get-AzureRmResourceProvider -ListAvailable | Select-Object ProviderNamespace | Foreach-Object { Register-AzureRmResourceProvider -ProviderName $_.ProviderNamespace}
Étape 1: connectez-vous à votre portail Azure
Étape 2: recherchez les abonnements dans la barre de menu de gauche et cliquez sur.
étape 3: Cliquez sur Access Control IAM puis sur Add. 
Étape 4: Dans la fenêtre Ajouter une autorisation, sélectionnez un contributeur pour le rôle. Dans la zone de saisie sélectionnée, tapez le nom de l'application que vous avez créée dans Azure AD (créé dans Azure Active Directory) et sélectionnez-le. Dans mon cas, j'ai créé Azure Resource Management. 
Étape 5: Après avoir accordé votre autorisation, cliquez sur Actualiser dans la fenêtre de votre abonnement pour afficher votre application dans la liste. Voir ci-dessous exemple . 
VOIR Problème courant lors de l'utilisation de groupes de ressources Azure et de RBAC https://blogs.msdn.Microsoft.com/Azure4fun/2016/10/20/common-problem-when-usen-Azure-resource-groups-rbac/
Ce problème est plus susceptible de se produire dans les nouveaux abonnements et se produit généralement si un certain type de ressource n'a jamais été créé auparavant dans cet abonnement.
Les administrateurs d'abonnement résolvent souvent ce problème en accordant des droits de contributeur aux propriétaires de groupes de ressources au niveau de l'abonnement, ce qui contredit leur stratégie consistant à isoler l'accès au niveau du groupe de ressources et non au niveau de l'abonnement.
Cause première
Certains administrateurs disent que certaines ressources nécessitent un accès au niveau de la souscription pour pouvoir créer ces ressources et que les droits de «propriétaire» au niveau du groupe de ressources ne sont pas suffisants. Ce n'est pas vrai.
Prenons un peu de recul pour comprendre comment cela fonctionne en premier.
Pour provisionner des ressources dans Azure (à l'aide du modèle de gestionnaire de ressources), vous devez disposer d'un fournisseur de ressources prenant en charge la création de cette ressource. Par exemple, si vous souhaitez provisionner une machine virtuelle, vous devez d’abord disposer d’un fournisseur de ressources ‘Microsoft.Compute’ dans l’abonnement avant de pouvoir le faire.
Les fournisseurs de ressources sont enregistrés au niveau de l'abonnement uniquement.
Heureusement, Azure Resource Manager (ARM) est suffisamment intelligent pour comprendre cela pour vous. Lorsqu'une nouvelle ressource Azure est provisionnée, si le fournisseur de ressources requis pour ce type de ressource n'est pas encore inscrit dans l'abonnement, ARM tentera de l'enregistrer pour vous. Cette action (enregistrement du fournisseur de ressources) nécessite un accès au niveau abonnement.
Par défaut, tout nouvel abonnement Azure sera préenregistré avec une liste des fournisseurs de ressources couramment utilisés. Le fournisseur de ressources pour IoTHub, par exemple, n'en fait pas partie.
Lorsqu'un utilisateur se voit attribuer des droits de propriétaire uniquement sur un groupe de ressources spécifique, si cet utilisateur tente de provisionner une ressource nécessitant l'inscription d'un fournisseur de ressources pour la première fois, cette opération échoue. C'est ce qui s'est passé dans notre cas ci-dessus lorsque nous avons essayé de fournir IoThub.
En résumé, nous devons NE PAS accorder des autorisations d'accès au niveau abonnement pour permettre aux utilisateurs de créer des ressources telles que HDInsight, IotHub et SQLDW… etc au sein de leurs groupes de ressources sur lesquels ils disposent de droits de propriétaire, comme tant que les fournisseurs de ressources pour ces ressources sont déjà enregistrés.
Suivez ce message: https://docs.Microsoft.com/en-us/Azure/azure-resource-manager/resource-group-create-service-principal-portal
Dans ce post, le rôle est donné en tant que "Lecteur" qui devrait être "Propriétaire" sinon il donnerait une erreur d'autorisation lors du déploiement.
Solution:
- Étape 1: enregistrez une application dans Azure Active Directory.
- Étape 2: Attribuez le rôle 'Data Factory Contributor' à la même application. nous pouvons y parvenir en utilisant Power Shell.
Le code ci-dessous fonctionne pour moi. Essayez d’essayer dans Power Shell après vous être connecté avec les informations d’identité Azure.
La mise en oeuvre:
- Étape 1:
$azureAdApplication = New-AzureRmADApplication -DisplayName <AppName> -HomePage <URL> -IdentifierUris <URL with domain> -Password <Password> - Étape 2:
New-AzureRmRoleAssignment -RoleDefinitionName "Data Factory Contributor" -ServicePrincipalName $azureAdApplication.ApplicationId