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

适用于:Azure信息保护、Office 365

相关:AIP 统一标签客户端和经典客户端

注意

为了提供统一且简化的客户体验,Azure 门户中的Azure信息保护经典客户端和标签管理在2021年 3 月 31 日已弃用。 不再提供对经典客户端的进一步支持,并且将不再发布维护版本。

经典客户端将于 2022 年 3 月 31 日正式停用并停止运行。

所有当前的 Azure 信息保护经典客户端客户必须迁移到统一Microsoft 信息保护平台,并升级到统一的标签客户端。 在迁移博客 中了解更多信息

为组织部署 Azure 信息保护之前,请确保为组织的租户Azure AD用户和组的帐户。

为用户和组创建这些帐户的方法不同,包括:

  • 在管理中心Microsoft 365 管理中心用户和组Exchange Online组。

  • 在 Azure 门户中创建用户和组。

  • 使用 PowerShell 和 Azure AD cmdlet 创建用户Exchange Online组。

  • 在本地 Active Directory 中创建用户和组,将其同步到Azure AD。

  • 在另一个目录中创建用户和组,将其同步到Azure AD。

使用此列表中的前三种方法创建用户和组时,其中一个例外是在 Azure AD 中自动创建的,Azure 信息保护可以直接使用这些帐户。 但是,许多企业网络使用本地目录来创建和管理用户和组。 Azure 信息保护不能直接使用这些帐户;必须将其同步到Azure AD。

上一段落中提到的例外是动态通讯组列表,你可以为Exchange Online。 与静态通讯组列表不同,这些组不会复制到Azure AD因此无法由 Azure 信息保护使用。

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

使用 Azure 信息保护的用户和组有三种方案:

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

  • 默认 Azure 信息保护策略会自动分配给租户租户中Azure AD。 但是,您也可以使用作用域策略将其他标签分配给指定的用户或组。

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

  • 使用权限确定用户是否可以打开文档或电子邮件,以及如何使用该文档或电子邮件。 例如,他们是否可以仅读取、读取和打印它,或读取和编辑它。

  • 访问控制包括到期日期以及是否需要连接到 Internet 才能访问。

若要配置 Azure Rights Management 服务以支持 特定方案,因此仅管理员选择这些组。 示例包括配置以下内容:

  • 超级用户,以便指定的服务或人员可以打开加密内容(如果需要进行电子数据展示或数据恢复)。

  • Azure Rights Management 服务的委派管理。

  • 载入控件以支持分阶段部署。

用户帐户的 Azure 信息保护要求

分配标签:

  • 所有用户帐户Azure AD配置范围策略,以向用户分配其他标签。

分配使用权限和访问控制,以及配置 Azure Rights Management 服务:

  • 若要授权用户,使用 Azure AD两个属性:proxyAddressesuserPrincipalName。

  • Azure AD proxyAddresses属性存储帐户的所有电子邮件地址,并且可以通过不同方式填充。 例如,Microsoft 365邮箱的用户Exchange Online自动具有存储在此属性中的电子邮件地址。 如果为用户分配备用电子邮件地址Microsoft 365,也会保存在此属性中。 它还可以通过从本地帐户同步的电子邮件地址填充。

    Azure 信息保护可以使用此 Azure AD proxyAddresses 属性中的任意值,但 ("已验证的域") 。 有关验证域的信息:

  • 只有在Azure AD proxyAddresses 属性中没有值时,才使用 Azure AD userPrincipal Azure AD Name属性。 例如,在 Azure 门户中创建用户,或为Microsoft 365邮箱的用户创建用户。

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

除了对租户中的用户使用 Azure AD proxyAddresses 和 Azure AD userPrincipalName 之外,Azure 信息保护还以相同的方式使用这些属性来授权其他租户中的用户。

其他授权方法:

  • 对于不在门户中的电子邮件地址Azure AD,使用 Microsoft 帐户进行身份验证时,Azure 信息保护可以授权这些地址。 但是,并非所有应用程序都可以在 Microsoft 帐户用于身份验证时打开受保护的内容。 详细信息

  • 将 Office 365 邮件加密 与新功能一起发送给在 Azure AD 中没有帐户的用户时,首先使用与社交标识提供者联合身份验证或一次密码对用户进行身份验证。 然后,受保护电子邮件中指定的电子邮件地址用于授权用户。

组帐户的 Azure 信息保护要求

分配标签:

  • 若要配置向组成员分配其他标签的作用域策略,可以使用 Azure AD 中具有包含用户租户的已验证域的电子邮件地址的任何类型的组。 具有电子邮件地址的组通常称为启用邮件的组。

    例如,可以使用启用邮件的安全组、静态通讯组和Microsoft 365组。 不能将安全组 (动态或静态) 因为此组类型没有电子邮件地址。 此外,无法使用来自 Exchange Online 的动态通讯组列表,因为此组不会复制到Azure AD。

分配使用权限和访问控制:

  • 可以在包含用户租户Azure AD已验证域的电子邮件地址的组中使用任何类型的组。 具有电子邮件地址的组通常称为启用邮件的组。

