为 Azure 信息保护准备用户和组

项目
04/12/2024

注意

你是否想要了解 Microsoft Purview 信息保护（以前称为 Microsoft 信息保护 (MIP)）方面的信息？

Azure 信息保护加载项已停用，并替换为 Microsoft 365 应用和服务中内置的标签。详细了解其他 Azure 信息保护组件的支持状态。

新的 Microsoft 信息保护客户端（不含加载项）目前为预览版，并计划正式发布。

在为组织部署 Azure 信息保护之前，请确保用户和组在组织租户的 Microsoft Entra ID 中具有帐户。

创建这些用户和组的帐户有多种方法，其中包括：

在 Microsoft 365 管理中心创建用户，在 Exchange Online 管理中心创建组。
在 Azure 门户中创建用户和组。
使用 Azure AD PowerShell 和 Exchange Online cmdlet 创建用户和组。
在本地 Active Directory 中创建用户和组，并将其同步到 Microsoft Entra ID。
在其他目录中创建用户和组，并将其同步到 Microsoft Entra ID。

使用此列表中的前三种方法创建用户和组时，它们将在 Microsoft Entra ID 中自动创建，并且 Azure 信息保护可以直接使用这些帐户（但存在一个例外）。然而，许多企业网络使用本地目录来创建和管理用户和组。 Azure 信息保护不能直接使用这些帐户；你必须将它们同步到 Microsoft Entra ID。

上一段落中提到的例外情况是，可以为 Exchange Online 创建的动态通讯组列表。与静态通讯组列表不同，这些组不会复制到 Microsoft Entra ID，因此不能由 Azure 信息保护使用。

Azure 信息保护如何使用用户和组

Azure 信息保护使用用户和组的方式有三种：

配置 Azure 信息保护策略时，用于将标签分配给用户，以便将标签应用于文档和电子邮件。只有管理员可以选择这些用户和组：

默认的 Azure 信息保护策略将自动分配给租户的 Microsoft Entra ID 中的所有用户。但是，也可以使用作用域策略为指定用户或组分配其他标签。

在使用 Azure Rights Management 服务保护文档和电子邮件时，用于分配使用权限和访问控制权限。管理员和用户均可选择这些用户和组：

使用权限可决定用户是否能够打开文档或电子邮件以及如何使用它们。例如，用户是只能阅读、可以阅读并打印，还是可以阅读并编辑。
访问控制包括到期日期以及是否需要连接到 Internet 进行访问。

用于配置 Azure Rights Management 服务以支持特定方案，因此只有管理员可以选择这些组。示例包括配置下列各项：

超级用户，以便指定的服务或人员可以打开加密的内容（如果电子数据展示或数据恢复需要）。
Azure Rights Management 服务的委派管理。
支持分阶段部署的加入控制机制。

用户帐户 Azure 信息保护要求

用于分配标签：

Microsoft Entra ID 中的所有用户帐户都可用于配置向用户分配其他标签的作用域内策略。

用于分配使用权限和访问控制，以及配置 Azure Rights Management 服务：

若要为用户授权，请使用 Microsoft Entra ID 中的两个属性：proxyAddresses 和 userPrincipalName。
Microsoft Entra proxyAddresses 属性存储帐户的所有电子邮件地址，并能以不同的方式填充。例如，Microsoft 365 中具有 Exchange Online 邮箱的用户自动具有存储在此属性中的电子邮件地址。如果为 Microsoft 365 用户分配了备用电子邮件地址，那么该地址也会保存在此属性中。它也可以由从本地帐户同步的电子邮件地址填充。

如果已将域添加到租户（“已验证的域”），Azure 信息保护可以使用此 Microsoft Entra proxyAddresses 属性中的任何值。有关验证域的详细信息，请参阅：
- 对于 Microsoft Entra ID：将自定义域名添加到 Microsoft Entra ID
- 对于 Office 365：将域添加到 Office 365
仅当租户中的帐户在 Microsoft Entra proxyAddresses 属性中没有值时，才会使用 Microsoft Entra userPrincipalName 属性。例如，可以在 Azure 门户中创建用户，或者创建没有邮箱的 Microsoft 365 用户。

向外部用户分配使用权限和访问控制权限

除了对你的租户中的用户使用 Microsoft Entra proxyAddresses 和 Microsoft Entra userPrincipalName 之外，Azure 信息保护还以同样的方式使用这些属性来为其他租户中的用户授权。

其他授权方法：

对于不在 Microsoft Entra ID 中的电子邮件地址，Azure 信息保护可以在使用 Microsoft 帐户对其进行了身份验证时为这些电子邮件地址授权。但是，并非所有应用程序都可以在使用 Microsoft 帐户进行身份验证时打开受保护的内容。详细信息
使用具有新功能的 Office 365 邮件加密向在 Microsoft Entra ID 中没有帐户的用户发送电子邮件时，会先通过社交标识提供者使用联合身份验证或使用一次性密码对此用户进行身份验证。然后使用受保护电子邮件中指定的电子邮件地址向此用户授权。

