权利管理中的委托和角色
在 Microsoft Entra ID 中，可以使用角色模型通过标识治理大规模管理访问。
- 可以使用访问包表示组织中的组织角色，例如“销售代表”。 表示该组织角色的访问包将包括销售代表通常可能需要的跨多个资源的所有访问权限。
- 应用程序可定义其自己的角色。 例如，如果你有一个销售应用程序，并且该应用程序的清单中包含应用角色“销售人员”，则可将应用清单中的该角色包含在访问包中。 在用户可以同时具有多个特定于应用程序的角色的情况下，应用程序还可以使用安全组。
- 可以使用角色来委派管理访问权限。 如果有销售人员所需的所有访问包的目录，可以通过为其分配特定于目录的角色来分配负责该目录的人员。
本文讨论了如何使用角色来管理 Microsoft Entra 权利管理中的各个方面，以控制对权利管理资源的访问。
默认情况下，全局管理员角色与标识监管管理员角色中的用户可以创建和管理权利管理的各个方面。 但是，这些角色中的用户可能不知道需要访问包的所有情况。 通常，是各自的部门、团队或项目中的用户知道他们正在合作的对象、使用的资源，以及相应的时间长度。 不要向非管理员授予不受限制的权限，而可以向用户授予执行其作业所需的最低权限，并避免创建有冲突或者不适当的访问权限。
此视频概述了如何将访问管理从 IT 管理员委托给非管理员用户。
委托示例
为了了解如何在权利管理中委托访问管理，让我们从一个示例着手。 假设你的组织中有以下管理员和经理。
作为 IT 管理员，Hana 在每个部门中都有联系人 - 市场营销部的 Mamta、财务部的 Mark 以及法务部的 Joe，这些人负责其所在部门的资源和业务关键内容。
使用权利管理，你可以将访问管理委托给这些非管理员的人员，因为这些人知道哪些用户需要对哪些资源具有多长时间的访问权限。 委派非管理员可确保适当的人员为其部门管理访问权限。
Hana 可以采用下面这种方式将访问管理委托给市场营销部、财务部和法务部。
Hana 创建新的 Microsoft Entra 安全组，并将 Mamta、Mark 和 Joe 添加为组的成员。
Hana 将该组添加到目录创建者角色。
Mamta、Mark 和 Joe 现在可以为自己的部门创建目录、添加自己的部门所需的资源，并在目录中执行进一步的委托。 他们看不到彼此的目录。
Mamta 创建“市场营销”目录，它是资源的容器。
Mamta 向此目录添加市场营销部所拥有的资源。
Mamta 可以将此部门的其他人员添加为此目录的目录所有者，这有助于共享目录管理职责。
Mamta 可以进一步将“市场营销”目录中访问包的创建和管理委托给市场营销部的项目经理。 用户可通过向其分配目录上的访问包管理者角色来完成此操作。 访问包管理者可以在该目录中创建和管理访问包以及策略、请求和分配。 如果目录允许，访问包管理者还可以配置用于从连接的组织中引入用户的策略。
下图显示了包含市场营销部、财务部和法务部的资源的目录。 使用这些目录时，项目经理可以为他们的团队或项目创建访问包。
委托后，市场营销部的角色可能与下表类似。
| 用户 | 组织角色 | Microsoft Entra 角色 | 权利管理角色 |
|---|---|---|---|
| Hana | IT 管理员 | 全局管理员或 Identity Governance 管理员 | |
| Mamta | 市场营销部经理 | 用户 | 目录创建者和目录所有者 |
| Bob | 市场营销部主管 | 用户 | 目录所有者 |
| Jessica | 市场营销部项目经理 | 用户 | 访问包管理者 |
权利管理角色
权利管理具有以下角色，具有管理权利管理本身的权限，适用于所有目录。
| 权利管理角色 | 角色定义 ID | 描述 |
|---|---|---|
| 目录创建者 | ba92d953-d8e0-4e39-a797-0cbedb0a89e8 |
创建和管理目录。 通常，该角色是不充当全局管理员的 IT 管理员，或者是资源集合的资源所有者。 创建目录的人员将自动成为该目录的第一个目录所有者，并可以添加其他目录所有者。 目录创建者无法管理或查看他们不拥有的目录，也无法将他们不拥有的资源添加到目录中。 如果目录创建者需要管理其他目录或添加他们不拥有的资源，那么他们可以请求成为该目录或资源的共同所有者。 |
权利管理具有为每个特定目录定义的以下角色，用于管理目录中的访问包和其他配置。 管理员或目录所有者可以将用户、用户组或服务主体添加到这些角色。
| 权利管理角色 | 角色定义 ID | 描述 |
|---|---|---|
| 目录所有者 | ae79f266-94d4-4dab-b730-feca7e132178 |
编辑和管理目录中的访问包和其他资源。 通常，该角色是 IT 管理员或资源所有者，或者是目录所有者选择的用户。 |
| 目录读取者 | 44272f93-9762-48e8-af59-1b5351b1d6b3 |
查看目录中的现有访问包。 |
| 访问包管理者 | 7f480852-ebdc-47d4-87de-0d8498384a83 |
编辑和管理目录中的所有现有访问包。 |
| 访问包分配管理人员 | e2182095-804a-4656-ae11-64734e9b7ae5 |
编辑和管理所有现有访问包的分配。 |
此外，所选的审批者和访问包请求者也拥有权限，但他们不是角色。
| Right | 描述 |
|---|---|
| 审批者 | 由策略授权，可以批准或拒绝对访问包的请求，但无法更改访问包定义。 |
| 请求者 | 由访问包的策略授权，可以请求该访问包。 |
下表列出了权利管理角色可以在权利管理中执行的任务。
| 任务 | Identity Governance 管理员 | 目录创建者 | 目录所有者 | 访问包管理者 | 访问包分配管理者 |
|---|---|---|---|---|---|
| 委托给目录创建者 | ✔️ | ||||
| 添加连接的组织 | ✔️ | ||||
| “创建新目录” | ✔️ | ✔️ | |||
| 将资源添加到目录 | ✔️ | ✔️ | |||
| 添加目录所有者 | ✔️ | ✔️ | |||
| 编辑目录 | ✔️ | ✔️ | |||
| 删除目录 | ✔️ | ✔️ | |||
| 委托给访问包管理者 | ✔️ | ✔️ | |||
| 删除访问包管理者 | ✔️ | ✔️ | |||
| 在目录中创建新的访问包 | ✔️ | ✔️ | ✔️ | ||
| 更改访问包中的资源角色 | ✔️ | ✔️ | ✔️ | ||
| 创建和编辑策略，包括用于外部协作的策略 | ✔️ | ✔️ | ✔️ | ||
| 直接将用户分配到访问包 | ✔️ | ✔️ | ✔️ | ✔️ | |
| 直接从访问包中删除用户 | ✔️ | ✔️ | ✔️ | ✔️ | |
| 查看谁有访问包的分配 | ✔️ | ✔️ | ✔️ | ✔️ | |
| 查看访问包的请求 | ✔️ | ✔️ | ✔️ | ✔️ | |
| 查看请求的传递错误 | ✔️ | ✔️ | ✔️ | ✔️ | |
| 重新处理请求 | ✔️ | ✔️ | ✔️ | ✔️ | |
| 取消挂起的请求 | ✔️ | ✔️ | ✔️ | ✔️ | |
| 隐藏访问包 | ✔️ | ✔️ | ✔️ | ||
| 删除访问包 | ✔️ | ✔️ | ✔️ |
若要确定任务的最小特权角色，还可以参考按 Microsoft Entra ID 中的管理员任务划分的管理员角色。
注意
如果访问包策略需要审批，则已分配访问包分配管理员角色的用户将无法再绕过审批设置。 如果有需要绕过审批的方案，我们建议在不需要审批的且范围仅限于需要访问的用户的访问包上创建第二个策略。
将资源添加到目录所需的角色
全局管理员可以在目录中添加或删除任何组（云创建的安全组，或云创建的Microsoft 365 组）、应用程序或 SharePoint Online 站点。
注意
用户如果已分配有“用户管理员”角色，则将无法再在其未拥有的目录中创建目录或管理访问包。 作为目录所有者的用户管理员可以在他们拥有的目录中添加或删除任何组或应用程序，但配置为可分配给目录角色的组除外。 若要详细了解可分配角色的组，请参阅在 Microsoft Entra ID 中创建可分配角色的组。 如果组织中的用户已分配有“用户管理员”角色，以配置目录、访问包或权利管理中的策略，则应为这些用户分配“标识治理管理员”角色。
对于不是全局管理员的用户，若要将组、应用程序或 SharePoint Online 网站添加到目录中，该用户必须同时能够对该资源执行操作，并且必须是该目录的权利管理中的目录所有者角色。 用户能够对资源执行操作的最常见方法是位于允许其管理资源的 Microsoft Entra 目录角色中。 或者对于具有所有者的资源，可通过将用户分配为资源的所有者使其能够执行操作。
当用户将资源添加到目录时，权利管理检查的操作如下：
- 要添加安全组或 Microsoft 365 组：必须允许用户执行
microsoft.directory/groups/members/update和microsoft.directory/groups/owners/update操作 - 要添加应用程序：必须允许用户执行
microsoft.directory/servicePrincipals/appRoleAssignedTo/update操作 - 要添加 SharePoint Online 网站：用户必须是 SharePoint 管理员或位于允许其在网站中管理权限的 SharePoint Online 网站角色中
下表列出了一些角色组合，其中包含允许这些角色组合中的用户将资源添加到目录的操作。 要从目录中移除资源，还必须具有相同操作的角色或所有权。
| Microsoft Entra 目录角色 | 权利管理角色 | 可以添加安全组 | 可以添加 Microsoft 365 组 | 可以添加应用 | 可以添加 SharePoint Online 网站 |
|---|---|---|---|---|---|
| 全局管理员 | 不适用 | ✔️ | ✔️ | ✔️ | ✔️ |
| Identity Governance 管理员 | 不适用 | ✔️ | |||
| 组管理员 | 目录所有者 | ✔️ | ✔️ | ||
| Intune 管理员 | 目录所有者 | ✔️ | ✔️ | ||
| Exchange 管理员 | 目录所有者 | ✔️ | |||
| SharePoint 管理员 | 目录所有者 | ✔️ | ✔️ | ||
| 应用程序管理员 | 目录所有者 | ✔️ | |||
| 云应用程序管理员 | 目录所有者 | ✔️ | |||
| 用户 | 目录所有者 | 仅限组所有者 | 仅限组所有者 | 仅限应用所有者 |
来宾用户生命周期的委托管理
通常，具有来宾邀请者权限的角色中的用户可以邀请单个外部用户加入组织，且此设置可通过使用外部协作设置进行更改。
在管理外部协作时，由于协作项目的外部用户可能事先不为其他人所知，向与外部组织合作的用户分配权利管理角色便使他们能够为外部协作配置目录、访问包和策略。 这些配置允许外部协作用户请求并添加到组织的目录和访问包中。
- 若要允许连接的组织中的外部目录中的用户能够申请目录中的访问包，需要将目录设置“为外部用户启用”设为“是”。 管理员或目录所有者可更改此设置。
- 访问包还需要为不属于你目录的用户设置策略集。 此策略可由管理员、目录所有者或目录的访问包管理者创建。
- 设置了该策略的访问包允许范围内的用户申请访问权限，包括目录中尚不存在的用户。 如果请求获得批准或不需要批准，则用户会自动添加到目录中。
- 如果策略设置适用于所有用户，并且该用户不属于现有的已连接组织，则会自动新建提议的已连接组织。 可以查看连接的组织列表，并删除不再需要的组织。
还可以配置当通过权利管理引入的外部用户失去了其最后一个访问包权限分配时会发生什么情况。 可以在管理外部用户的生命周期设置中阻止其登录到此目录，或删除其来宾帐户。
限制委派的管理员为不属于目录的用户配置策略
可以在外部协作设置中将“来宾邀请设置”更改为特定管理员角色，并将“启用来宾自助注册”设置为“否”，从而阻止不属于管理角色的用户邀请个人来宾。
若要防止委派的用户通过配置权利管理让外部用户能够申请外部协作，应确保将此限制传达给所有全局管理员、标识治理管理员、目录创建者和目录所有者（因为他们能够更改目录），这样他们就不会无意中促成新目录或更新后的目录中的新协作。 他们应该确保将目录的“为外部用户启用”设置为“否”，且无任何访问包设置了允许不属于目录中的用户提出申请的策略。
可以在 Microsoft Entra 管理中心查看当前为外部用户启用的目录列表。
至少以标识治理管理员身份登录到 Microsoft Entra 管理中心。
浏览到“标识治理”>“权利管理”>“目录”。
将筛选设置“为外部用户启用”更改为“是”。
如果其中任一目录具有非零数量的访问包，则这些访问包可能为不属于目录中的用户设置了策略。
以编程方式管理权利管理角色的角色分配
还可使用 Microsoft Graph 查看和更新目录创建者以及权利管理目录特定的角色分配。 对于具有委托的 EntitlementManagement.ReadWrite.All 权限的应用程序，如果用户在其中具有相应的角色，则可调用图形 API 来列出权利管理的角色定义和这些角色定义的角色分配。
例如，若要查看分配给特定用户或组的权利管理特定角色，请使用 Graph 查询列出角色分配，并提供用户或组的 ID 作为 principalId 查询筛选器的值，如以下所示：
GET https://graph.microsoft.com/v1.0/roleManagement/entitlementManagement/roleAssignments?$filter=principalId eq 'aaaaaaaa-bbbb-cccc-1111-222222222222'&$expand=roleDefinition&$select=id,appScopeId,roleDefinition
对于特定于目录的角色，响应中的 appScopeId 指示为用户分配角色的目录。 此响应仅检索该主体对权利管理中角色的显式分配，它不会返回通过目录角色或通过分配给角色的组中的成员身份而具有访问权限的用户的结果。