将 RBAC 用于具有 Azure 自动化托管标识的应用程序

将应用程序的 RBAC 扩展到托管身份

应用程序的 RBAC 是一种预览机制，用于控制 Azure AD 应用程序对 Exchange Online 邮箱的访问权限。 Exchange Online 管理 PowerShell 模块的 V3.0 支持使用 Azure 自动化托管标识进行身份验证。我喜欢使用托管标识来运行计划的 Exchange Online 脚本，并且使用应用程序的 RBAC 来确保用于托管标识的 Azure AD 应用程序应获得正确的授权来访问邮箱似乎很自然。

作为使用应用程序的 RBAC 来控制使用托管标识运行脚本的 Azure AD 应用程序的示例，我决定调整房间邮箱使用情况报告脚本。该脚本使用Calendars.Read Graph 权限来提取日历信息。这是 RBAC for applications 支持的权限之一，因此它似乎是演示主体的一个不错且实用的选择。调整为 Azure 自动化交互运行的脚本并不困难，但需要小心（这里有一些提示）。

Azure 身份验证是一项显着差异。以下是改编后的代码如何获取托管身份的访问令牌并使用它连接到 Exchange Online：

# Connect to Microsoft Graph in Azure Automation
Connect-AzAccount -Identity
$AccessToken = Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com"

Connect-ExchangeOnline -ManagedIdentity -Organization office365itpros.onmicrosoft.com

为自动化做好准备

托管标识在 Azure 自动化帐户的上下文中运行。我现有的所有 Azure 自动化帐户都已分配执行不同操作所需的图形权限。关于应用程序 RBAC 的要点在于，Exchange Online 会根据筛选器（管理范围）评估应用程序是否应获得访问邮箱的权限。为了避免分配给其他帐户的权限出现任何问题，我决定从头开始并创建一个名为 RBACforApps 的新 Azure 自动化帐户。

在大多数情况下，与 Exchange Online 交互的脚本使用 Exchange Online 管理模块中的 cmdlet。此处的情况并非如此，因为我选择使用的脚本混合了标准 PowerShell cmdlet 和 Graph API 请求来处理数据。但是，涉及不运行某些 Exchange Online cmdlet 的 Exchange 数据的脚本很少见，因此我在此处提供了有关如何配置 Azure 自动化帐户以便其可以运行 Exchange Online cmdlet 的详细信息。

首先，必须将 Exchange Online 管理 PowerShell 模块导入自动化帐户。如果不导入该模块，该帐户将无法运行任何 Exchange Online cmdlet。如果您计划使用该帐户从其他模块运行 cmdlet，则还必须导入这些模块。

接下来，如果自动化帐户需要运行 Exchange Online cmdlet，则必须向自动化帐户分配以管理员身份管理 Exchange 的权限。实际上，您允许该帐户运行 cmdlet，就像管理员登录到交互式 PowerShell 会话一样。要将“管理 Exchange 作为应用程序”角色分配给 Azure 自动化帐户，请运行以下 PowerShell 代码，该代码使用 Microsoft Graph PowerShell SDK 中的 cmdlet：

Connect-MgGraph -Scopes Directory.ReadWrite.All

$ManagedIdentityApp = Get-MgServicePrincipal -Filter "displayName eq 'RBACforApps'"
$ExoApp = Get-MgServicePrincipal -Filter "AppId eq '00000002-0000-0ff1-ce00-000000000000'"
$AppPermission = $ExoApp.AppRoles | Where-Object {$_.DisplayName -eq "Manage Exchange As Application"}
$AppRoleAssignment = @{
"PrincipalId" = $ManagedIdentityApp.Id
"ResourceId" = $ExoApp.Id
"AppRoleId" = $AppPermission.Id
}
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentityApp.Id -BodyParameter $AppRoleAssignment

最后，在 Azure 自动化帐户可以运行 Exchange Online cmdlet 之前，必须将 Exchange 管理员角色分配给 Azure 自动化帐户使用的应用程序。有关确保应用程序可以运行 Exchange Online cmdlet 所需遵循的项目清单，请参阅本文。

运行基线测试

若要确定 Azure 自动化帐户可以使用托管标识登录 Exchange Online，请创建一个运行 Exchange Online cmdlet 的测试 Runbook。一个简单的 Get-EXOMailbox 命令来报告某些邮箱的详细信息足以验证一切正常。

在我们将应用程序的 RBAC 引入方程式之前，我们应该使用正常的图形权限运行基线测试。为此，我们将脚本中发出的 API 请求所需的图形权限（Place.Read.All 和 Calendars.Read） 分配给 RBACforApps 应用。然后添加房间邮箱使用脚本中的代码并确保其正常运行。

准备应用 RBAC 来应对应用程序限制

