CBA和ExO

既然基本身份验证已被禁用，请了解有关 Exchange Online PowerShell 基于证书的身份验证的详细信息。

PowerShell 和安全性并不是“夜间航行的两艘船”，而应该在本地或云中执行脚本的管理员的心中交织在一起。通过 PowerShell 连接和使用 Exchange Online 也没有什么不同。在本文中，我们将探讨管理员必须进行的一些更改，以便在禁用基本身份验证后与 PowerShell 进行连接。我们将回顾各种连接以及与之相关的安全性，最后介绍 Exchange Online PowerShell 的基于证书的身份验证。

凭证存储选项

连接到目标系统时的第一道防线是如何将凭据传递到该系统。使用 PowerShell，我们有很多选择，管理员在使用他们支持的系统时可能至少使用了以下三种或更多方法：

清除文本： 在脚本中[不好，不要这样做] - 例如：Uber Hack
密码文件：本地计算机上的加密文件[比明文稍好，如果未设置文件权限则不好]
本地凭据： PowerShell Secrets 模块[比密码文件更安全，加密]
证书：使用自签名或第三方证书作为身份证明（需要注册 Azure 应用程序）[最安全]
Azure 自动化凭据： 需要在 Azure 中进行一些配置[最安全]
Azure Key Vault：凭据存储在 Azure 密钥中Vault（需要 Azure 资源）[最安全]

更改身份验证

截至 2022 年 10 月 1 日，管理员可以使用 New-PSSession cmdlet（以及一些其他条件）通过基本身份验证连接到 Exchange Online。既然微软已经关闭了这扇门并且不再允许这些连接，我们需要考虑其他选择。然后在 12 月 15 日，微软再次宣布了针对 Exchange Online PowerShell 连接的另一项更改，其中 RPS（远程 PowerShell）也被阻止（截至 2023 年 7 月 - 微软公告和更新）

这个改变消除了什么？

• 使用 New-PSSession 建立的任何连接
• Exchange Online PowerShell 模块 v1 或 v2
• 使用 -UseRPSSession 参数的任何 Exchange Online PowerShell 模块

替代品是什么？

一切并没有丢失，因为 Microsoft 提供了一种使用 PowerShell 连接到 Exchange Online 的方法。其中包括使用 Exchange Online PowerShell 模块 v3（无 -UseRPSSession 参数）或使用基于证书的身份验证 (CBA)。在本文中，我们将探讨 CBA 的使用，因为它可用于交互式运行脚本以及安全运行自动化脚本来执行任务，无需用户干预。

如何设立CBA

为 Exchange Online 设置基于证书的身份验证只需要几个组件。我们需要满足一些先决条件才能成功连接 PowerShell：

• 1. 在 Azure AD 中注册应用程序
• 2.为应用程序分配API权限
• 3. 创建自签名证书
• 4. 将证书与Azure App关联
• 5. 分配 Azure AD 角色

注册申请

首先，直接浏览到Azure 租户中的应用程序注册页面：
https://portal.azure.com/#view/Microsoft_AAD_RegisteredApps/ApplicationsListBlade

到达此处后，单击“新注册按钮”：

(1) 添加应用程序的名称，(2) 保留默认帐户类型（大多数情况），(3) 从下拉列表中选择 Web，(4) 输入域这个重定向。单击“注册”，我们就有了一个可与 PowerShell 一起使用的应用。

为应用程序分配 API 权限

这部分有点棘手，但 Microsoft 在其文档中提供了很好的说明。步骤归结为：

1. 单击您刚刚在租户中创建的应用程序，根据 Microsoft 对应用程序清单代码进行此步骤中记录的修改：

访问需要 JSON（根据 Microsoft 文档）

2. 然后转到应用程序的“API 权限”并 (1) 授予同意并 (2) 添加此 Exchange 权限：

Azure 注册应用程序中的 API 权限。

创建自签名证书

接下来，我们需要用于验证运行 PowerShell 脚本的控制台与 Exchange Online 之间的连接的证书。我们可以使用 PowerShell 生成自签名证书。例如，具有 PowerShellGeek.com 域的组织需要创建证书，这一点很重要，我们将需要该证书用于应用程序和证书：

生成证书

$NewCertificate = New-SelfSignedCertificate -DnsName "PowerShellGeek.com" -CertStoreLocation "cert:\CurrentUser\My" -NotAfter (Get-Date).AddYears(1) -KeySpec KeyExchange

生成 PFX 版本的证书

$NewCertificate | Export-PfxCertificate -FilePath ExOConnection.pfx -Password (Get-Credential).password