组帐户 Azure 信息保护要求

用于分配标签：

若要配置将其他标签分配给组成员的作用域内策略，可以使用 Microsoft Entra ID 中的任何类型的组，只要该组具有一个电子邮件地址，其中包含用户租户的已验证域。具有电子邮件地址的组通常称为启用邮件的组。

例如，可使用启用邮件的安全组、静态通讯组和 Microsoft 365 组。不能使用安全组（动态或静态），因为该组类型没有电子邮件地址。也不能使用 Exchange Online 中的动态通讯组列表，因为此组不会复制到 Microsoft Entra ID。

对于分配使用权限和访问控制权限：

可以使用 Microsoft Entra ID 中的任何类型的组，只要该组具有一个电子邮件地址，其中包含用户租户的已验证域。具有电子邮件地址的组通常称为启用邮件的组。

对于配置 Azure Rights Management 服务：

可以使用 Microsoft Entra ID 中具有租户内已验证域中的电子邮件地址的任何类型的组，但有一个例外。即，在配置加入控制机制以使用某个组时，该组必须是租户的 Microsoft Entra ID 中的一个安全组。
可以从租户中的已验证域使用 Azure AD 中的任何组（无论是否具有电子邮件地址），以进行 Azure Rights Management 服务的委派管理。

向外部组分配使用权限和访问控制权限

除了为你的租户中的组使用 Microsoft Entra proxyAddresses 之外，Azure 信息保护还以同样的方式使用此属性来为其他租户中的组授权。

将 Active Directory 本地帐户用于 Azure 信息保护

若要将本地管理的帐户用于 Azure 信息保护，必须将其同步到 Microsoft Entra ID。为方便部署，我们建议使用 Microsoft Entra ID Connect。但是，可以使用可实现相同结果的任何目录同步方法。

同步帐户时，无需同步所有属性。有关必须同步的属性列表，请参阅 Microsoft Entra ID 文档中的 Azure RMS 部分。

从 Azure Rights Management 的属性列表中可以看到，对于用户而言，需要本地 AD属性 mail、proxyAddresses 和 userPrincipalName 进行同步。 mail 和 proxyAddresses 的值会同步到 Microsoft Entra proxyAddresses 属性。有关详细信息，请参阅如何在 Microsoft Entra ID 中填充 proxyAddresses 属性

确认已准备好用户和组以使用 Azure 信息保护

可以使用 Azure AD PowerShell 确认用户和组可用于 Azure 信息保护。此外，还可以使用 PowerShell 确认可用于向他们授权的值。

注意

自 2024 年 3 月 30 日起，Azure AD 和 MSOnline PowerShell 模块已弃用。若要了解详细信息，请阅读有关弃用的更新。在此日期之后，对这些模块的支持仅限于到 Microsoft Graph PowerShell SDK 的迁移帮助和安全性修复。弃用的模块将持续运行至 2025 年 3 月 30 日。

我们建议迁移到 Microsoft Graph PowerShell，以便与 Microsoft Entra ID（以前称为 Azure AD）进行交互。有关常见迁移问题，请参阅迁移常见问题解答。 注意：2024 年 6 月 30 日之后，MSOnline 版本 1.0.x 可能会遇到中断。

例如，在 PowerShell 会话中使用 Microsoft Entra ID 的 V1 PowerShell 模块 MSOnline，首先连接到服务并提供全局管理员凭据：

Connect-MsolService

注意：如果此命令不起作用，可以运行 Install-Module MSOnline 安装 MSOnline 模块。

接下来，配置 PowerShell 会话，以便它不会截断该值：

$Formatenumerationlimit =-1

确认已准备好用户帐户用于 Azure 信息保护

若要确认用户帐户，请运行以下命令：

Get-Msoluser | select DisplayName, UserPrincipalName, ProxyAddresses

首先查看并确保显示要用于 Azure 信息保护的用户。

然后查看是否填充了 ProxyAddresses 列。如果是，可使用此列中的电子邮件值授权用户以使用 Azure 信息保护。

如果 ProxyAddresses 列未填充，则使用 UserPrincipalName 中的值授权用户以用于 Azure Rights Management 服务。

例如：

显示名称	UserPrincipalName	ProxyAddresses
Jagannath Reddy	jagannathreddy@contoso.com	{}
Ankur Roy	ankurroy@contoso.com	{SMTP:ankur.roy@contoso.com, smtp: ankur.roy@onmicrosoft.contoso.com}

在此示例中：

Jagannath Reddy 的用户帐户将通过 jagannathreddy@contoso.com 进行授权。
Ankur Roy 的用户帐户将使用 ankur.roy@contoso.com 和 ankur.roy@onmicrosoft.contoso.com 进行授权，而不是 ankurroy@contoso.com。