通过运行 Get-EXOMailbox cmdlet 并在 RecipientTypeDetails 参数中传递 RoomMailbox 值，可以轻松查找会议室邮箱。例如：

Get-ExoMailbox -RecipientTypeDetails RoomMailbox | Set-Mailbox -CustomAttribute1 'PublicRoom'

如有必要，稍后我们可以通过更新 CustomAttribute1 以存储另一个值来删除对邮箱的访问权限。脚本的测试证明我们有一个有效的代码。现在，我们从 RBACforApps 应用中删除 Calendars.Read 权限。这可确保托管身份仅在满足应用程序 RBAC 的要求时才能访问房间邮箱。

[Array]$SPPermissions = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentityApp.Id
$GraphApp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'" # Microsoft Graph
$Role = $GraphApp.AppRoles | Where-Object {$_.Value -eq "Calendars.Read"}
$Assignment = $SpPermissions | Where-Object {$_.AppRoleId -eq $Role.Id}
Remove-MgServicePrincipalAppRoleAssignment -AppRoleAssignmentId $Assignment.Id -ServicePrincipalId $ManagedIdentityApp.Id

现在，我们为应用程序控制对房间邮箱日历的访问创建 RBAC 基础。这是通过创建以下内容来完成的：

• Exchange Online 中的服务主体对象，指向托管标识所使用的企业应用程序的服务主体。
• 查找房间邮箱的管理范围。
• 用于链接 Exchange Online 服务主体对象、管理范围和应用程序日历读取权限的管理角色分配。

结果是，当 Exchange Online 发现托管标识使用的应用程序尝试访问某些邮箱中的日历时，它会检查这些日历是否属于管理范围中定义的邮箱。如果这是真的，则 Exchange Online 允许访问。以下是我使用的命令：

# Grab the Application and Service Principal Identifiers for the app used by the
# managed identity
$SP = Get-MgServicePrincipal -All
$ServicePrincipalId = $SP | Where-Object {$_.displayName -eq "RBACforApps"} | Select-Object -ExpandProperty Id
$AppId = $SP | Where-Object {$_.displayName -eq "RBACforApps"} | Select-Object -ExpandProperty AppId

# Define the service principal object in Exchange Online
New-ServicePrincipal -AppId $AppId -ServiceId $ServicePrincipalId -DisplayName 'RBACforApps'

DisplayName                              ServiceId                                 AppId
-----------                              ---------                                 -----
RBACforApps                              2a492904-9d96-4ece-97e4-c55798a873f5      415e4ba8-635f-4689-b069-22dea1fcfdb3

# Define the management scope for room mailboxes
New-ManagementScope -Name "Room Mailboxes" -RecipientRestrictionFilter "CustomAttribute1 -eq 'PublicRoom'"

Name           ScopeRestrictionType Exclusive RecipientRoot RecipientFilter                   ServerFilter
----           -------------------- --------- ------------- ---------------                   ------------
Room Mailboxes RecipientScope       False                   CustomAttribute1 -eq 'PublicRoom'

# Create the management role assignment to link everything together
New-ManagementRoleAssignment -App $AppId -Role "Application Calendars.Read" -CustomResourceScope "Room Mailboxes"

测试选择性访问

由于我们已从其应用中删除了Calendars.Read权限，因此 Azure 自动化 Runbook 现在依赖于应用程序的 RBAC 来获取对房间邮箱日历的访问权限。通过 Azure 管理中心的测试窗格执行 Runbook，检查一切是否仍然正常。图 1 显示了结果。一切都很好，我们注意到董事会会议室是使用最频繁的。

下一步测试选择性访问。通过更新自定义属性来删除应用程序对董事会会议室邮箱的访问权限。

Set-Mailbox -Identity "Board Conference Room" -CustomAttribute1 $Null

继续再次执行 Runbook。这次，RBAC for Applications 将不会授予对董事会会议室邮箱的访问权限，因为它不属于为角色分配定义的管理范围，因此该房间不会出现在使用情况统计信息中。请记住，Exchange Online 会缓存管理范围以获得更好的性能，因此请等待 30 分钟，然后再使用更新的范围进行测试。图2显示了结果——正如所料，没有董事会会议室的迹象！

您可以从 GitHub 下载我使用的 Runbook 代码。

控制很重要

应用程序的 RBAC 允许 Azure AD 应用程序选择性地访问 Exchange Online 邮箱。许多处理大量邮箱的脚本作为后台或计划作业运行。适用于应用程序的 RBAC 可以与 Azure 自动化使用托管标识执行的脚本配合使用，这非常棒。对用户数据进行控制的能力始终受到赞赏。如果应用程序的 RBAC 涵盖 SharePoint Online、Teams 和其他保存机密数据的潜在存储库，那就太好了。