将企业协议角色分配给服务主体

可以在 Azure 门户中管理企业协议 (EA) 注册。 可以创建不同的角色来管理组织、查看成本和创建订阅。 本文通过配合使用 Azure PowerShell 和 REST API 与 Microsoft Entra ID 服务主体，帮助你自动执行其中一些任务。

在开始之前，请确保熟悉以下文章的内容：

• 企业协议角色
• 使用 Azure PowerShell 进行登录

需要通过某种方式来调用 REST API。 查询 API 的一些常用方式包括：

• Visual Studio
• Insomnia
• Bruno
• PowerShell 的 Invoke-RestMethod
• Curl

创建服务主体并对其进行身份验证

若要使用服务主体自动执行 EA 操作，需要创建 Microsoft Entra 应用标识，然后可以通过自动方式进行身份验证。

按照这些文章中的步骤通过使用服务主体进行创建和身份验证。

• 创建服务主体
• 获取用于登录的租户和应用 ID 值

下面是应用程序注册页的一个示例。

查找服务主体和租户 ID

需要服务主体的对象 ID 和租户 ID。 本文后面的权限分配操作需要此信息。 所有应用程序都在租户的 Microsoft Entra ID 中注册。 应用注册完成后，会创建两种类型的对象:

• 应用程序对象 - 应用程序 ID 是你在企业应用程序下看到的信息。 不要使用 ID 来授予任何 EA 角色。
• 服务主体对象 - 可在 Microsoft Entra ID 的“企业注册”窗口中查看服务主体对象。 对象 ID 用于向服务主体授予 EA 角色。

1. 打开 Microsoft Entra ID，然后选择“企业应用程序”。

2. 在列表中找到你的应用。

   

3. 选择应用以查找应用程序 ID 和对象 ID：

   

4. 转到 Microsoft Entra ID“概述”页，查找租户 ID。

   

可分配给服务主体的权限

在本文的后面部分中，你将使用 EA 角色授予 Microsoft Entra 应用执行操作的权限。 只能将以下角色分配给服务主体，并且需要角色定义 ID，正如以下所示。

• 只有具有注册写入者角色的用户才能将 EnrollmentReader 角色分配给服务主体。 分配给服务主体的 EnrollmentReader 角色不会显示在 Azure 门户中。 它是以编程方式创建的，因此仅用于编程目的。
• 只有具有注册写入者角色或部门写入者角色的用户才能将 DepartmentReader 角色分配给服务主体。
• 只有是注册帐户所有者（EA 管理员）的用户才能将 SubscriptionCreator 角色分配给服务主体。 该角色不会显示在 Azure 门户中。 它是以编程方式创建的，因此仅用于编程目的。
• EA 买方角色不会显示在 Azure 门户中。 它是以编程方式创建的，因此仅用于编程目的。

向服务主体授予 EA 角色时，必须使用 billingRoleAssignmentName 所需的属性。 该参数是需要提供的唯一 GUID。 可以使用 New-Guid PowerShell 命令生成 GUID。 也可使用在线 GUID/UUID 生成器网站生成唯一的 GUID。

服务主体只能有一个角色。

向服务主体分配注册帐户角色权限

1. 阅读角色分配 - Put REST API 文章。 阅读本文时，请选择“试用”以通过使用服务主体开始使用。

   

2. 使用你的帐户凭据通过要分配的注册访问权限登录到租户。

3. 提供以下参数作为 API 请求的一部分。

   • billingAccountName：此参数为“计费帐户 ID”。 可以在 Azure 门户中的“成本管理 + 计费”概述页面上找到此 ID。

     

   • billingRoleAssignmentName：此参数是需要提供的唯一 GUID。 可以使用 New-Guid PowerShell 命令生成 GUID。 也可使用在线 GUID/UUID 生成器网站生成唯一的 GUID。

   • api-version：使用 2019-10-01-preview 版本。 使用角色分配 - Put - 示例中的示例请求正文。

     请求正文具有 JSON 代码，其中包含需要使用的三个参数。

     参数	查找位置
     properties.principalId	它是对象 ID 的值。 请参阅查找服务主体和租户 ID。
     properties.principalTenantId	请参阅查找服务主体和租户 ID。
     properties.roleDefinitionId	/providers/Microsoft.Billing/billingAccounts/{BillingAccountName}/billingRoleDefinitions/24f8edb6-1668-4659-b5e2-40bb5f3a7d7e

     计费帐户名称是在 API 参数中使用的同一参数。 它是 Azure 门户中显示的注册 ID。

     请注意，24f8edb6-1668-4659-b5e2-40bb5f3a7d7e 是 EnrollmentReader 的计费角色定义 ID。

4. 选择“运行”以启动命令。

   

   200 OK 响应显示服务主体已成功添加。

现在，可以使用服务主体自动访问 EA API。 该服务主体具有 EnrollmentReader 角色。

向服务主体分配 EA 购买者角色权限