配置 Azure Rights Management 服务:

  • 可以使用租户中具有Azure AD域的电子邮件地址的组类型,只有一个例外。 将载入控件配置为使用组时,该例外情况是,组必须是租户Azure AD安全组。

  • 可以使用租户中具有Azure AD (电子邮件地址或不带电子邮件地址) 租户中已验证域的任何组,以委托管理 Azure Rights Management 服务。

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

除了对租户中的Azure AD使用代理代理Addresses,Azure 信息保护还以相同的方式使用此属性来授权来自另一个租户的组。

使用本地 Active Directory 中的帐户进行 Azure 信息保护

如果拥有要用于 Azure 信息保护的托管本地帐户,则必须将其同步到Azure AD。 为方便部署,我们建议使用Azure AD 连接。 但是,可以使用任何实现相同结果的目录同步方法。

同步帐户时,不需要同步所有属性。 有关必须同步的属性列表,请参阅以下文档中的Azure RMS Azure Active Directory部分。

从 Azure Rights Management 的属性列表中,可以看到,对于用户,同步需要邮件、proxyAddressesuserPrincipalName的本地 AD 属性。 mailproxyAddresses的值将同步到Azure AD proxyAddresses 属性。 有关详细信息,请参阅如何在 Azure AD 中填充proxyAddresses 属性

确认用户和组已准备好进行 Azure 信息保护

可以使用 PowerShell Azure AD确认用户和组可以与 Azure 信息保护一起使用。 也可使用 PowerShell 来确认可用于授权的值。

例如,在 PowerShell 会话中使用适用于 Azure Active Directory MSOnline的 V1 PowerShell 模块,首先连接到服务,并提供全局管理员凭据:

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 以匹配电子邮件地址,则必须执行以下步骤:

  1. 如果 UPN 值中的域名是 Azure AD 租户的已验证域,则添加 UPN 值作为 Azure AD 中的另一个电子邮件地址,以便 UPN 值现在可用于授权用户帐户进行 Azure 信息保护。

    如果 UPN 值中的域名不是租户的已验证域,则不能与 Azure 信息保护一起使用。 但是,当组电子邮件地址使用已验证的域名时,用户仍可被授权为组的成员。

  2. 如果 UPN 不可路由 (例如) ,请为用户配置备用登录 ID,并指示他们如何使用Office登录。 ankurroy@contoso.local 此外,还必须设置注册表项Office。

    对于用户的 UPN 更改,至少 24 小时或 UPN 更改正确反映在系统中之前,将丢失业务连续性。

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

提示

可以使用 Export-Csv cmdlet 将结果导出到电子表格,以便更轻松地管理,例如搜索和批量编辑导入。

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

注意

对于用户的 UPN 更改,至少 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 信息保护的注意事项

如果更改用户或组的电子邮件地址,建议将旧电子邮件地址添加为第二个电子邮件地址 (也称为代理地址、别名或备用电子邮件地址) 用户或组。 这样做时,旧电子邮件地址将添加到 Azure AD addresses 属性。 此帐户管理可确保在使用旧电子邮件地址时保存的任何使用权限或其他配置的业务连续性。

如果无法这样做,具有新电子邮件地址的用户或组有被拒绝访问以前使用旧电子邮件地址保护的文档和电子邮件的风险。 在这种情况下,必须重复保护配置以保存新电子邮件地址。 例如,如果向用户或组授予了模板或标签中的使用权限,请编辑这些模板或标签,并指定具有与授予旧电子邮件地址相同的使用权限的新电子邮件地址。

请注意,组很少更改其电子邮件地址,如果将使用权限分配给组而不是单个用户,则用户的电子邮件地址是否发生更改并不重要。 在此方案中,使用权限分配给组电子邮件地址,而不是单个用户电子邮件地址。 这是管理员最可能 (建议) 配置用于保护文档和电子邮件的使用权限的方法。 但是,用户通常会为单个用户分配自定义权限。 因为始终无法知道用户帐户或组是否用于授予访问权限,所以始终将旧电子邮件地址添加为第二个电子邮件地址最安全。

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

出于性能原因,Azure 信息保护会缓存组成员身份。 这意味着,当 Azure 信息保护使用这些组时,对 Azure AD 成员身份的任何更改最多可能需要三个小时才能生效,并且此时间段可能会更改。

请记住,在使用组授予使用权限或配置 Azure Rights Management 服务,或者配置作用域策略时执行的任何更改或测试中都考虑到此延迟。

下一步

确认用户和组可以与 Azure 信息保护一同使用,并且已准备好开始保护文档和电子邮件时,请检查是否需要激活 Azure Rights Management 服务。 必须先激活此服务,才能保护组织的文档和电子邮件:

  • 从 2018 年 2 月开始:如果包含 Azure Rights Management 或 Azure 信息保护的订阅在本月或之后获得,系统会自动激活该服务。

  • 如果订阅是在 2018 年 2 月之前获取的:则必须自己激活该服务。

有关详细信息,包括检查激活状态,请参阅从 Azure 信息保护激活 保护服务