Назначение ролей Соглашение Enterprise субъектам-службам

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

Примечание.

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

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

Создание и проверка подлинности субъекта-службы

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

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

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

Снимок экрана, показывающий регистрацию приложения.

Поиск идентификаторов субъекта-службы и клиента

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

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

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

    Снимок экрана, показывающий пример корпоративного приложения.

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

    Снимок экрана, показывающий идентификатор приложения и идентификатор объекта для корпоративного приложения.

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

    Снимок экрана с идентификатором клиента.

Примечание.

Значение идентификатора клиента Microsoft Entra выглядит как GUID со следующим форматом: 11111111-1111-1111-1111-111111111111

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

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

Роль Разрешенные действия Идентификатор определения роли
EnrollmentReader Средства чтения регистрации могут просматривать данные в область регистрации, отдела и учетной записи. Данные содержат плату за все подписки в область, в том числе в разных клиентах. Может просматривать предоплату Azure (ранее называемую денежным обязательством), связанную с регистрацией. 24f8edb6-1668-4659-b5e2-40bb5f3a7d7e
Покупатель EA Приобретение резервирований и просмотр транзакций резервирования. Имеет все разрешения роли EnrollmentReader, которая, в свою очередь, имеет все разрешения DepartmentReader. Может просматривать сведения об использовании и платежах во всех учетных записях и подписках. Может просматривать предоплату Azure (ранее называемую денежным обязательством), связанную с регистрацией. da6647fb-7651-49ee-be91-c43c4877f0c4
DepartmentReader Загрузите сведения об использовании для отдела, который они администрируют. Может просматривать сведения об использовании и расходах, связанных с их отделом. db609904-a47f-4794-9be8-9bd86fbffd8a
SubscriptionCreator Создание новых подписок в заданной области учетной записи. a0bcee42-bf30-4d1b-926a-48d21664ef71
  • Роль EnrollmentReader может быть назначена субъекту-службе только пользователем, у которого есть роль записи регистрации. Роль EnrollmentReader, назначенная субъекту-службе, не отображается в портал Azure. Она создается программным способом и предназначена только для программного использования.
  • Роль DepartmentReader может быть назначена субъекту-службе только пользователем, у которого есть роль средства записи регистрации или средства записи отделов.
  • Роль SubscriptionCreator может быть назначена субъекту-службе только пользователем, который является владельцем учетной записи регистрации (администратор EA). Роль не отображается в портал Azure. Она создается программным способом и предназначена только для программного использования.
  • Роль покупателя EA не отображается в портал Azure. Она создается программным способом и предназначена только для программного использования.

При предоставлении роли EA субъекту-службе необходимо использовать необходимое billingRoleAssignmentName свойство. Этот параметр является уникальным ИДЕНТИФИКАТОРом GUID, который необходимо указать. Глобально уникальный идентификатор можно создать с помощью команды PowerShell New-Guid. Можно также использовать веб-сайт генератора GUID/UUID для создания уникального идентификатора GUID.

Субъект-служба может иметь только одну роль.

Назначение разрешения роли учетной записи регистрации субъекту-службе

  1. См. статью REST API Назначение ролей – Put. Когда вы читаете статью, выберите "Попробовать начать работу с помощью субъекта-службы".

    Снимок экрана, показывающий пункт

  2. Используйте данные вашей учетной записи для входа в клиент с уровнем доступа для регистрации, который вы хотите назначить.

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

    • billingAccountName: этот параметр представляет идентификатор учетной записи выставления счетов. Его можно найти на портале Azure на странице Управление затратами и выставление счетов.

      Снимок экрана: идентификатор учетной записи выставления счетов.

    • billingRoleAssignmentName: этот параметр представляет уникальный идентификатор GUID, который необходимо указать. Глобально уникальный идентификатор можно создать с помощью команды PowerShell New-Guid. Можно также использовать веб-сайт генератора GUID/UUID для создания уникального идентификатора GUID.

    • api-version: используйте версию 2019-10-01-preview. Используйте образец текста запроса в статье Назначение ролей — Put — Примеры.

      Текст запроса содержит код JSON с тремя параметрами, которые необходимо использовать.

      Параметр Где ее найти
      properties.principalId Это значение идентификатора объекта. Ознакомьтесь с идентификаторами субъекта-службы и клиента.
      properties.principalTenantId Ознакомьтесь с идентификаторами субъекта-службы и клиента.
      properties.roleDefinitionId /providers/Microsoft.Billing/billingAccounts/{BillingAccountName}/billingRoleDefinitions/24f8edb6-1668-4659-b5e2-40bb5f3a7d7e

      Имя учетной записи выставления счетов — это тот же параметр, который использовался в параметрах API. Это идентификатор регистрации, который отображается в портал Azure.

      Обратите внимание, что 24f8edb6-1668-4659-b5e2-40bb5f3a7d7e является идентификатором определения роли выставления счетов для EnrollmentReader.

  4. Щелкните Выполнить, чтобы выполнить приложение.

    Снимок экрана: пример назначения ролей с примерами сведений, готовых к выполнению.

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

Теперь вы можете использовать субъект-службу для автоматического доступа к API EA. Субъект-служба имеет роль EnrollmentReader.

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

Для роли покупателя EA необходимо выполнить те же действия, что и для модуля чтения регистрации. Укажите roleDefinitionId, как в следующем примере:

"/providers/Microsoft.Billing/billingAccounts/1111111/billingRoleDefinitions/ da6647fb-7651-49ee-be91-c43c4877f0c4"

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

  1. Ознакомьтесь со статьей о REST API Назначение ролей в отделе регистрации — Put. Во время чтения статьи выберите Попробовать.

    Снимок экрана, показывающий пункт

  2. Используйте данные вашей учетной записи для входа в клиент с уровнем доступа для регистрации, который вы хотите назначить.

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

    • billingAccountName: этот параметр представляет идентификатор учетной записи выставления счетов. Его можно найти на портале Azure на странице Управление затратами и выставление счетов.

      Снимок экрана: идентификатор учетной записи выставления счетов.

    • billingRoleAssignmentName: этот параметр представляет уникальный идентификатор GUID, который необходимо указать. Глобально уникальный идентификатор можно создать с помощью команды PowerShell New-Guid. Можно также использовать веб-сайт генератора GUID/UUID для создания уникального идентификатора GUID.

    • departmentName: этот параметр представляет идентификатор отдела. Идентификаторы отделов можно просмотреть на портале Azure на странице Управление затратами + выставление счетов>Отделы.

      В этом примере использован отдел ACE. Идентификатором в этом примере является 84819.

      Снимок экрана, на котором показан пример идентификатора отдела.

    • api-version: используйте версию 2019-10-01-preview. Используйте образец из статьи Назначение ролей в отделе регистрации — Put.

      Текст запроса содержит код JSON с тремя параметрами, которые необходимо использовать.

      Параметр Где ее найти
      properties.principalId Это значение идентификатора объекта. Ознакомьтесь с идентификаторами субъекта-службы и клиента.
      properties.principalTenantId Ознакомьтесь с идентификаторами субъекта-службы и клиента.
      properties.roleDefinitionId /providers/Microsoft.Billing/billingAccounts/{BillingAccountName}/billingRoleDefinitions/db609904-a47f-4794-9be8-9bd86fbffd8a

      Имя учетной записи выставления счетов — это тот же параметр, который использовался в параметрах API. Это идентификатор регистрации, который отображается в портал Azure.

      Идентификатор определения роли выставления счетов db609904-a47f-4794-9be8-9bd86fbffd8a предназначен для читателя отдела.

  4. Щелкните Выполнить, чтобы выполнить приложение.

    Снимок экрана, показывающий пример назначения ролей в отделе регистрации: пункт

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

Теперь вы можете использовать субъект-службу для автоматического доступа к API EA. Субъект-служба имеет роль DepartmentReader.

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

  1. См. статью Назначение ролей для учетной записи регистрации — Put. При чтении нажмите кнопку "Попробовать" , чтобы назначить роль создателя подписки субъекту-службе.

    Снимок экрана, показывающий пункт

  2. Используйте данные вашей учетной записи для входа в клиент с уровнем доступа для регистрации, который вы хотите назначить.

  3. Укажите следующие параметры в запросе API. Дополнительные сведения см. в статье Назначение ролей для учетной записи регистрации — Put — параметры URI.

    • billingAccountName: этот параметр представляет идентификатор учетной записи выставления счетов. Его можно найти на портале Azure на странице Управление затратами и выставление счетов.

      Снимок экрана, показывающий идентификатор учетной записи выставления счетов.

    • billingRoleAssignmentName: этот параметр представляет уникальный идентификатор GUID, который необходимо указать. Глобально уникальный идентификатор можно создать с помощью команды PowerShell New-Guid. Можно также использовать веб-сайт генератора GUID/UUID для создания уникального идентификатора GUID.

    • enrollmentAccountName: этот параметр представляет идентификатор учетной записи. Найти идентификатор учетной записи для имени учетной записи можно на портале Azure на странице Управление затратами + выставление счетов.

      В этом примере мы использовали тестовую учетную запись GTM. Идентификатор: 196987.

      Снимок экрана, показывающий идентификатор учетной записи.

    • api-version: используйте версию 2019-10-01-preview. Используйте образец из статьи Назначение ролей в отделе регистрации — Put — Примеры.

      Текст запроса содержит код JSON с тремя параметрами, которые необходимо использовать.

      Параметр Где ее найти
      properties.principalId Это значение идентификатора объекта. Ознакомьтесь с идентификаторами субъекта-службы и клиента.
      properties.principalTenantId Ознакомьтесь с идентификаторами субъекта-службы и клиента.
      properties.roleDefinitionId /providers/Microsoft.Billing/billingAccounts/{BillingAccountID}/enrollmentAccounts/{enrollmentAccountID}/billingRoleDefinitions/a0bcee42-bf30-4d1b-926a-48d21664ef71

      Имя учетной записи выставления счетов — это тот же параметр, который использовался в параметрах API. Это идентификатор регистрации, который отображается в портал Azure.

      Идентификатор определения роли выставления счетов a0bcee42-bf30-4d1b-926a-48d21664ef71 предназначен для роли создателя подписки.

  4. Щелкните Выполнить, чтобы выполнить приложение.

    Снимок экрана: параметр

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

Теперь вы можете использовать субъект-службу для автоматического доступа к API EA. Субъект-служба имеет роль SubscriptionCreator.

Проверка назначений ролей субъекта-службы

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

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

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

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

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

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

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