对于 EA 买方角色，请对注册读者使用相同的步骤。 使用以下示例指定 roleDefinitionId：

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

向服务主体分配部门读取者角色

1. 请阅读注册部门角色分配 - Put REST API 文章。 阅读此文时，请选择“试用”。

   

2. 使用你的帐户凭据通过要分配的注册访问权限登录到租户。

3. 提供以下参数作为 API 请求的一部分。

   • billingAccountName：此参数为“计费帐户 ID”。 可以在 Azure 门户中的“成本管理 + 计费”概述页面上找到此 ID。

     

   • billingRoleAssignmentName：此参数是需要提供的唯一 GUID。 可以使用 New-Guid PowerShell 命令生成 GUID。 也可使用在线 GUID/UUID 生成器网站生成唯一的 GUID。

   • departmentName：此参数是部门 ID。 可以在 Azure 门户中的“成本管理 + 计费”>“部门”页上查看部门 ID 。

     本示例使用了 ACE 部门。 本示例的 ID 为 84819。

     

   • api-version：使用 2019-10-01-preview 版本。 使用注册部门角色分配 - Put 中的示例。

     请求正文具有 JSON 代码，其中包含需要使用的三个参数。

     参数	查找位置
     properties.principalId	它是对象 ID 的值。 请参阅查找服务主体和租户 ID。
     properties.principalTenantId	请参阅查找服务主体和租户 ID。
     properties.roleDefinitionId	/providers/Microsoft.Billing/billingAccounts/{BillingAccountName}/billingRoleDefinitions/db609904-a47f-4794-9be8-9bd86fbffd8a

     计费帐户名称是在 API 参数中使用的同一参数。 它是 Azure 门户中显示的注册 ID。

     计费角色定义 ID db609904-a47f-4794-9be8-9bd86fbffd8a 用于部门读者。

4. 选择“运行”以启动命令。

   

   200 OK 响应显示服务主体已成功添加。

现在，可以使用服务主体自动访问 EA API。 该服务主体具有 DepartmentReader 角色。

向服务主体分配订阅创建者角色

1. 阅读注册帐户角色分配 - Put 文章。 阅读时，请选择“试用”以将订阅创建者角色分配给服务主体。

   

2. 使用你的帐户凭据通过要分配的注册访问权限登录到租户。

3. 提供以下参数作为 API 请求的一部分。 阅读注册帐户角色分配 - Put - URI 参数文章。

   • billingAccountName：此参数为“计费帐户 ID”。 可以在 Azure 门户中的“成本管理 + 计费”概述页上找到此 ID。

     

   • billingRoleAssignmentName：此参数是需要提供的唯一 GUID。 可以使用 New-Guid PowerShell 命令生成 GUID。 也可使用在线 GUID/UUID 生成器网站生成唯一的 GUID。

   • enrollmentAccountName：此参数是帐户 ID。 可在 Azure 门户中“成本管理 + 计费”页上找到帐户名的帐户 ID。

     对于本示例，我们使用了 GTM Test Account。 ID 为 196987。

     

   • api-version：使用 2019-10-01-preview 版本。 使用注册部门角色分配 - Put - 示例中的示例。

     请求正文具有 JSON 代码，其中包含需要使用的三个参数。

     参数	查找位置
     properties.principalId	它是对象 ID 的值。 请参阅查找服务主体和租户 ID。
     properties.principalTenantId	请参阅查找服务主体和租户 ID。
     properties.roleDefinitionId	/providers/Microsoft.Billing/billingAccounts/{BillingAccountID}/enrollmentAccounts/{enrollmentAccountID}/billingRoleDefinitions/a0bcee42-bf30-4d1b-926a-48d21664ef71

     计费帐户名称是在 API 参数中使用的同一参数。 它是 Azure 门户中显示的注册 ID。

     计费角色定义 ID a0bcee42-bf30-4d1b-926a-48d21664ef71 用于订阅创建者角色。

4. 选择“运行”以启动命令。

   

   200 OK 响应显示服务主体已成功添加。

现在，可以使用服务主体自动访问 EA API。 该服务主体具有 SubscriptionCreator 角色。

验证服务主体角色分配

服务主体角色分配在 Azure 门户中不可见。 使用计费角色分配 - 按注册帐户列出 - REST API（Azure 计费）API，可以查看注册帐户角色分配，包括订阅创建者角色。 使用该 API 来验证是否成功进行角色分配。

故障排除

你必须标识并使用你向其授予 EA 角色的 Enterprise 应用程序对象 ID。 如果使用其他应用程序的对象 ID，API 调用将失败。 验证是否正在使用正确的 Enterprise 应用程序对象 ID。

如果在进行 API 调用时收到以下错误，则你可能错误地使用了位于应用注册中的服务主体对象 ID 值。 若要解决此错误，请确保正在使用企业应用程序中的服务主体对象 ID，而不是应用注册。

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

后续步骤

企业协议计费帐户入门。