将 Azure 托管标识与 Microsoft 365 PowerShell 结合使用

Azure 托管身份适用于部分但不适用于所有 Microsoft 365 模块

更新于 2023 年 7 月 15 日

使用 Azure 自动化 Runbook 是定期运行 PowerShell 脚本的好方法。在之前的文章中，我探索了如何使用 Runbook 处理 Exchange Online 数据、使用 Microsoft Graph PowerShell SDK 向新员工发送欢迎电子邮件以及在 SharePoint Online 中创建文件。所有这些都是如何利用 Azure 自动化的好例子。在本文中，我将探讨在 Azure 自动化 Runbook 中使用托管标识进行身份验证。

托管标识是系统分配和托管的标识，可用于访问资源。有两种类型的托管身份可用：系统身份和用户身份。在本文中，我将介绍系统管理的身份，而不是用户管理的身份。系统管理的身份与自动化帐户等资源相关联。正如我们稍后将看到的，能够将 Graph API 权限和 Azure AD 管理角色分配给自动化帐户的服务主体是实现的关键部分。

Microsoft 记录了可以验证托管身份的 Azure 服务集，但缺乏 Microsoft 365 PowerShell 模块的文档。我的评价是：

• Microsoft Graph PowerShell SDK（Azure AD 帐户和组）：有效。
• Microsoft Teams：有效。
• Exchange Online 管理：Exchange Online 管理 (V2) 模块尚不支持。您可以连接较旧的 Exchange V1 模块并将其与托管标识一起使用。我们将在另一篇文章中介绍这一点。
• SharePoint Online：有一些使用 SharePoint Online PowerShell 和托管标识的示例（这里是一个和第二个示例）。 SharePoint PnP 模块支持一组有限的托管标识功能。解析使用 SharePoint Online 和托管标识的细节超出了本文的范围。正如我们稍后将看到的，为了将消息写入 Teams 通道，我使用了 SharePoint PnP 模块。

总体印象是，微软设计了 Azure 自动化和托管身份来处理 Azure 资源，并没有过多关注让 Azure 自动化与 Microsoft 365 资源一起工作。尽管如此，生活（和 IT）仍然是一段旅程，所以让我们探索各种可能性。

创建 Azure 自动化帐户

首先，您需要一个与 Azure 订阅关联的 Azure 自动化帐户。有些人建议您对托管身份使用单独的帐户，但如果需要，您可以使用现有帐户。我在本文中讨论如何创建 Azure 自动化帐户，最大的区别是托管标识不需要 RunAs 帐户。

托管身份的权限和角色

Microsoft 的文档解释了系统分配的托管标识的工作原理。同一篇文章还介绍了如何创建托管身份。在本文中，我使用名为 ManagedIdentitiesAutomation 的自动化帐户。该帐户存储我们将在示例中使用的资源，主要是 PowerShell 模块。确保在开始之前加载包含 Runbook 中使用的 cmdlet 的 Graph 模块（例如 Microsoft.Graph.Authentication 和 Microsoft.Graph.Teams）作为资源自动化帐户。

创建托管标识时，Azure AD 会为托管标识创建服务主体对象。这很重要，因为服务主体是“分配权限的便捷方式”。换句话说，与其他 Azure AD 注册和企业应用程序的服务主体一样，您可以将权限和管理角色分配给托管标识的服务主体，以使这些权限可供托管标识使用。

若要查看服务主体可用的角色和权限的详细信息，请访问 Azure AD 管理中心，选择企业应用程序，然后筛选托管标识。当您找到在 Azure 自动化中创建的托管标识时，您可以看到分配给其服务主体的权限（图 1）。

图1列出了许多权限。这是因为我使用相同的帐户进行不同的测试。要确定使用图形 API 的 cmdlet 需要哪些权限，您可以按照本文中的建议进行操作。我们很快就会回到权限管理。

工作示例

工作示例是探索任何技术可能性的好方法。就我而言，我决定将我编写的用于填充团队中共享通道的成员身份的脚本移至 Azure 自动化。该脚本搜索新的 Azure AD 帐户并将其添加到共享通道，以确保组织中的每个人都可以访问该通道。将脚本移至 Azure 自动化后，我可以安排它定期运行以检测新帐户并添加新帐户。

该脚本使用 Microsoft Teams 和 Microsoft Graph PowerShell SDK 模块。作为奖励，我更新了脚本，将其处理结果发布到共享频道，以便每个人都可以看到新成员的详细信息。我们很快就会讲到那部分。

连接、身份验证和权限

该脚本需要连接到 Microsoft Graph 和 Microsoft Teams 终结点。获取访问令牌的最简单方法是运行 Connect-AzAccount cmdlet。您可以运行带有 Identity 参数的 Connect-MicrosoftTeams cmdlet 以使用托管标识，这会导致：

# Connect to Microsoft Graph in Azure Automation
Connect-AzAccount -Identity
$AccessToken = Get-AzAccessToken -ResourceUrl "https://graph.microsoft.com"
# Connect to the Graph SDK with the acquired access token
Connect-Graph -AccessToken $AccessToken.Token -Scopes AppRoleAssignment.ReadWrite.All
#Define the desired graph endpoint
Select-MgProfile  Beta
# Connect to Teams
Connect-MicrosoftTeams -Identity

Microsoft Graph PowerShell SDK V2.0（或更高版本）支持托管标识，因此您可以将连接替换为：

