Назначение разрешений Microsoft Graph для удостоверения управляемой службы Azure

Я пытаюсь назначить разрешения для удостоверения управляемой службы Azure для моего приложения логики Azure, но у меня возникают ошибки.

Я использую версию 2.0.1.16 модуля PowerShell для AzureAD.

Я сделал следующее:

  1. Создать приложение логики
  2. Создайте удостоверение управляемой службы Azure в параметрах рабочего процесса этого приложения логики.
  3. Запустите PowerShell ниже, чтобы назначить роль group.readwrite.all идентификатором управляемой службы.

Сначала выдается ошибка отказа в доступе, а последующие попытки вызывают ошибку «InvalidRequest». Я глобальный администратор и имею полный доступ к группе ресурсов (это базовый клиент разработчика, у меня есть полные разрешения)

Пробовал на разных арендаторах. Кто-нибудь смог заставить это работать?

    PS C:\Users\markp> $msi = Get-AzureADServicePrincipal | ?{$_.DisplayName -ieq "test"}
PS C:\Users\markp> $mai
PS C:\Users\markp> $msi

ObjectId                             AppId                                DisplayName
--------                             -----                                -----------
8d87a1f9-fab0-45a9-a6f3-1e93b2d99b52 032c3c1c-2530-4eae-b390-153e3b0eb3c6 TEST


PS C:\Users\markp> $graph = Get-AzureADServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"
PS C:\Users\markp> $graph

ObjectId                             AppId                                DisplayName
--------                             -----                                -----------
5a634981-6bbe-4c81-9aef-185a71df56f7 00000003-0000-0000-c000-000000000000 Microsoft Graph


PS C:\Users\markp> $role = $graph.AppRoles | ?{$_.Value -imatch "group.read.all" }
PS C:\Users\markp> $role


AllowedMemberTypes : {Application}
Description        : Allows the app to read group properties and memberships, and read the calendar and conversations f
                     or all groups, without a signed-in user.
DisplayName        : Read all groups
Id                 : 5b567255-7703-4780-807c-7be8301ae99b
IsEnabled          : True
Value              : Group.Read.All



PS C:\Users\markp> New-AzureADServiceAppRoleAssignment -ObjectId $msi.ObjectId -PrincipalId $msi.ObjectId -Id $role.Id -ResourceId $graph.ObjectId
New-AzureADServiceAppRoleAssignment : Error occurred while executing NewServicePrincipalAppRoleAssignment
Code: Authorization_RequestDenied
Message: Insufficient privileges to complete the operation.
HttpStatusCode: Forbidden
HttpStatusDescription: Forbidden
HttpResponseStatus: Completed
At line:1 char:1
+ New-AzureADServiceAppRoleAssignment -ObjectId $msi.ObjectId -Principa ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [New-AzureADServiceAppRoleAssignment], ApiException
    + FullyQualifiedErrorId : Microsoft.Open.AzureAD16.Client.ApiException,Microsoft.Open.AzureAD16.PowerShell.NewServ
   icePrincipalAppRoleAssignment

PS C:\Users\markp> New-AzureADServiceAppRoleAssignment -ObjectId $msi.ObjectId -PrincipalId $msi.ObjectId -Id $role.Id -ResourceId $graph.ObjectId
New-AzureADServiceAppRoleAssignment : Error occurred while executing NewServicePrincipalAppRoleAssignment
Code: Request_BadRequest
Message: One or more properties are invalid.
RequestId: 57ef7908-dd8b-4a21-b48e-f2692d324264
DateTimeStamp: Fri, 28 Sep 2018 14:36:55 GMT
HttpStatusCode: BadRequest
HttpStatusDescription: Bad Request
HttpResponseStatus: Completed
At line:1 char:1
+ New-AzureADServiceAppRoleAssignment -ObjectId $msi.ObjectId -Principa ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [New-AzureADServiceAppRoleAssignment], ApiException
    + FullyQualifiedErrorId : Microsoft.Open.AzureAD16.Client.ApiException,Microsoft.Open.AzureAD16.PowerShell.NewServ
   icePrincipalAppRoleAssignment

