Exchange Online 中应用程序的基于角色的访问控制
本文将指导你使用精细且可缩放的资源范围的访问控制：基于角色的访问控制 (RBAC) for Applications in Exchange Online。
概述
RBAC for Applications in Exchange Online 允许管理员向独立访问 Exchange Online 中的数据的应用程序授予权限。 此授权可以与访问范围 (资源范围配对，) 指定应用可以访问哪些邮箱。 此功能扩展 Exchange Online 中的当前 RBAC 模型，并替换应用程序访问策略。
注意
使用 RBAC 应用程序角色时，无法访问 自动发现服务 。 如果需要对 Exchange Online 执行自动发现请求，请使用应用程序 访问策略 Microsoft Entra ID 权限来限制邮箱访问。
此系统的核心是管理角色分配配置，该配置表示管理员允许主体访问数据的意图。 在这种情况下，允许应用针对一组目标资源执行某些角色。 例如，管理员可以使用 管理范围配置仅在特定区域中访问日历数据的会议室预订系统。 请参阅下图，说明角色分配模型：
配置说明
以下步骤将指导你创建这些应用程序 RBAC 分配：
要求
组织管理角色组具有新 Application RBAC 角色的委派角色分配。 你需要是组织管理角色组的成员才能分配这些权限。 或者，可以使用 Exchange Online RBAC 在认为合适的情况下向这些应用程序角色授予委派分配。 在 Microsoft Entra ID 中，需要 Exchange 管理员角色来分配这些权限。
定义资源范围
- 管理范围： 一个 Exchange 实体 ，该实体使用对这些邮箱的属性使用筛选器表达式来表示一组邮箱。
- 管理单元： Microsoft Entra 资源，它可以是其他Microsoft Entra 资源的容器，该资源仅包含用户组或设备。 若要了解详细信息，请参阅 Microsoft Entra ID 中的管理单元 和 创建或删除管理单元。
管理范围
管理范围允许管理员根据这些对象的属性限定一组邮箱的范围。 有关 添加、 删除和 设置的信息，请参阅管理范围文档。 下面是管理范围中的 可筛选属性 列表。
注意
虽然有一个名为“管理单元”的属性，但我们建议对角色分配使用本机管理单元参数，以避免将范围创建为中间指针对象。
服务主体
服务主体表示租户中应用程序的实例。 应将 Exchange 中的服务主体视为指向 Entra ID Microsoft 现有服务主体的指针。 不能直接使用 Exchange Online 工具创建服务主体。 Microsoft Entra 工具用于管理租户中的服务主体注册。 Exchange 会阻止创建无效指针，并自动反映Microsoft Entra ID 中服务主体的任何删除。
新建服务主体
New-ServicePrincipal -AppId <Client Application ID in AAD> -ObjectId <Service principal object ID in AAD> -DisplayName <name>
以下屏幕截图可帮助你在 Entra ID Microsoft中找到这些 ID：
注意
不要使用“应用注册”页中的 ID，因为它显示不同的值。 红色轮廓的“应用程序 ID”是 AppID，“对象 ID”是 ServiceID。
可以使用另一种方法通过 Get-MgServicePrincipal 查找这些 ID。
删除服务主体
Remove-ServicePrincipal -Identity <ObjectID, AppID, or DisplayName>
设置服务主体
Set-ServicePrincipal -Identity <ObjectID, AppID, or DisplayName > -DisplayName <Updated name>
应用程序角色
应用程序角色是 Exchange Online 中一种特殊类型的管理角色，只能分配给应用程序。 可以使用 Get-ManagementRole 枚举这些角色。
角色分配
管理角色分配将主体、角色和自定义资源范围关联在一起。 此分配充当跨范围执行角色的服务主体的权限分配。
新角色分配
New-ManagementRoleAssignment [[-Name] <String>] -Role <RoleIdParameter> -App <ObjectID, AppID, or DisplayName> -CustomResourceScope <Management Scope> (or -RecipientAdministrativeUnitScope)
设置角色分配
Set-ManagementRoleAssignment [-Identity] <RoleAssignmentIdParameter> -CustomResourceScope <Management Scope> (or -RecipientAdministrativeUnitScope)
删除角色分配
若要删除角色分配，请参阅 删除管理分配。
测试授权
测试 cmdlet 可用于模拟特定服务主体的 RBAC 分配启用的行为。
注意
此方法排除可能在 Entra ID 中单独授予的权限Microsoft。
测试授权时，可以包含一个可选资源参数，以评估哪些作用域内权限适用于该目标邮箱。
InScope will = true or false 表示如果、true、该权限应用于该服务主体的邮箱，或 false，则表示服务主体具有该权限，但不具有该特定邮箱的权限。 省略此标志将导致“未运行”。
测试结果始终包含特定分配权限的允许资源范围。
测试服务主体访问
Test-ServicePrincipalAuthorization -Identity <ObjectID, AppID, or DisplayName> [-Resource] <target mailbox>
示例
在 PowerShell 中使用 Connect-ExchangeOnline 后，请执行以下步骤：
示例一：使用管理范围为加拿大员工配置日历读取访问权限
New-ServicePrincipal -AppId 71487acd-ec93-476d-bd0e-6c8b31831053 -ObjectId 6233fba6-0198-4277-892f-9275bf728bcc -DisplayName "example"
DisplayName ObjectId AppId
----------- --------- -----
example 6233fba6-0198-4277-892f-9275bf728bcc 71487acd-ec93-476d-bd0e-6c8b3183105
New-ManagementScope -Name "Canadian employees" -RecipientRestrictionFilter "CustomAttribute1 -eq '012332'"
Name ScopeRestrictionType Exclusive RecipientRoot RecipientFilter
---- -------------------- --------- ------------- ---------------
Canadian employees RecipientScope False CustomAttribute1 -eq '012332'
New-ManagementRoleAssignment -App 6233fba6-0198-4277-892f-9275bf728bcc -Role "Application Calendars.Read" -CustomResourceScope "Canadian Employees"
Name Role RoleAssigneeName RoleAssigneeType AssignmentMethod
---- ---- ---------------- ---------------- ----------------
Application Calendar... Application Ca... 6233fba6-0198-... ServicePrincipal Direct
示例 2：为所有欧洲管理单元邮箱配置 Mail.Read
New-ServicePrincipal -AppId eb19847b-5563-42ea-b719-ea47cb0cf4b3 -ObjectId 59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36 -DisplayName "example"
DisplayName ObjectId AppId
----------- --------- -----
example 59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36 eb19847b-5563-42ea-b719-ea47cb0cf4b3
New-ManagementRoleAssignment -App 59b7c6cb-58d3-4ee8-a409-8c1f9dbb5d36 -Role "Application Mail.Read" -RecipientAdministrativeUnitScope 4d819ce9-9257-44d7-af20-68a49e6697f4
Name Role RoleAssigneeName RoleAssigneeType AssignmentMethod
---- ---- ---------------- ---------------- ----------------
Application Mail.Rea... Application Ma... 59b7c6cb-58d3-... ServicePrincipal Direct
示例 3：测试分配给服务主体的权限
Test-ServicePrincipalAuthorization -Resource b -Identity "DemoB" | Format-Table
RoleName GrantedPermissions AllowedResourceScope ScopeType InScope
-------- ------------------ -------------------- --------- ------
Application Mail.Read Mail.Read Scope-MESGaDN CustomRecipientScope False
Application Calendars.Read Calendars.Read Scope-DL1 CustomRecipientScope False
Application Contacts.Read Contacts.Read Scope-MESGa CustomRecipientScope False
限制
- 应用程序不能成为角色组的成员。
- 应用程序角色只能分配给服务主体。
- 无法复制或派生应用程序角色。
- 独占管理范围不限制应用访问。
- 对应用权限的更改会受到缓存维护的影响，该维护时间在 30 分钟到 2 小时之间，具体取决于应用最近的使用情况。 测试配置时，测试命令会绕过此缓存。 没有对 API 进行入站调用的应用将在 30 分钟内重置其缓存，而活跃使用的应用将使其缓存保持活动状态长达 2 小时。
支持的协议
- MS Graph
- EWS
支持的应用程序角色
| 名称 | 协议 | 权限列表 | 说明 |
|---|---|---|---|
| Application Mail.Read | MS Graph | Mail.Read | 允许应用在没有登录用户的情况下读取所有邮箱中的电子邮件。 |
| Application Mail.ReadBasic | MS Graph | Mail.ReadBasic | 允许应用在没有登录用户的情况下读取所有邮箱中除正文、预览版、附件和任何扩展属性外的电子邮件 |
| Application Mail.ReadWrite | MS Graph | Mail.ReadWrite | 允许应用在没有登录用户的情况下在所有邮箱中创建、读取、更新和删除电子邮件。 不包括发送邮件的权限。 |
| Application Mail.Send | MS Graph | Mail.Send | 允许应用在没有登录用户的情况下以任意用户身份发送邮件。 |
| Application MailboxSettings.Read | MS Graph | MailboxSettings.Read | 允许应用在没有登录用户的情况下读取所有邮箱中的用户的邮箱设置。 |
| Application MailboxSettings.ReadWrite | MS Graph | MailboxSettings.ReadWrite | 允许应用在没有登录用户的情况下在所有邮箱中创建、读取、更新和删除用户的邮箱设置。 |
| Application Calendars.Read | MS Graph | Calendars.Read | 允许应用在没有登录用户的情况下读取所有日历的事件。 |
| Application Calendars.ReadWrite | MS Graph | Calendars.ReadWrite | 允许应用在没有登录用户的情况下创建、读取、更新和删除所有日历的事件。 |
| Application Contacts.Read | MS Graph | Contacts.Read | 允许应用在没有已登录用户的情况下读取所有邮箱中的所有联系人。 |
| Application Contacts.ReadWrite | MS Graph | Contacts.ReadWrite | 允许应用在没有登录用户的情况下创建、读取、更新和删除所有邮箱中的全部联系人。 |
| 应用程序邮件完全访问权限 | MS Graph | Mail.ReadWrite、Mail.Send | 允许应用在所有邮箱中创建、读取、更新和删除电子邮件，并作为任何没有登录用户的用户发送邮件。 |
| Application Exchange Full Access | MS Graph | Mail.ReadWrite、Mail.Send、MailboxSettings.ReadWrite、Calendars.ReadWrite、Contacts.ReadWrite | 无已登录用户：允许应用在所有邮箱中创建、读取、更新和删除电子邮件，以及以任何用户身份发送邮件。 允许应用在所有邮箱中创建、读取、更新和删除用户的邮箱设置。 允许应用创建、读取、更新和删除所有日历的事件。 允许应用创建、读取、更新和删除所有邮箱中的所有联系人。 |
| 应用程序 EWS。AccessAsApp | EWS | EWS。AccessAsApp | 允许应用使用具有对所有邮箱的完全访问权限的 Exchange Web 服务。 |
你可能会注意到，这些角色表示Microsoft Graph 权限，你可以在 Azure 标识平台的其他地方同意这些权限。 除了这些角色分配允许精细的资源范围访问之外，这些权限将具有与这些 Graph 权限相同的效果。
常见问题
为什么我的应用程序仍有权访问未使用 RBAC 授予的邮箱？
需要确保已删除在 Entra ID Microsoft分配的租户范围的未作用域权限。 使用 RBAC 分配的权限除了授予你Microsoft Entra ID 之外，还会执行该操作。 Microsoft Entra 权限只能使用应用程序访问策略进行约束。
如何在一个界面中查看和修改所有应用程序权限？
为了确保管理员具有应用权限的统一视图，我们将以Microsoft Entra 管理员体验在 Exchange Online 中显示授予的这些权限。 此功能即将推出，请继续关注。
如何从应用程序访问策略迁移到应用程序的 RBAC？
借助应用程序访问策略，可以在 Azure 中获取服务主体、权限许可以及与 Exchange Online 中的服务主体关联的策略。 虽然可以使用 Exchange 管理范围或管理单元以任何适合自己的方式重新构建范围机制，但下面提供了一些有关重用应用访问策略中的组作为 RBAC for Applications 授予的范围的一些指导。 此过程不会导致应用使用中断。
迁移步骤：
- 创建新的管理范围，该范围指向应用程序访问策略中的范围组
- 创建服务主体指针对象
- 使用管理范围限制向 Exchange Online 中的服务主体分配所需的权限
- 删除对 Azure 中权限的同意
- 删除应用程序访问策略
在步骤 1 中创建管理范围时，将使用带有筛选器参数 MemberOfGroup的收件人筛选器。
下面是一个示例：“MemberOfGroup -eq 'CN=mesga20220818210551，OU=Fabrikam346.onmicrosoft.com，OU=Microsoft Exchange 托管组织，DC=NAMPR00A001，DC=prod，DC=outlook，DC=com'”
注意
此筛选器参数使用组的 可分辨名称 ，可以使用 Get-Group cmdlet 找到该名称。
局限性：
- 嵌套组成员被视为范围外。 只有直接组成员身份会导致成员被视为授权范围。
- Microsoft支持 365 个组、Mail-Enabled 安全组和通讯组列表。
RBAC for Applications 如何与应用程序访问策略协同工作？
与应用访问策略的兼容性
RBAC for Applications 取代了应用程序访问策略。
授权互操作性可按如下所述进行描述：
应用程序访问策略仅约束Microsoft Entra ID 中分配的权限。
RBAC for Applications 提供具有关联资源范围的授权的备用表达式。
应用可以具有Microsoft Entra 同意的权限和 RBAC 分配。 例如，当应用具有租户范围的 Mail.Read 和作用域为 Mail.Send 时，我们预计会出现这种情况。
权限同意是累加的。
示例一：来自 2 个系统的同意
- 应用在 Entra ID Microsoft Mail.Read
- 此应用的范围限定为使用应用程序访问策略启用邮件的安全组 1
- 同一应用在 RBAC for Applications 中同意管理范围 1 的 Calendar.Read
- 邮箱 A 位于已启用邮件的安全组 1 中
- 邮箱 B 在管理范围 1 的范围内
对应用 1 需要 Mail.Read 和 Calendar.Read 的终结点进行 MS Graph 访问：
- 面向邮箱 A： 失败
- 面向邮箱 B： 失败
此终结点需要 Mail.Read 和 Calendar.Read。 虽然应用对两个单独的邮箱单独拥有这些权限，但它对一个邮箱没有这两个权限。
示例 2：分配相同权限两次
- 应用在 Entra ID Microsoft Mail.Read
- 此应用的范围限定为使用应用程序访问策略的启用邮件的安全组 1
- 同一应用已同意使用 RBAC for Applications 管理范围 1 的 Mail.Read
- 邮箱 A 位于已启用邮件的安全组 1 中
- 管理范围 1 允许根据某些筛选器（例如“Alias -ne mbxa”）访问邮箱 A (以外的每个邮箱 )
对应用 1 需要 Mail.Read 的终结点的 MS Graph 访问权限：
- 面向邮箱 A：允许
- 面向邮箱 B：允许
虽然 Mail.Read from Microsoft Entra 仅允许访问邮箱 A，但 RBAC 分配允许访问除 A 之外的所有内容。实际上，这允许访问所有内容，因为“A 和 Not A”意味着一切。
虽然我们概述了这些边缘用例的完整性，但我们并不期望应用程序访问策略通常与 RBAC for Applications 一起使用。 租户范围的权限应在 Microsoft Entra ID 中分配，而应使用 RBAC for Applications 授予资源范围的权限。
RBAC for Applications 支持多少个应用程序？
使用 RBAC for Applications，每个租户最多可以有 10,000 个应用程序。 如果此限制对你造成问题，请告知我们。 我们已以高度可缩放的方式为应用程序构建了 RBAC，以满足最大客户的需求。
有关此功能的反馈
有关此功能的 exoapprbacpreview@microsoft.com反馈可与 共享。