迁移第 2 阶段 – AD RMS 的服务器端配置

项目
12/26/2023

对于“从 AD RMS 迁移到 Azure 信息保护”的第 2 阶段，使用以下信息。这些过程涵盖从 AD RMS 迁移到 Azure 信息保护的步骤 4 至步骤 6。

步骤 4：从 AD RMS 导出配置数据并将其导入 Azure 信息保护

该步骤分为两个过程：

通过将受信任的发布域 (TPD) 导出到 .xml 文件，从 AD RMS 导出配置数据。对于所有迁移，此过程都是相同的。
将配置数据导入 Azure 信息保护。此步骤可以采用不同的过程，具体取决于当前的 AD RMS 部署配置和 Azure RMS 租户密钥的首选拓扑。

从 AD RMS 导出配置数据

在所有 AD RMS 群集上，针对具有组织受保护内容的所有受信任的发布域，执行以下过程。无需在仅限许可的群集上运行此过程。

导出配置数据（受信任的发布域信息）

以具有 AD RMS 管理权限的用户身份登录 AD RMS 群集。
在 AD RMS 管理控制台 (Active Directory Rights Management Services)，展开 AD RMS 群集名称，展开“信任策略”，然后单击“受信任的发布域”。
在结果窗格中，选择受信任的发布域，然后在“操作”窗格中单击“导出受信任的发布域”。
在“导出受信任的发布域”对话框中：
- 单击“另存为”并保存到选择的路径和文件名称。确保将 .xml 指定为文件扩展名（不会自动追加）。
- 指定并确认强密码。记住此密码，因为稍后在将配置数据导入 Azure 信息保护时需要用到。
- 在 RMS 版本 1.0 中，请勿选中保存受信任的域文件的复选框。

导出所有受信任的发布域后，便可以启动将此数据导入到 Azure 信息保护的过程了。

请注意，受信任的发布域包括服务器许可方证书 (SLC) 密钥，用于解密以前受保护的文件，因此务必导出（稍后导入到 Azure）所有受信任的发布域，而不仅仅是当前处于活动状态的域。

例如，如果将 AD RMS 服务器从加密模式 1 升级到加密模式 2，将有多个受信任的发布域。如果不导出并导入包含使用加密模式 1 的存档密钥受信任的发布域，则迁移结束时，用户将无法打开使用加密模式 1 密钥保护的内容。

将配置数据导入 Azure 信息保护策略

此步骤的具体过程取决于当前的 AD RMS 部署配置和 Azure 信息保护租户密钥的首选拓扑。

当前的 AD RMS 部署正在对服务器许可方证书 (SLC) 密钥使用以下配置之一：

AD RMS 数据库中的密码保护。这是默认配置。
通过使用 nCipher 硬件安全模块 (HSM) 进行 HSM 保护。
通过使用来自 nCipher 之外的供应商的硬件安全模块 (HSM) 进行 HSM 保护。
受外部加密提供程序保护的密码。

注意

有关将硬件安全模块与 AD RMS 结合使用的详细信息，请参阅将 AD RMS 与硬件安全模块配合使用。

两个 Azure 信息保护租户密钥拓扑选项包括：Microsoft 管理租户密钥（Microsoft 托管），或者在 Azure Key Vault 中你管理租户密钥（客户托管）。当你管理自己的 Azure 信息保护租户密钥时，它有时被称为“创建自己的密钥”(BYOK)。有关详细信息，请参阅规划和实现 Azure 信息保护租户密钥文章。

使用下表确定要用于迁移的过程。