注意： ScriptRunner 团队的 Markus 也在博客文章《如何使用 PowerShell 创建 PFX 文件？》中讨论了这一点。

生成 CER 版本的证书

$NewCertificate | Export-Certificate -FilePath c:\ExOConnection.cer 

请注意，上述凭据提示的用户名并未使用，但我们必须输入一些内容来至少捕获密码。

使用 PowerShell 创建的两个文件，供稍后在该过程中使用。

将证书添加到 Azure 应用程序

现在我们有了证书，我们可以将其添加到我们之前创建的 Azure 应用程序中。浏览回 Azure 门户，然后浏览到“应用注册”：

找到您在上一步中创建的应用程序并将其打开。然后单击“证书和机密”。

Azure 应用程序的证书

单击“上传证书”并选择使用 PowerShell 创建的证书：

请确保在此过程中的某个时刻获取证书的指纹，因为连接到 Exchange Online PS 需要它。在此示例中，证书指纹为：AE20B242AE58AA3ABED4D57C22253E2F7572B404

注意： 确保使用适当的 NTFS 权限保护生成的证书文件，以确保它不会成为安全 PowerShell 通信中最薄弱的环节。

分配 Azure AD 角色

该过程的最后一部分现在是为 Azure AD 中的各种角色授予对此 Azure 应用程序的访问权限，这将允许分配了这些角色的用户使用正确的权限与 PowerShell 进行连接。这是在 Azure AD 门户 (https://aad.portal.azure.com) 中完成的。在此示例中，我们将角色分配给“全局管理员”，但也可以轻松地将其分配给“Exchange 服务管理员”角色。

点击“添加分配”，搜索已创建的应用程序，选择并点击“添加”以授予此用户权限。

为 Azure AD 角色组添加分配

如何与CBA建立联系

一旦我们拥有了与应用程序关联的证书、API 权限和证书，我们现在就可以使用 ExO PS v3 进行连接。

下载 ExO v3 的 PowerShell

Install-Module ExchangeOnlineManagement

在 PowerShell 中加载模块

Import-Module ExchangeOnlineManagement

连接到 Exchange Online PowerShell

为了使用 CBA 与 PowerShell 正确连接，我们需要一些组件：

(A) 证书过程中的指纹：

如前文所述，我们需要创建并与 Azure 应用程序关联的证书的指纹：

AE20B242AE58AA3ABED4D57C22253E2F7572B404

(B) 我们还需要创建的 Azure 应用程序的应用程序 ID：

在哪里可以找到 PowerShell 的 Azure 应用 ID

一旦我们有了这两个，我们现在就可以使用证书连接到 Exchange Online：

Connect-ExchangeOnline -CertificateThumbPrint <Certificate Thumbprint> -AppID <App ID> -Organization "<tenant>.onmicrosoft.com"

Connect-ExchangeOnline -CertificateThumbPrint AE20B242AE58AA3ABED4D57C22253E2F7572B404 -AppID 279fcdda-c0b9-4f99-b2d7-c99dd2376d3c -Organization tenantdomain.onmicrosoft.com

现在我们已使用证书连接到 Exchange Online

为什么要使用CBA？

既然我们知道如何设置以及如何使用它，为什么还要费劲去使用 CBA呢？ ExO v3 模块无需 CBA 即可连接到 Exchange Online。我们可以从安全文本文件、Secrets PowerShell 模块提供凭据或手动输入凭据。为什么要使用CBA？ CBA 提供更安全的连接，不会让您的登录凭据（登录名和密码）容易受到攻击，并且被认为使用起来更安全。 CBA 还简化了您的身份验证并使脚本自动化变得更加容易。

哪些其他工作负载可以使用 CBA？

• 安全与合规中心 PowerShell
• 微软团队
• SharePoint PNP
• ETC。

每个工作负载都应该有一个单独的应用程序，以便可以按最小权限分配它们。否则，如果通过一个应用程序提供所有访问权限，则分配该应用程序的用户可能拥有比执行其工作所需的权限更大的权限，从而产生安全问题。

（左）一个 Azure 应用映射到多个工作负载
（右）一个 Azure 应用仅映射到一个工作负载

结论

基于证书的身份验证只是 Exchange Online 的一种身份验证方法，但它提供了比涉及管理员登录名和密码（明文、安全文件或其他方式）的连接更安全的连接。管理员应该为 Exchange Online 切换到 CBA，因为设置简单、方便、安全，并且它可以在自动化脚本以及其他工作负载（例如安全与合规中心、SharePoint PnP 和 Teams）中使用。

不要像 Uber 在脚本文件中使用明文密码那样被黑客攻击！