Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

第 5 章 使用 ActiveActive Directorynbsp;Directory 和 IdentityIdentity Managementnbsp;Management 创建 Cross-forest Trusts

本章论述了 ActiveActive Directorynbsp;Directory 和 IdentityIdentity Managementnbsp 间创建跨林信任;Management.跨林信任是间接集成身份管理和 Active Directory(AD)环境的两个方法之一。另一种方法是同步。如果您不确定要为您的环境选择哪一种方法，请参阅 第 1.3 节 “间接集成”。
Kerberos 实施信任的概念。在信任中，一个 Kerberos 域的主体可向另一个 Kerberos 域中的服务请求一个票据。使用此票据时，主体可以针对属于其他域的计算机上的资源进行身份验证。
Kerberos 也可以在另外两个单独的 Kerberos 域之间创建关系：跨域信任。属于信任的域使用一对票据和密钥；一个域的成员然后计算为两个域的成员。
红帽身份管理支持在 IdM 域和 Active Directory 域之间配置跨林信任。

5.1. 跨林信任简介

Kerberos 域仅涉及身份验证。其他服务和协议用于为 Kerberos 域中的计算机上运行的资源补充身份和授权。
因此，建立 Kerberos 跨域信任不足以让一个域的用户访问另一域中的资源；在其他通信级别也需要支持。

5.1.1. 信任关系的架构

ActiveActive Directorynbsp;Directory 和 IdentityIdentity Managementnbsp;Management 管理各种核心服务，如 Kerberos、LDAP、DNS 或证书服务。为了以透明的方式集成这两种多样化环境，所有核心服务必须彼此无缝交互。

Active Directory Trusts、林和跨林信任

Kerberos 跨域信任在 Active Directory 环境之间身份验证方面扮演着重要角色。无论如何执行访问权限，解析可信 AD 域中用户和组名称的所有活动都需要身份验证：使用 LDAP 协议或作为服务器消息块(SMB)协议基础上分布式计算环境/远程过程调用(DCE/RPC)的一部分。由于在两个不同的 Active Directory 域之间组织访问涉及更多协议，因此信任关系具有更为通用的名称，Active Directory 信任。
可以将多个 AD 域组织到 Active Directory 林中。林的根域是林中创建的第一个域。身份管理域不能是现有 AD 林的一部分，因此它总是被视为一个单独的林。
当两个单独的林根域之间建立了信任关系时，允许来自不同 AD 地区的用户和服务进行通信，则信任称为 Active Directory 跨林信任。

信任流和单向信任

信任在两个域之间建立访问关系。Activeactive Directorynbsp;Directory 环境可能比较复杂，因此 ActiveActive Directorynbsp 的可能类型和排序;Directory 信任、在子域、根域或林之间。信任是指从一个域到另一个域的路径。在域之间移动身份和信息的方式称为信任流。
受信任的域包含用户 ，信任域则允许访问资源。在单向信任中，信任流向一个方向：用户可以访问信任域的资源，但信任域的用户无法访问受信任的域中的资源。在 图 5.1 “单向信任” 中，Domain A 被 Domain B 信任，但 Domain B 不被 Domain A 信任。

图 5.1. 单向信任

单向信任
IdM 允许管理员配置单向和双向信任。详情请查看 第 5.1.4 节 “一次性和双向信任”。

传输和非转换信任

信任可以是传递的，以便域信任另一个域和被该第二个域信任的任何其他域。

图 5.2. 传输信任

传输信任
信任也可以是非转换性的，这意味着信任仅限于明确包含的域。

Active Directory 和 Identity Management 中的跨林信任

在 Active Directory 林内，域之间的信任关系在默认情况下通常是双向和传递的。
因为两个 AD 林之间的信任是两个林根域之间的信任，所以它也可以是双向或单向的。跨林信任的传递很明确：任何在 AD 林内导致林根域的域信任正在被跨林信任传递。但是，单独的跨林信任不是传递的。必须在每个 AD 林根域与另一个 AD 林根域之间建立显式跨林信任。
从 AD 的角度来看，身份管理代表一个独立的 AD 域。当 AD 林根域和 IdM 域之间建立跨林信任时，来自 AD 林域中的用户可以与 IdM 域中的 Linux 计算机和服务交互。

图 5.3. 信任方向

信任方向

5.1.2. Active Directory 安全对象和信任

Active Directory 全局目录

全局目录包含有关 ActiveActive Directorynbsp;Directory 对象的信息。它将对象的完整副本存储在自己的域中。来自 ActiveActive Directorynbsp 中其他域的对象；Directory 林，通常最多搜索属性的部分副本存储在全局目录中。此外，某些类型的组仅在特定范围内有效，且可能不属于全局目录。
请注意，跨林信任上下文比单个域宽松。因此，来自可信林的这些服务器本地或域范围内安全组成员资格对 IdM 服务器可能不可见。