当前的 AD RMS 部署	选择 Azure 信息保护租户密钥拓扑	迁移说明
AD RMS 数据库中的密码保护	由 Microsoft 管理	请参阅此表后面的“受软件保护的密钥到受软件保护的密钥”迁移过程。这是最简单的迁移路径，只需将配置数据传输到 Azure 信息保护即可。
通过使用 nCipher nShield 硬件安全模块 (HSM) 进行 HSM 保护	由客户管理 (BYOK)	请参阅此表后面的“受 HSM 保护的密钥到受 HSM 保护的密钥”迁移过程。这需要 Azure Key Vault BYOK 工具集并执行三个步骤：先将密钥从本地 HSM 传输到 Azure Key Vault HSM，然后授权 Azure 信息保护中的 Azure Rights Management Service 使用租户密钥，最后将配置数据传输到 Azure 信息保护。
AD RMS 数据库中的密码保护	由客户管理 (BYOK)	请参阅此表后面的“受软件保护的密钥到受 HSM 保护的密钥”迁移过程。这需要 Azure Key Vault BYOK 工具集并执行四个步骤：先提取软件密钥并将其导入本地 HSM，然后将密钥从本地 HSM 传输到 Azure 信息保护 HSM，接下来将密钥保管库数据传输到 Azure 信息保护，最后将配置数据传输到 Azure 信息保护。
通过使用来自 nCipher 之外的供应商的硬件安全模块 (HSM) 进行 HSM 保护	由客户管理 (BYOK)	与 HSM 供应商联系以获取有关如何将密钥从此 HSM 传输到 nCipher nShield 硬件安全模块 (HSM) 的说明。然后按照此表后面的“受 HSM 保护的密钥到受 HSM 保护的密钥”的迁移过程中的说明进行操作。
使用外部加密提供程序保护的密码	由客户管理 (BYOK)	与加密提供程序的供应商联系以获取有关如何将密钥传输到 nCipher nShield 硬件安全模块 (HSM) 的说明。然后按照此表后面的“受 HSM 保护的密钥到受 HSM 保护的密钥”的迁移过程中的说明进行操作。

如果具有无法导出的受 HSM 保护的密钥，则仍可以通过将 AD RMS 群集配置为只读模式来迁移到 Azure 信息保护。在此模式下，仍可打开以前受保护的内容，但新受保护的内容使用由你 (BYOK) 或 Microsoft 托管的新租户密钥。有关详细信息，请参阅支持从 AD RMS 迁移到 Azure RMS 的 Office 可用更新。

在开始这些密钥迁移过程之前，确保在导出受信任的发布域时访问之前创建的 .xml 文件。例如，这些文件可能会保存到 U 盘中，你可以将其从 AD RMS 服务器移动到连接到 Internet 的工作站。

注意

无论如何存储这些文件，使用安全最佳做法来保护这些文件，因为此数据包括私钥。

要完成步骤 4，选择迁移路径的说明：

步骤 5：激活 Azure Rights Management Service

打开 PowerShell 会话并运行以下命令：

连接到 Azure Rights Management Service，并在出现提示时指定全局管理员的凭证：
```
Connect-AipService
```
激活 Azure Rights Management Service：
```
Enable-AipService
```

如果 Azure 信息保护租户已激活，该怎么办？ 如果已为组织激活 Azure Rights Management Service，并且已创建要在迁移后使用的自定义模板，则必须导出并导入这些模板。下一步将介绍此过程。

步骤 6：配置导入的模板

由于导入模板的默认状态为“已存档”，因此，如果希望用户能够将这些模板与 Azure Rights Management Service 结合使用，则必须将此状态更改为“已发布”。

从 AD RMS 导入的模板外观和行为与可在 Azure 门户中创建的自定义模板一样。要更改要发布的导入模板，以便用户可以查看并从应用程序中选择它们，请参阅配置和管理 Azure 信息保护的模板。

除了发布新导入的模板之外，在继续迁移之前，可能需要对模板进行两项重要更改。要在迁移过程中为用户提供更一致的体验，不要对导入的模板进行其他更改，也不要发布 Azure 信息保护附带的两个默认模板，或在此时创建新模板。而是等待迁移过程完成并取消设置的 AD RMS 服务器。

