具有对象标识的客户端无权在范围内执行操作"Microsoft.DataFactory/datafactories/datapipelines/read"

Question

我试图以编程方式从azure函数调用数据工厂管道.它抛出以下错误.

链接:http: //eatcodelive.com/2016/02/24/starting-an-azure-data-factory-pipeline-from-c-net/

AuthorizationFailed:对象ID为"XXX829e05'XXXX-XXXXX"的客户端"XXXX-XXXXX-XXXX"无权执行操作'Microsoft.DataFactory/datafactories/datapipelines/read'over scope'/ subscriptions/XXXXXX-4bf5-84c6 -3a352XXXXXX/resourcegroups/fffsrg /提供商/ Microsoft.DataFactory/datafactories/ADFTestFFFS/datapipelines/ADFTutorialPipelineCustom".

试图搜索类似的问题,但没有一个搜索结果给我解决我的问题,你能指导我们可能是什么问题吗？

目标是,每当文件被添加到blob时运行数据工厂管道.所以为了实现结果,我们尝试使用blob触发器从azure函数调用数据工厂管道.

在这方面的任何帮助非常感谢.

谢谢

Answer 1

步骤1：登录到Azure门户。
步骤2：在左侧菜单栏中找到“订阅”，然后单击。

步骤3：单击访问控制IAM，然后单击添加。

步骤4：在Add Permission（添加许可）窗口中，选择角色的贡献者。在“选择输入”框中，键入您在Azure AD中创建的应用名称（在Azure Active Directory中创建），然后选择它。就我而言，我创建了Azure资源管理。

第5步：获得成功的权限后，在订阅窗口中单击刷新，您将看到您的应用程序显示在列表中。请参见以下示例。

Answer 2

我们最近在同一消息中遇到了这个问题，发现这是由于用户使用不同的订阅登录造成的（我们有 2 个订阅）。使用 az login --subscription 为我们解决了这个问题。

Answer 3

对于遇到具有相同错误消息的类似问题的其他人 - 在“az login”之后，我在尝试以所有者身份创建资源组时收到相同的错误，我通过以下方法解决了此问题：

az account set --subscription "Azure Subscription 1"

基本上它源于未设置订阅，您可以在此处找到详细信息：https: //learn.microsoft.com/en-us/cli/azure/manage-azure-subscriptions-azure-cli#get-the-active -订阅

Answer 4

您收到的错误是您无权对管道范围执行操作'Microsoft.DataFactory/datafactories/datapipelines/read',因为您没有对datafactory的相关权限.

您需要具有"Contributor"/"DataFactoryContributor"权限才能创建和管理数据工厂资源或子资源.以下链接中有关azure RBAC角色的更多详细信息:

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

由于客户尝试从Azure Function中使用ADF客户端,因此建议使用AAD应用程序和服务主体来验证ADF客户端.您可以在此处找到有关创建AAD应用程序和服务主体的说明:

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

请按照有关如何创建Active Directory应用程序,服务主体,然后将其分配给以下链接中的Data Factory Contributor角色的说明以及将服务主体与ADF客户端一起使用的代码示例.

Answer 5

查看使用 Azure 资源组和 RBAC 时的常见问题 https://blogs.msdn.microsoft.com/azure4fun/2016/10/20/common-problem-when-using-azure-resource-groups-rbac/

此问题更可能发生在较新的订阅中，并且通常发生在之前从未在该订阅中创建过某种资源类型的情况下。

订阅管理员通常通过在订阅级别授予资源组所有者贡献者权限来解决此问题，这与他们将访问隔离到资源组级别而不是订阅级别的策略相矛盾。

根本原因

一些管理员说，某些资源需要访问订阅级别才能创建这些资源，而资源组级别的“所有者”权限是不够的。那不是真的。

让我们先退后一步，了解这一切是如何运作的。

要在 azure 中配置任何资源（使用资源管理器模型），您需要有一个支持创建该资源的资源提供程序。例如，如果您要预配虚拟机，则需要先在订阅中提供“Microsoft.Compute”资源提供程序，然后才能执行此操作。

资源提供者仅在订阅级别注册。

幸运的是，Azure 资源管理器 (ARM) 足够智能，可以为您解决这个问题。配置新的 Azure 资源时，如果该资源类型所需的资源提供程序尚未在订阅中注册，ARM 将尝试为您注册它。该操作（资源提供者注册）需要访问订阅级别。

默认情况下，任何新的 azure 订阅都将预先注册一个常用资源提供程序列表。例如，IoTHub 的资源提供者不是其中之一。

当用户仅被授予特定资源组的所有者权限时，如果该用户尝试提供需要注册资源提供程序的资源，则该操作将失败。这就是我们在上面的案例中尝试配置 IoThub 时发生的情况。

因此，底线是，我们不要需要授予访问权限的订阅级别的用户能够在自己的资源组中创建像HDInsight，IotHub和SQLDW ...等资源，他们对业主的权利，只要资源这些资源的提供者已经注册。