Назначьте роли корпоративного соглашения служебным субъектам.

Вы можете управлять записью вашего Корпоративного соглашения (EA) в портале Azure. Вы можете создавать различные роли для управления организацией, просматривать затраты и создавать подписки. В этой статье показано, как автоматизировать некоторые из этих задач с помощью Azure PowerShell и REST API с принципалами службы Microsoft Entra ID.

Прежде чем приступать к работе, убедитесь, что вы ознакомлены со следующими статьями.

• Роли для Корпоративного соглашения
• Sign in with Azure PowerShell (Вход в Azure PowerShell)

Вам нужен способ вызова REST API. Ниже приведены некоторые популярные способы запроса API:

• Visual Studio
• Бессонница
• Бруно
• PowerShell `Invoke-RestMethod`
• Курл

Создайте и аутентифицируйте вашего служебного пользователя

Чтобы автоматизировать действия EA с помощью учетной записи службы, необходимо создать удостоверение приложения Microsoft Entra, которое затем может автоматически аутентифицироваться.

Следуйте действиям, описанным в этих статьях, чтобы создать и аутентифицироваться с использованием сервисного принципала.

• Создать сервисный принципал
• Получите значения идентификатора клиента и приложения для входа

Ниже приведен пример страницы регистрации приложения.

Найдите идентификаторы основной службы и арендатора

Вам нужны идентификатор объекта служебного принципала и идентификатор арендатора. Эти сведения понадобятся для операций назначения разрешений далее в этой статье. Все приложения регистрируются в Microsoft Entra ID у арендатора. При завершении регистрации приложения создаются два типа объектов:

• Объект приложения — идентификатор приложения — это то, что отображается в разделе "Корпоративные приложения". Не используйте ID для предоставления ролей EA.
• Объект главного служб - Объект главного служб — это то, что вы видите в окне регистрации предприятия в Microsoft Entra ID. Идентификатор объекта используется для предоставления ролей EA служебному принципалу.

1. Откройте идентификатор Microsoft Entra и выберите корпоративные приложения.

2. Найдите приложение в списке.

   

3. Выберите приложение, чтобы узнать его идентификатор и идентификатор объекта.

   

4. Перейдите на страницу Обзор Microsoft Entra ID, чтобы найти идентификатор клиента.

   

Разрешения, которые могут быть назначены служебному участнику

В дальнейшем в этой статье вы предоставите приложению Microsoft Entra разрешение на выполнение действий с помощью роли EA. Вы можете назначить служебному принципалу только следующие роли, и вам нужен идентификатор определения роли, точно как показано.

Для назначения каждой роли служебного принципала требуются следующие роли пользователей.

• EnrollmentReader: пользователь, которому назначена роль, должен иметь роль автора регистрации.
• DepartmentReader: назначение пользователя должен иметь роль автора регистрации или автора отдела.
• SubscriptionCreator: пользователь, назначающий подписку, должен быть владельцем учетной записи для регистрации (администратором EA).
• Покупатель EA: пользователь, проводящий назначение, должен иметь роль регистрирующего записывающего.
• Читатель роли администратора партнеров: пользователь, назначающий, должен иметь роль администратора партнера.

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

При предоставлении роли EA сервисному принципалу необходимо использовать обязательное свойство billingRoleAssignmentName. Этот параметр является уникальным идентификатором GUID, который вы должны предоставить. Вы можете создать глобально уникальный идентификатор (GUID) с помощью команды PowerShell New-Guid. Можно также использовать веб-сайт генератора GUID/UUID для создания уникального идентификатора GUID.

Служебный принципал может иметь только одну роль.

Назначение роли субъекту-службе

Выполните следующие действия, чтобы назначить любую из поддерживаемых ролей служебному принципалу.

1. Используйте соответствующие назначения ролей, поместите REST API и нажмите кнопку "Попробовать". Найдите правильный API для использования в таблице ниже.

2. Войдите в арендатора с необходимым доступом.

3. Укажите следующие параметры в запросе API:

   • billingAccountName: идентификатор счета. Для роли читателя администратора партнера используйте формат pcn.{PCN} (где {PCN} находится номер клиента партнера). Для всех остальных ролей используйте стандартный идентификатор учетной записи выставления счетов на портале Azure.

   

   • billingRoleAssignmentName: уникальный GUID, который вы создаете (см. New-Guid).
   • api-version: используется 2019-10-01-preview , если не указано иное.
   • Параметры текста запроса:
     • properties.principalId: идентификатор объекта субъекта-службы.
     • properties.principalTenantId: идентификатор клиента.
     • properties.roleDefinitionId: используйте значение из приведенной ниже таблицы.

1. Выберите "Выполнить" , чтобы выполнить команду.

5. 200 OK Ответ означает, что субъект-служба успешно назначена роли.

Проверка назначений ролей сервисного принципала

Назначения ролей служебной учетной записи не отображаются в портале Azure. Вы можете просмотреть назначения ролей учетной записи на регистрацию, включая роль создателя подписки, с использованием API назначения ролей в выставлении счетов — список по учетной записи на регистрацию — REST API (выставление счетов Azure). Используйте API, чтобы убедиться, что назначение роли выполнено успешно.

Устранение неполадок

Вы должны определить и использовать ID объекта приложения Enterprise, где вы предоставили роль EA. Если вы используете идентификатор объекта из другого приложения, вызовы API завершаются сбоем. Убедитесь, что вы используете правильный идентификатор объекта приложения Enterprise.

Если при вызове API возникает следующая ошибка, возможно, вы неправильно используете значение идентификатора объекта субъекта-службы, расположенного в регистрациях приложений. Чтобы устранить эту ошибку, убедитесь, что вы используете идентификатор учетной записи службы из "Enterprise Applications", а не в разделе "Регистрация приложений".

The provided principal Tenant Id = xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx and principal Object Id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx are not valid

Следующие шаги

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