Клиент с идентификатором объекта не имеет разрешения на выполнение действия "Microsoft.DataFactory/datafactories/datapipelines/read" по области

Ответ 1

Вы получаете сообщение об ошибке, что у вас нет прав на выполнение действия "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

Поскольку клиент пытается использовать клиент ADF изнутри функции Azure, рекомендуется использовать приложение AAD и субъект-службу для аутентификации клиента ADF. Инструкции по созданию приложения AAD и принципала службы вы можете найти здесь:

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

Пожалуйста, следуйте инструкциям по созданию приложения Active Directory, участника службы, а затем назначьте его роли "Участник фабрики данных" в следующей ссылке и в примере кода для использования участника службы с клиентом ADF.

Ответ 2

Шаг 1: войдите в свой лазурный портал
Шаг 2: найдите Подписки в левой части меню и нажмите.

Шаг 3: Нажмите Access Control IAM, а затем нажмите Add.

Шаг 4. В окне "Добавить разрешение" выберите участника для роли. В поле ввода введите имя приложения, созданного в Azure AD (созданный в Azure Active Directory), и выберите его. В моем случае я создал Azure Resource Management.

Шаг 5. После того, как вы дали успешное разрешение, нажмите "Обновить" в окне подписки, и вы увидите свое приложение в списке. Смотрите ниже пример.

Ответ 3

У нас недавно была эта проблема с тем же сообщением, и мы обнаружили, что это вызвано тем, что пользователь вошел в систему с другой подпиской (у нас есть 2). Использование az login --subscription решило проблему для нас.

Ответ 4

СМ. Общая проблема при использовании групп ресурсов 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… и т.д., В своих группах ресурсов, на которые у них есть права владельца, при условии, что ресурс Провайдеры для этих ресурсов уже зарегистрированы.

Ответ 5

Решение:

• Шаг 1. Зарегистрируйте приложение в каталоге Azure Active.
  
• Шаг 2: Назначьте 'Data Factory роль Contributor в том же приложении. мы можем достичь этого, используя силовую оболочку.
  

Следующий код работает для меня. Пожалуйста, попробуйте в силовой оболочке после входа в систему с учетными данными Azure.
Реализация:

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

Ответ 6

Следуйте этому посту: https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal

В этом посте Роль указана как "Читатель", которая должна быть "Владельцем", иначе она выдаст ошибку разрешения при развертывании.

Ответ 7

Я решил, следуя этому сообщению: https://www.nwcadence.com/blog/resolving-authorizationfailed-2016 с помощью команды в PowerShell:

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