Connect-MgGraph -Identity -Scopes AppRoleAssignment.ReadWrite.All

请记住，SDK V2 将 cmdlet 分为生产模块和测试模块。如果您的代码使用 beta cmdlet，请记住将必要的 beta 模块（例如 Microsoft.Graph.Beta.Users）导入到 Azure 自动化帐户中。 Select-MgProfile cmdlet 不在 SDK V2 中，应从 Runbook 中删除。

检查权限

我们现在已连接到 Graph 和 Teams，但 Azure AD 生成的访问令牌不允许我们执行太多操作，除非托管标识有权运行 cmdlet 或 Graph 请求。在继续之前，我必须：

• 将团队管理角色添加到托管标识的服务主体。
• 将脚本中执行的任务所需的 Graph API 权限分配给服务主体。

查看分配给图 1 中托管标识的权限集时，您看不到添加或删除权限的选项（未显示全屏，但没有可用的选项）。 Azure AD 管理中心表示：“同意此应用程序的功能已被禁用，因为该应用程序不需要同意。” 实际上，这意味着所有权限管理都必须通过 PowerShell 完成。

确保使用的帐户具有 Directory.ReadWrite.All 和 Application.ReadWrite.All 权限（用于更新 Azure AD 和应用程序详细信息）后，我分配的方式如下服务主体的团队管理角色：

# Fetch details of the Teams management app
$TeamsApp = Get-MgServicePrincipal -Filter "AppId eq '48ac35b8-9aa8-4d74-927d-1f4a14a0b239'"  
$AppPermission = $TeamsApp.AppRoles | Where-Object {$_.DisplayName -eq "Application_access"} # Create the payload for the assignment
$AppRoleAssignment = @{
    "PrincipalId" = $ManagedIdentity.Id
    "ResourceId" = $TeamsApp.Id
    "AppRoleId" = $AppPermission.Id }
# Assign the role to the service principal for the managed identity.
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentity.Id -BodyParameter $AppRoleAssignment

之后，我将必要的图形权限分配给服务主体。以下是我添加向频道添加新成员所需的权限的方法：

$GraphApp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'" # Microsoft Graph
$Role = $GraphApp.AppRoles | Where-Object {$_.Value -eq  'ChannelMember.ReadWrite.All'}
$AppRoleAssignment = @{
    "PrincipalId" = $ManagedIdentity.Id
    "ResourceId" = $GraphApp.Id
    "AppRoleId" = $Role.Id }
# Assign the Graph permission
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentity.Id -BodyParameter $AppRoleAssignment

如果您犯了错误并分配了不必要的权限，您可以通过在服务主体持有的集合中查找权限分配的标识符并运行Remove-MgServicePrincipalAppRoleAssignment来删除它。 cmdlet。以下是我删除 TeamWork.Migrate.All 权限的操作。

[Array]$SPPermissions = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentity.Id
$Role = $GraphApp.AppRoles | Where-Object {$_.Value -eq "TeamWork.Migrate.All"}
$Assignment = $SpPermissions | Where-Object {$_.AppRoleId -eq $Role.Id}
Remove-MgServicePrincipalAppRoleAssignment -AppRoleAssignmentId $Assignment.Id -ServicePrincipalId $ManagedIdentity.Id

此时您可能会想到两件事。首先，Microsoft 是否记录了所有这些步骤？其次，为什么托管身份的权限管理过程如此复杂？我的观点是该领域缺乏连贯的文档。微软在不同的地方涵盖了基础知识，但将所有内容整合在一起以使托管身份的权限管理成为一项简单的操作似乎并没有发生。相反，微软将理论付诸实践的任务留给了其他人。

无论如何，在向托管标识添加必要的角色和权限后，当脚本进行身份验证时，Azure AD 生成的访问令牌包含所有权限，脚本可以执行一些实际工作（图 2）。

发布到团队

如上所述，我希望脚本输出频道中新成员的详细信息。出现了两个问题：

1. 我们正在发布到共享频道。访问频道仅限频道会员。托管身份不是频道成员，并且似乎没有办法冒充频道成员。
2. 共享频道不支持连接器，因此无法使用传入的 Webhook 连接器发布消息（除非您决定发布到主机团队中的另一个频道）。

我使用 Azure KeyVault 来存储连接到 PnP 所需的用户凭据和其他信息。将此信息存储在 Azure Key Vault 中可以轻松更改用于发布消息的帐户或目标通道。为了发布该消息，我使用与本文中所解释的代码大致相同的代码来创建一个包含新频道成员详细信息的 HTML 正文部分（图 3）。

一切正常后，我发布了 Runbook 并将其添加到计划中，以便 Azure 自动化每周运行该脚本。几周以来，剧本进展顺利，所以我称其为成功。您可以从 GitHub 下载完整的脚本。

经验教训和结论

即使有一些粗糙的边缘，Microsoft Graph API、Azure 自动化和托管标识的组合也是卸载资源密集型脚本（例如扫描所有租户成员以生成报告的脚本）处理的好方法。如果用于 Microsoft 365 管理的所有主线 PowerShell 模块都比现在更彻底、更优雅地支持托管身份，情况会更好。这可能会及时到来。

Active Directory 的网络安全风险管理

了解如何通过这些网络安全风险管理解决方案预防 AD 攻击并从中恢复。