全局目录和 POSIX 属性

Activeactive Directorynbsp;Directory 不使用默认设置复制 POSIX 属性。如果需要使用 AD 中定义的 POSIX 属性，请强烈建议将它们复制到全局目录服务。

5.1.3. IdM 中的信任架构

在 IdentityIdentity Managementnbsp;Management side 中，IdM 服务器必须能够识别 ActiveActive Directorynbsp;Directory 身份并相应地处理访问控制的组成员资格。Microsoft PAC（MS-PAC、Privilege Account 证书）包含用户所需的信息、其安全 ID、域名和组成员身份。IdentityIdentity Managementnbsp;Management 有两个组件来分析 Kerberos ticket 中 PAC 中的数据：
  • SSSD，要在 ActiveActive Directorynbsp 上执行身份查找，并检索用于授权的用户和组安全标识符(SID)。SSSD 还缓存用户、组和票据信息，以及映射 Kerberos 和 DNS 域的用户、组和票据信息，
  • IdentityIdentity Managementnbsp;Management（Linux 域管理）将 ActiveActive Directorynbsp;Directory 用户与 aan IdMnbsp;IdM 组关联，用于 IdM 策略和访问。
    注意
    Linux 域管理（如 SELinux、sudo 和基于主机的访问控制）的访问控制规则和策略通过 IdentityIdentity Managementnbsp;Management 进行定义和应用。在 ActiveActive Directorynbsp;Directory 一侧设置的任何访问控制规则没有被 IdM 评估或使用；唯一的 ActiveActive Directorynbsp;Directory 配置是组成员资格。

使用不同的 Active Directory Forests 信任

IdM 也可以是与不同 AD 林的信任关系的一部分。建立信任后，可以按照相同的命令和程序在以后添加与其他林之间的额外信任。IdM 可以同时信任多个完全不相关的林，允许来自这些不相关 AD 的用户访问同一共享 IdM 域中的资源。

5.1.3.1. Activeactive Directorynbsp;Directory PACs 和 IdM Tickets

ActiveActive Directorynbsp 中的组信息存储在 Privilege Attribute 证书 （MS-PAC 或 PAC）数据集中的标识符列表中。PAC 包含各种授权信息，如组成员身份或其他凭据信息。它还包括 Active Directory 域中用户和组的安全标识符 (SID)。SIDS 是创建时分配给 Active Directory 用户和组的标识符。在信任环境中，组成员由 SID 标识，而不是名称或 DN。
Active Directory 用户的 Kerberos 服务请求票据中嵌入了 PAC，作为将实体识别到 Windows 域中其他 Windows 客户端和服务器的一种方式。IdM 将 PAC 中的组信息映射到 ActiveActive Directorynbsp;Directory 组，然后到对应的 IdM 组来确定访问权限。
当 ActiveActive Directorynbsp;Directory 用户在 IdM 资源中请求一个 ticket 请求时，此过程如下：
  1. 服务请求包含用户的 PAC。IdM Kerberos 分发中心(KDC)通过比较 Active Directory 组列表和 IdM 组中的成员资格来分析 PAC。
  2. 对于 MS-PAC 中定义的 Kerberos 主体的 SID，IdM KDC 评估 IdM LDAP 中定义的外部组成员资格。如果 SID 有可用的其他映射，MS-PAC 记录将使用 SID 所属 IdM 组的其他 SID 扩展。生成的 MS-PAC 由 IdM KDC 签名。
  3. 服务票据返回给用户，其更新的 PAC 由 IdM KDC 签名。属于 IdM 域的 AD 组的用户现在可以被 IdM 客户端上的 SSSD 根据服务票据的 MS-PAC 内容识别。这允许减少身份流量来发现 IdM 客户端的组成员资格。
当 IdM 客户端评估服务票据时，该进程包括以下步骤：
  1. 评估流程中使用的 Kerberos 客户端库将 PAC 数据发送到 SSSD PAC 响应器。
  2. PAC 响应器验证 PAC 中的组 SID，并将用户添加到 SSSD 缓存中的对应组。当访问新服务时，SSSD 会为每个用户存储多个 TGT 和票据。
  3. 属于已验证组的用户现在可以访问 IdM 端所需的服务。

5.1.3.2. Active Directory 用户和身份管理组

在管理 Active Directory 用户和组时，您可以将单独的 AD 用户和整个 AD 组添加到身份管理组中。
有关如何为 AD 用户配置 IdM 组的描述，请参阅 第 5.3.3 节 “为 ActiveActive Directorynbsp 创建 IdM 组;Directory 用户”。

