Разрешения MSI для Graph API

Мой вопрос: есть ли у нас какой-либо задокументированный метод предоставления разрешений на управление удостоверениями службы для Graph API, как это было бы с регистрацией приложения Azure на портале? Мне не удалось найти какие-либо параметры Powershell или возможность управлять разрешениями для субъекта-службы MSI на портале Azure или в документации. Я нашел аналогичный вопрос на форумах MSDN, но хотел убедиться, что не было никаких дальнейших обновлений или обходных путей, о которых кто-либо знал?

Сообщение форума MSDN: https://social.msdn.microsoft.com/Forums/azure/en-US/dae34534-f193-4444-b52e-ba9cfa4a1fda/does-azure-msi-support-accessing-graph-api?forum=WindowsAzureAD


azure-managed-identity azure-active-directory microsoft-graph-api
person floyd    schedule 28.12.2017    source источник
comment
Я голосую за закрытие этого вопроса, потому что это поиск рекомендаций по книгам, инструментам, программным библиотекам и многому другому, что не по теме.   -  person Trenton McKinney    schedule 13.11.2020

Ответы (2)


arrow_upward
14
arrow_downward

Заявление об ограничении ответственности - я не слишком хорошо знаком с MSI, но поскольку они моделируются как субъекты служб, это должно работать. Также я не могу проверить эти шаги.

Для выполнения этих действий необходимо использовать Azure AD PowerShell (v2)., чтобы назначить разрешения приложения для вашего MSI (для доступа к Microsoft Graph), и что вы являетесь администратором или администратором приложения в своем клиенте. Для Microsoft Graph задокументированные разрешения можно найти здесь. Те же инструкции можно использовать и для других ресурсов, защищенных Azure AD. Я предполагаю, что вы уже установили модуль PowerShell.

  1. Connect-AzureAD для подключения PS к Azure Ad. Введите свои права администратора.
  2. $graph = Get-AzureADServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'", чтобы найти принципала службы, представляющую Microsoft Graph, и присвоить его переменной. Субъект-служба для Microsoft Graph в настоящее время создается вовремя при первом доступе, поэтому существует вероятность, что он не существует. Его можно создать, вызвав New-AzureADServicePrincipal -AppId "00000003-0000-0000-c000-000000000000".
  3. $graph.AppRoles - это покажет вам все доступные разрешения приложений, которые вы можете выбрать, которые предоставляются Microsoft Graph. Например, если вашему MSI необходимо прочитать информацию о группе, найдите в списке разрешение «Group.Read.All» и запишите его идентификатор разрешения (это GUID). Например, вот одна из записей из списка AppRoles: AllowedMemberTypes : {Application} Description : Allows the app to read events of all calendars without a signed-in user. DisplayName : Read calendars in all mailboxes Id : 798ee544-9d2d-430c-a058-570e29e34338 IsEnabled : True Value : Calendars.Read
  4. Найдите свой объектный идентификатор MSI (при условии, что вы его не знаете, но знаете его clientId / appId): $msi = Get-AzureADServicePrincipal -Filter "AppId eq '{Your_MSI_appId}'"
  5. Для каждого разрешения, которое требуется вашему MSI, запустите следующий командлет PS, чтобы назначить разрешение вашему MSI: New-AzureADServiceAppRoleAssignment -Id {permissionId} -PrincipalId $msi.ObjectId -ResourceId $graph.ObjectId

И это должно сработать. Теперь у вас должна быть возможность получить токен доступа для MSI для вызова Microsoft Graph, а токен доступа должен содержать roles утверждение, которое соответствует разрешениям (идентификаторам), которые вы назначили выше. Затем вы можете использовать этот токен доступа для вызова Microsoft Graph. Это похоже на шаги 6 и 7 в https://docs.microsoft.com/en-us/azure/active-directory/msi-overview.

Надеюсь это поможет,

person Dan Kershaw - MSFT    schedule 28.12.2017
comment
Я выполнил шаги, описанные выше, и могу подтвердить, что это работает. Кроме того, что Powershell запрашивает параметр -ObjectId, он совпадает с основным идентификатором. New-AzureADServiceAppRoleAssignment -Id {permissionId} -PrincipalId $ msi.ObjectId -ObjectId $ msi.ObjectId -ResourceId $ graph.ObjectId. Вы можете получить AppId идентификатора управляемой службы, перейдя в Azure Active Directory - Корпоративные приложения - Все приложения. Обязательно установите для всех фильтров значение «Любые» / «Все приложения». - person Martijn; 01.01.2018
comment
Спасибо за подтверждение и дополнительную информацию. Вам не нужно указывать objectId для нового назначения - он должен быть сгенерирован для вас системой, но я думаю, что могу ошибаться. Однако, насколько мне известно, здесь objectId доступен только для чтения. - person Dan Kershaw - MSFT; 02.01.2018
comment
@ DanKershaw-MSFT, это поддерживается в Azure gov? Мне не удается заставить New-AzureADServiceAppRoleAssignment работать, несмотря на успехи в негосударственной сфере - person Josh; 08.08.2018
comment
Я делаю то, что говорит @ DanKershaw-MSFT, но получаю следующую ошибку (Я запускаю команды ppowershell как глобальный администратор): ›New-AzureADServiceAppRoleAssignment: при выполнении произошла ошибка› Authorization_RequestDenied Сообщение: недостаточно прав для ›завершения операции. ›› HttpStatusDescription: Запрещено ›HttpStatusCode: ForbiddenHttpResponseStatus: Но когда я проверял разрешения для принципала в корпоративном приложении, казалось, что они применяются! Не могли бы вы поделиться кодом, чтобы получить токен доступа для принципала? - person Olandese; 27.08.2018
comment
Спасибо @ DanKershaw-MSFT за это и отлично работает! Если вы столкнулись с проблемами, ознакомьтесь с моим запись в блоге для получения дополнительных сведений. - person Rahul P Nath; 09.10.2019

arrow_upward
0
arrow_downward

Ожидается сообщение RequestDenied. Было внесено изменение в то, что обновление системного MSI SP теперь заблокировано.

person Bac Hoang - MSFT    schedule 28.01.2019
comment
Не могли бы вы подробнее рассказать об этом? У вас есть ссылка на официальную документацию, в которой описывается причина, по которой обновление System MSI SP теперь заблокировано? - person Kacper Ryniec; 06.03.2019