azure azure-active-directory azure-logic-apps
person Mark Priem    schedule 28.09.2018    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Начальная настройка

Я установил новое приложение логики под названием test в своей пробной подписке, как вы объяснили выше, и включил для него MSI в настройках рабочего процесса. Затем я использовал те же самые команды PowerShell, что и у вас выше.

Объяснение двух самых важных вещей, которые происходят

  1. Первый запуск - даже если вы получаете ошибку с кодом: Authorization_RequestDenied, операция добавления новых назначений ролей фактически выполнила свою работу. Добавлены новые разрешения. (Я дам небольшое свидетельство по этому поводу в разделе ниже)

  2. Последующие запуски после первого запуска - вы получаете сообщение об ошибке с кодом: Request_BadRequest, потому что назначения разрешений / ролей, которые вы пытаетесь добавить, уже были добавлены при первом запуске.

Свидетельство

  1. Скрипты PowerShell именно из вашего сообщения. введите описание изображения здесь

  2. Эти запросы работали для меня только из Azure AD Graph Explorer (а НЕ из нового Microsoft Graph Explorer). Кроме того, запросы чувствительны к регистру, поэтому даже небольшая разница будет иметь значение.

    Вы можете в основном посмотреть на назначения ролей для субъекта-службы до и после первого запуска сценария PowerShell, чтобы увидеть, что необходимые разрешения действительно добавлены (я создал новое приложение логики, в котором ничего не было, и только MSI включил для проверки этого часть)

Запрос графика Azure AD:

Azure AD Graph Query: https://graph.windows.net/{tenant Id}/servicePrincipals/{MSI Service Principal ID}/appRoleAssignments
    
{MSI Service Principal ID} is 8d87a1f9-fab0-45a9-a6f3-1e93b2d99b52 in your case.

Назначение ролей для субъекта-службы MSI ПЕРЕД первым запуском New-AzureADServiceAppRoleAssignment с использованием указанного выше запроса.

введите описание изображения здесь

Назначение ролей для субъекта-службы MSI ПОСЛЕ первого запуска New-AzureADServiceAppRoleAssignment с использованием указанного выше запроса.

введите описание изображения здесь

Еще одно сообщение SO, которое связано, но немного отличается

В этом сообщении SO упоминаются почти те же сценарии PowerShell, которые вы используете. Интересно то, что похоже, что скрипты у многих тоже работали без ошибок. Но обратите внимание на последний комментарий пользователя Olandese

введите описание изображения здесь

person Rohit Saigal    schedule 29.09.2018
comment
Спасибо, Рохит! Я использовал PowerShell для получения назначений ролей, и он оказался пустым, поэтому я не стал проверять дальше. Позвольте мне попробовать использовать Graph Explorer, чтобы проверить то же самое! Я вернусь к этому позже сегодня. - person Mark Priem; 29.09.2018
comment
Да ... он вернулся пустым и для меня, и в PowerShell, и даже через Portal, если вы посмотрите на разрешения для Enterprise App (там отображается специальная страница, не найденная). Я предполагаю, что все это из-за применения некоторой специальной логики для маскировки информации в случае Managed Service Identity. - person Rohit Saigal; 29.09.2018
comment
Круто. Я бы сказал, работа в процессе ????????. Я закончу приложение логики и посмотрю, что произойдет. - person Mark Priem; 29.09.2018

arrow_upward
0
arrow_downward

В настоящее время поведение не изменилось.

  • Ошибка первой фиктивной аутентификации
  • 2-й раз неверный запрос

Однако теперь вы также можете подтвердить изменения, применяемые через новую конечную точку бета-версии MS Graph, после выполнения команд Powershell.

перейдите к https://developer.microsoft.com/en-us/graph/graph-explorer и авторизуйтесь у своего пользователя (должно быть указано на левой боковой панели)

Затем вы можете запросить применяемые роли через: https://graph.microsoft.com/beta/servicePrincipals/ {msi.ObjId} / appRoleAssignedTo

person Joost VdC    schedule 08.11.2018