非POSIX 外部组和 SID 映射

IdM LDAP 中的组成员资格通过指定属于组成员的 LDAP 对象的区分名称(DN)来表示。AD 条目不会同步或复制到 IdM，这意味着 AD 用户和组在 IdM LDAP 中没有 LDAP 对象。因此，它们不能直接用于在 IdM LDAP 中表达组成员资格。
因此，IdM 会创建非POSIX 外部组 ：代理 LDAP 对象，其中包含 AD 用户和组的 SID 作为字符串的引用。然后，非POSIX 外部组被引用为普通 IdM LDAP 对象，以代表 IdM 中的 AD 用户和组的组成员资格。
非POSIX 外部组的 SIDS 由 SSSD 处理；SSSD 映射 AD 用户属于 IdM 中的 POSIX 组的 SID。AD 端的 SID 与用户名关联。当用户名用于访问 IdM 资源时，IdM 中的 SSSD 会将该用户名解析为其 SID，然后在 AD 域中查找该 SID 的信息，如 第 5.1.3.1 节 “Activeactive Directorynbsp;Directory PACs 和 IdM Tickets” 所述。

ID 范围

在 Linux 中创建用户时，会为其分配用户 ID 号。此外，也为用户创建一个专用组。私有组 ID 号与用户 ID 号相同。在 Linux 环境中，这不会造成冲突。但是，在 Windows 上，安全 ID 号必须为域中的每个对象唯一。
受信任的 AD 用户需要在 Linux 系统中使用 UID 和 GID 号。IdM 可以生成这个 UID 和 GID 号，但如果 AD 条目已分配了 UID 和 GID 号，则分配不同的数字会导致冲突。为避免此类冲突，可以使用 AD 定义的 POSIX 属性，包括 UID 和 GID 号以及首选的登录 shell。
注意
AD 将林内所有对象的信息子集存储在全局目录中。全局目录包括林中的每个域的所有条目。如果要使用 AD 定义的 POSIX 属性，红帽强烈建议您首先将这些属性复制到全局目录。
创建信任时，IdM 会自动检测要使用的 ID 范围，并为添加到信任的 AD 域创建一个唯一 ID 范围。您还可以通过将以下选项之一传递给 ipa trust-add 命令来手动选择：
ipa-ad-trust
此范围选项用于 IdM 根据 SID 生成 ID 算法。
如果 IdM 使用 SID-to-POSIX ID 映射生成 SID，AD 和 IdM 用户和组的 ID 范围必须具有唯一、非覆盖的 ID 范围。
ipa-ad-trust-posix
此范围选项用于 AD 条目中 POSIX 属性中定义的 ID。
IdM 从 AD 的全局目录或目录控制器获取 POSIX 属性，包括 uidNumber 和 gidNumber。如果 AD 域正确管理且没有 ID 冲突，则以这种方式生成的 ID 号是唯一的。在这种情况下，不需要验证 ID 或 ID 范围。
例如： 
[root@ipaserver ~]# ipa trust-add name_of_the_trust --range-type=ipa-ad-trust-posix
重新创建其他 ID 范围的信任
如果所创建信任的 ID 范围不适合您的部署，您可以使用 other --range-type 选项重新创建信任：
  1. 查看当前使用的所有 ID 范围： 
    [root@ipaserver ~]# ipa idrange-find
    在列表中，标识 ipa trust-add 命令创建的 ID 范围的名称。ID 范围名称的第一部分是 trust: name_of_the_trust _id_range的名称，如 ad.example.com。
  2. （可选）如果您不知道在创建信任时使用了哪个 --range-type 选项 ipa-ad -trust 或 ipa-ad-trust-posix，请识别该选项： 
    [root@ipaserver ~]# ipa idrange-show name_of_the_trust_id_range
    记录 类型，以便您在第 5 步中为新信任选择相反类型。
  3. 删除 ipa trust-add 命令创建的范围： 
    [root@ipaserver ~]# ipa idrange-del name_of_the_trust_id_range
  4. 删除信任： 
    [root@ipaserver ~]# ipa trust-del name_of_the_trust
  5. 使用正确的 --range-type 选项创建新信任。例如： 
    [root@ipaserver ~]# ipa trust-add name_of_the_trust --range-type=ipa-ad-trust

5.1.3.3. Active Directory 用户以及 IdM 策略和配置

几个 IdM 策略定义（如 SELinux、基于主机的访问控制、sudo 和 netgroups）依赖于用户组来识别策略的应用方式。

图 5.4. ActiveActive Directorynbsp;Directory Users and IdM Groups and Policies