在大多数情况下，UserPrincipalName 的值匹配 ProxyAddresses 字段中的一个值。这是建议的配置，但如果无法更改 UPN 以匹配电子邮件地址，则必须执行以下步骤：

如果 UPN 值中的域名是 Microsoft Entra 租户的已验证域，请添加该 UPN 值作为 Microsoft Entra ID 中的另一个电子邮件地址，以便可以立即使用该 UPN 值为此用户帐户授权，使其可用于 Azure 信息保护。

如果 UPN 值中的域名不是租户的已验证域，则不能用于 Azure 信息保护。但是，当组电子邮件地址使用已验证域名时，用户仍然可以被授权为组成员。
如果 UPN 不可路由（例如，ankurroy@contoso.local），请为用户配置备用登录 ID，并指导他们使用此备用登录方式登录 Office。还必须为 Office 设置注册表项。

为用户更改 PIN 后，业务连续性将中断至少 24 小时或直到 UPN 更改正确反映在系统中为止。

有关详细信息，请参阅配置备用登录 ID 和 Office 应用程序定期提示输入 SharePoint、OneDrive 和 Lync Online 的凭据。

提示

可以使用 Export-Csv cmdlet 将结果导出到电子表格，以便于进行管理，例如搜索和批量编辑以进行导入。

例如：Get-MsolGroup | select DisplayName, ProxyAddresses | Export-Csv -Path UserAccounts.csv

注意

为用户更改 PIN 后，业务连续性将中断至少 24 小时或直到 UPN 更改正确反映在系统中为止。

确认已准备好组帐户用于 Azure 信息保护

若要确认组帐户，请使用以下命令：

Get-MsolGroup | select DisplayName, ProxyAddresses

确保显示要用于 Azure 信息保护的组。对于显示的组，可以使用 ProxyAddresses 列中的电子邮件地址授权组成员使用 Azure Rights Management 服务。

然后查看组是否包含要用于 Azure 信息保护的用户（或其他组）。可以使用 PowerShell 来执行此操作（例如，Get-MsolGroupMember），或使用管理门户。

对于使用安全组的两个 Azure Rights Management 服务配置方案，可以使用以下 PowerShell 命令查找对象 ID 并显示可用于标识这些组的名称。还可以使用 Azure 门户查找这些组，复制对象 ID 的值并显示名称：

Get-MsolGroup | where {$_.GroupType -eq "Security"}

电子邮件地址更改情况下的 Azure 信息保护注意事项

如果更改用户或组的电子邮件地址，我们建议向用户或组添加旧电子邮件地址作为第二个电子邮件地址（也称为代理地址、别名或备用电子邮件地址）。执行此操作后，旧电子邮件地址将添加到 Microsoft Entra proxyAddresses 属性。此帐户管理功能可确保在使用旧电子邮件地址时保存的任何使用权限或其他配置的业务连续性。

如果无法执行此操作，则具有新电子邮件地址的用户或组可能无法访问先前受旧电子邮件地址保护的文档和电子邮件。此情况下，必须重复保护配置以保护新的电子邮件地址。例如，如果向用户或组授予了模板或标签的使用权限，则他们可使用与向旧电子邮件地址授予的相同使用权限编辑这些模板或标签，还可按相同权限指定新的电子邮件地址。

请注意，一个组更改其电子邮件地址的情况很少见，如果为某个组而不是单个用户分配使用权限，则用户的电子邮件地址是否更改无关紧要。在这种情况下，使用权限分配给组电子邮件地址，而不是单个用户电子邮件地址。这是管理员在配置可保护文档和电子邮件的使用权限时最有可能采用的方法，同时也是建议的方法。但是，用户通常更有可能为单个用户分配自定义权限。由于无法随时了解用户帐户或组是否已用于授予访问权限，因此，始终添加旧电子邮件地址作为第二个电子邮件地址是最安全的做法。

Azure 信息保护缓存组成员身份

出于性能原因，组成员身份由 Azure 信息保护缓存。这意味着，Azure 信息保护使用这些组时，对 Microsoft Entra ID 中的组成员身份所做的任何更改最多可能需要三小时才能生效，并且此时间段可能会发生变化。

请注意，此延迟归因于将组用于 Azure Rights Management 时执行的任何更改或测试，例如分配使用权限或配置 Azure Rights Management 服务。

后续步骤

在已确认可将 Azure 信息保护用于你的用户和组，并已准备好开始保护文档和电子邮件后，请检查是否需要激活 Azure Rights Management 服务。必须首先激活此服务才能开始保护你组织的文档和电子邮件：

从 2018 年 2 月开始：如果包含 Azure Rights Management 或 Azure 信息保护的订阅是在当月或之后获取的，将自动为你激活此服务。
如果你的订阅是在 2018 年 2 月之前获取的：必须自己激活此服务。

有关详细信息（包括如何检查激活状态），请参阅从 Azure 信息保护激活保护服务。