可能需要为此步骤进行的模板更改：

如果在迁移之前创建了 Azure 信息保护自定义模板，则必须手动导出和导入这些模板。
如果 AD RMS 中的模板使用了“ANYONE”组，则可能需要手动添加用户或组。

在 AD RMS 中，ANYONE 组向通过本地 Active Directory 进行身份验证的所有用户授予权限，Azure 信息保护不支持此组。最接近的等效项是为 Microsoft Entra 租户中的所有用户自动创建的组。如果将 ANYONE 组用于 AD RMS 模板，则可能需要添加用户和要向其授予的权限。

如果在迁移前创建了自定义模板，则需要执行以下步骤

如果在迁移之前或在激活 Azure Rights Management Service 之前或之后创建了自定义模板，则即使模板设置为“已发布”，迁移后用户也无法使用模板。要让这些模板可供用户使用，必须首先执行以下操作：

通过运行 Get-AipServiceTemplate 识别这些模板并记下它们的模板 ID。
通过使用 Azure RMS PowerShell cmdlet Export-AipServiceTemplate 导出模板。
通过使用 Azure RMS PowerShell cmdlet Import-AipServiceTemplate 导入模板。

然后，可以像迁移后创建的任何其他模板一样发布或存档这些模板。

如果 AD RMS 中的模板使用了“ANYONE”组，则需要执行以下步骤

如果 AD RMS 中的模板使用 ANYONE 组，Azure 信息保护中的最近等效组名为 AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@<名称>.onmicrosoft.com。例如，对于 Contoso，此组可能如下所示：AllStaff-7184AB3F-CCD1-46F3-8233-3E09E9CF0E66@contoso.onmicrosoft.com。此组包含 Microsoft Entra 租户中的所有用户。

在 Azure 门户中管理模板和标签时，此组在 Microsoft Entra ID 中显示为租户的域名。例如，对于 Contoso，此组可能如下所示：contoso.onmicrosoft.com。要添加此组，该选项显示“添加 <组织名称> - 所有成员”。

如果不确定 AD RMS 模板是否包含 ANYONE 组，则可以使用以下示例 Windows PowerShell 脚本来标识这些模板。有关将 Windows PowerShell 用于 AD RMS 的详细信息，请参阅使用 Windows PowerShell 管理 AD RMS。

将这些模板转换为 Azure 门户中的标签时，可以轻松地将外部用户添加到模板。然后，在“添加权限”窗格中，选择“输入详细信息”以手动为这些用户指定电子邮件地址。

有关此配置的详细信息，请参阅如何配置 Rights Management 保护的标签。

用于标识包含 ANYONE 组的 AD RMS 模板的示例 Windows PowerShell 脚本

本部分包含示例脚本，以帮助识别定义了 ANYONE 组的任何 AD RMS 模板，如上一节中所述。

免责声明：此示例脚本在任何 Microsoft 标准支持计划或服务下均不受支持。此示例脚本按原样提供，不提供任何形式的保证。

import-module adrmsadmin

New-PSDrive -Name MyRmsAdmin -PsProvider AdRmsAdmin -Root https://localhost -Force

$ListofTemplates=dir MyRmsAdmin:\RightsPolicyTemplate

foreach($Template in $ListofTemplates)
{
                $templateID=$Template.id

                $rights = dir MyRmsAdmin:\RightsPolicyTemplate\$Templateid\userright

     $templateName=$Template.DefaultDisplayName

        if ($rights.usergroupname -eq "anyone")

                         {
                           $templateName = $Template.defaultdisplayname

                           write-host "Template " -NoNewline

                           write-host -NoNewline $templateName -ForegroundColor Red

                           write-host " contains rights for " -NoNewline

                           write-host ANYONE  -ForegroundColor Red
                         }
 }
Remove-PSDrive MyRmsAdmin -force

后续步骤

转到第 3 阶段 – 客户端配置。

通过