ActiveActive Directorynbsp;Directory Users and IdM Groups and Policies
Active Directory 用户在 IdM 域外部，但仍可作为组成员添加到 IdM 组，只要这些组配置为外部组，如 第 5.1.3.2 节 “Active Directory 用户和身份管理组” 所述。在这种情况下，sudo、基于主机的访问控制和其他策略会应用到外部 POSIX 组，最终在访问 IdM 域资源时应用到 AD 用户。
ticket 中的 PAC 中的用户 SID 被解析为 AD 身份。这意味着，ActiveActive Directorynbsp;Directory 用户可使用其完全限定的用户名或其 SID 作为组成员来添加。

5.1.4. 一次性和双向信任

IdM 支持两种类型的信任协议，具体取决于能够建立与 IdM 中服务连接的实体是仅限于 AD，也可以包含 IdM 实体。
单向信任
单向信任可让 AD 用户和组访问 IdM 中的资源，但不能通过另一种方式访问。IdM 域信任 AD 林，但 AD 林不信任 IdM 域。
单向信任是创建信任的默认模式。
双向信任
双向信任可让 AD 用户和组访问 IdM 中的资源。您必须为 Microsoft SQL Server 等解决方案配置双向信任，该解决方案希望 Kerberos 协议的 S4U2Self 和 S4U2Proxy Microsoft 扩展在信任范围内工作。RHEL IdM 主机上的应用可能会从 Active Directory 域控制器请求 S4U2Self 或 S4U2Proxy 信息，并提供一个双向信任来提供此功能。
请注意，这个双向信任功能并不允许 IdM 用户登录到 Windows 系统，IdM 中的双向信任并不为用户授予与 AD 中的单向信任解决方案相比的任何额外权利。
有关单向和双向信任的常规信息，请参阅 第 5.1.1 节 “信任关系的架构”。
建立信任后，就无法修改其类型。如果您需要其他类型的信任，请再次运行 ipa trust-add 命令；这样做，您可以删除现有信任并创建新信任。

5.1.5. 外部 Trusts 到 ActiveActive Directorynbsp;Directory

外部信任是指位于不同地区的域之间的信任关系。虽然林信任始终需要在 ActiveActive Directorynbsp 根域间建立信任；Directory 林，您可以建立对林内任何域的信任。
外部信任是非转换的。因此，来自其他 ActiveActive Directorynbsp 的用户和组无法访问 IdM 资源。如需更多信息，请参阅 “传输和非转换信任”一节。

5.1.6. 信任控制器和信任代理

IdM 提供以下支持对 ActiveActive Directorynbsp;Directory 信任的 IdM 服务器：
信任控制器
可以控制信任并对 ActiveActive Directorynbsp;Directory 域控制器(DC)执行身份查找的 IdM 服务器。Activeactive Directorynbsp;Directory 域控制器在建立和验证对 ActiveActive Directorynbsp 的信任时联系信任控制器。配置信任时会创建第一个信任控制器。
有关将 IdM 服务器配置为信任控制器的详情，请参考 第 5.2.2 节 “创建信任”。
与信任代理相比，信任控制器运行更多的面向网络的服务，因而为潜在的入侵者提供了更大的攻击面。
信任代理
可针对 ActiveActive Directorynbsp;Directory 域控制器执行身份查找的 IdM 服务器。
有关将 IdM 服务器配置为信任代理的详情，请参考 第 5.2.2.1.1 节 “为信任准备 IdM 服务器”。
除了信任控制器和代理外，IdM 域还可以包含不带任何角色的副本。但是，这些服务器并不与 ActiveActive Directorynbsp;Directory 进行通信。因此，与这些服务器通信的客户端无法解决 ActiveActive Directorynbsp;Directory 用户和组或验证或授权 ActiveActive Directorynbsp;Directory 用户。

表 5.1. 信任控制器和信任代理提供的功能比较

功能 信任控制器 信任代理
解决 ActiveActive Directorynbsp;Directory 用户和组 是 是
注册运行来自可信 ActiveActive Directorynbsp 的用户访问的 IdM 客户端；Directory 林 是 是
管理信任（例如，添加信任协议） 是 否
在规划部署信任控制器和信任代理时，请考虑以下指南：
  • 每个身份管理部署至少配置两个信任控制器。
  • 在每个数据中心中至少配置两个信任控制器。
如果您希望创建额外的信任控制器，或者现有信任控制器失败，请通过提升信任代理或副本来创建新的信任控制器。要做到这一点，在 IdM 服务器中使用 ipa-adtrust-install 工具，如 第 5.2.2.1.1 节 “为信任准备 IdM 服务器” 所述。
重要
您不能将现有信任控制器降级到信任代理。信任控制器服务器角色安装后，就无法从拓扑中删除。