在 IdM 和 AD 间安装信任

大约 44 分钟

在 IdM 和 AD 间安装信任

来源：官方文档原始多页入口：在 IdM 和 AD 间安装信任内容规模：约 38,608 字符，43 个章节标题，102 个命令/代码块，22 条提示框

阅读提要

副标题：管理 IdM 和 AD 域之间的跨林信任
摘要：身份管理(IdM)和活动目录(AD)管理各种核心服务，如 Kerberos、LDAP、DNS 和证书服务。信任关系通过使所有核心服务无缝交互，透明地集成了这两个环境。例如，信任可让 AD 用户认证到 IdM 拓扑中的服务。准备信任需要在 IdM 和 AD 中使用通用加密类型，在防火墙中打开端口，以及配置 DNS 和 Kerberos 领域设置。如果不再需要信任，您可以将其删除。
主要章节：管理 IdM 和 AD 域之间的跨林信任；对红帽文档提供反馈；第 1 章建立信任的先决条件；第 2 章 Windows 服务器支持的版本；第 3 章 IdM 和 AD 之间的信任是如何工作的；第 4 章 AD 管理权利；第 5 章确保支持 AD 和 RHEL 中的通用加密类型；第 6 章 IdM 和 AD 间的通信所需的端口；第 7 章为信任配置 DNS 和域设置；第 8 章在活动目录 DNS 域中配置 IdM 客户端；第 9 章设置信任；第 10 章对设置跨林信任进行故障排除
推荐阅读顺序：先看“阅读提要”和目录，再按章节查看“关键点/命令/注意”；需要原文细节时点击来源链接。

章节笔记

概览

该章节主要为下一级主题的入口。

管理 IdM 和 AD 域之间的跨林信任

要点：摘要

对红帽文档提供反馈

要点：我们致力于为您提供高质量的文档，您的反馈将对我们有很大帮助。为帮助我们改进，您可以通过 Red Hat Jira 跟踪系统提交建议或报告错误。
要点：流程
列表：登录到 Jira 网站。如果您还没有帐户，请创建一个。
列表：单击顶部导航栏中的 Create。
列表：在 Summary 字段中输入描述性标题。
列表：在 Description 字段中输入您对改进的建议。包括文档相关部分的链接。
列表：点窗口底部的 Create。

第 1 章建立信任的先决条件

要点：要在身份管理(IdM)域和 Active Directory (AD)域之间建立跨林信任，您必须在 IdM 服务器和 AD 域控制器上正确配置所有必需的先决条件。
要点：每个服务器的唯一 NetBIOS 名称放在信任中，因为 NetBIOS 名称对于识别 AD 域至关重要。
列表：首先，请参阅规划身份管理和活动目录之间的跨林信任文档。
列表：AD 安装在其中有一个域控制器。
列表：IdM 服务器已安装并运行。
列表：AD 服务器和 IdM 服务器的时钟必须同步，因为 Kerberos 要求通信的最大延迟为 5 分钟。
列表：每个服务器的唯一 NetBIOS 名称放在信任中，因为 NetBIOS 名称对于识别 AD 域至关重要。 AD 或 IdM 域的 NetBIOS 名称通常是相应 DNS 域的第一部分。如果 DNS 域是 ad.example.com，则 NetBIOS 名称通常是 AD。但这不是必须的。务必要确保 NetBIOS 名称只包括一个词且没有句点。NetBIOS 名称的最大长度为 15 个字符。
列表：IdM 系统必须在内核中启用 IPv6 协议。如果禁用 IPv6，IdM 服务使用的 CLDAP 插件将无法初始化。
注意：注意在 RHEL 7 中，同步和信任是把 RHEL 系统间接集成到活动目录(AD)的两种可能的方法。在 RHEL 8 中，同步已弃用，在 RHEL 9 中，它不再提供。要集成 IdM 和 AD，请使用信任方法。

第 2 章 Windows 服务器支持的版本

要点：确保您的活动目录(AD)环境满足与身份管理(IdM)的兼容性要求。
要点：您可以使用以下林和域功能级别建立与 AD 林的信任关系：
列表：林功能级别范围：Windows Server 2012 - Windows Server 2025
列表：域功能级别范围：Windows Server 2012 - Windows Server 2025
列表：Windows Server 2025
列表：Windows Server 2022
列表：Windows Server 2019
列表：Windows Server 2016
注意：重要 IdM 不支持建立 AD 与运行 Windows Server 2008 R2 或更早版本的 AD 域控制器之间的信任。IdM 在建立信任关系时需要 SMB 加密，这只在 Windows Server 2012 或更高版本中支持。

第 3 章 IdM 和 AD 之间的信任是如何工作的

要点：身份管理(IdM)和活动目录(AD)在两个 Active Directory 林之间建立林级信任，IdM 代表单独的 AD 林。这可让所有 AD 用户：
要点：在信任关系中，所有 IdM 对象都在 IdM 中管理，而所有 AD 对象都在 AD 中管理。
列表：登录访问 Linux 系统和资源。
列表：使用单点登录（SSO）。
注意：注意在信任的环境中，IdM 可让您使用 ID 视图来为 IdM 服务器上的 AD 用户配置 POSIX 属性。

第 4 章 AD 管理权利

要点：要在 Active Directory (AD)和身份管理(IdM)之间建立信任，您必须使用具有所需特权的 AD 管理员帐户。
要点：用于在 AD 和 IdM 之间建立信任的 AD 管理员帐户必须属于以下组之一：
列表：AD 林中的企业管理员组
列表：AD 林的林根域中的域管理员组
列表：企业管理员
列表：域管理员
列表：域和林信任是如何工作的

第 5 章确保支持 AD 和 RHEL 中的通用加密类型

要点：默认情况下，身份管理建立一个跨域信任，支持 AES-128 和 AES-256 Kerberos 加密类型，并且弃用了不太安全的 RC4 类型。但是，Active Directory (AD)用户凭证和 AD 域间的信任可能仍然依赖于 RC4 加密。
要点：RC4 加密已被弃用并默认禁用，因为它被视为不如较新的 AES-128 和 AES-256 加密类型安全。相反，Active Directory(AD)用户凭证和 AD 域之间的信任支持 RC4 加密，它们可能不支持 AES 加密类型。
列表：要在 Active Directory 中启用 AES 加密支持（推荐），请参阅以下 Microsoft 文章： AD DS: Security: Kerberos "Unsupported etype" 错误（在访问可信域中的资源时）。
列表：要在 RHEL 中启用 RC4 支持，如果您的活动目录环境不支持 AES 加密，请将加密子策略设置为支持每个 IdM 信任控制器、信任代理和客户端上针对 AD 域控制器进行身份验证的传统算法： [root@host ~]# update-crypto-policies --set LEGACY:AD-SUPPORT-LEGACY Setting system policy to LEGACY:AD-SUPPORT-LEGACY Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the…
列表：重启主机。
列表：使用系统范围的加密策略
列表：信任控制器和信任代理
命令/配置摘录：

[root@host ~]# update-crypto-policies --set LEGACY:AD-SUPPORT-LEGACY
Setting system policy to LEGACY:AD-SUPPORT-LEGACY Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place.

第 6 章 IdM 和 AD 间的通信所需的端口

要点：在 AD 域控制器和 IdM 服务器的防火墙中打开以下端口，以启用 Active Directory (AD)和身份管理(IdM)环境之间的必要的通信。
要点：要打开端口，您可以使用以下方法：
列表：firewalld 服务 — 您可以启用特定的端口，或启用包括端口的以下服务： freeipa 信任配置 LDAP 的 FreeIPA Kerberos DNS 详情请查看您系统上的 firewall-cmd 手册页。
列表：freeipa 信任配置
列表：LDAP 的 FreeIPA
列表：Kerberos
列表：DNS
列表：RHEL web 控制台，它是一个基于 firewalld 服务的带有防火墙设置的 UI。在 Networking 部分，点您使用的防火墙区旁的 Add services，并添加所需的服务和端口。
注意：注意在 IdM 服务器中不需要为信任打开 TCP 端口 389，但与 IdM 服务器通信的客户端需要这样端口。 DCE RPC 端点映射程序需要 TCP 端口 135 才能正常工作，并在 IdM-AD 信任创建过程中使用。
注意：注意 ipa-adtrust-install 命令目前在其安装后概述中列出了端口 138 (NetBIOS-DGM)和 139 (NetBIOS-SSN)。这些端口不需要，并可以被阻断。
表格样本（共 6 行）：
- 服务 | 端口 | 协议
- 端点解析端口映射器 | 135 | TCP
- Microsoft-DS | 445 | TCP 和 UDP
- Dynamic RPC | 49152-65535 | TCP

第 7 章为信任配置 DNS 和域设置

要点：在身份管理(IdM)和活动目录(AD)之间建立信任前，您必须确保两个环境都可以正确解析域名。
要点：要使用集成的 DNS 服务器和认证机构(CA)和 AD 域控制器在 IdM 服务器之间配置 DNS 解析，请执行以下任务：
列表：准备 IdM 环境：配置必要的 DNS 区域和资源记录。
列表：启用跨域解析：在 AD 服务器上配置条件 DNS 转发以指向 IdM。
列表：验证连接：验证 DNS 配置以确保域间的无缝通信。

7.1. 唯一的主 DNS 域

要点：要使身份管理(IdM)到 Active Directory (AD)信任，每个环境都必须占据唯一的、专用 DNS 域和 Kerberos 域。这种分离允许 Active Directory 通过名称后缀路由路由身份验证请求。
要点：每个系统都必须配置自己的唯一的主 DNS 域。例如：
列表：ad.example.com 用于 AD，Idm.example.com 用于 IdM。
列表：example.com 用于 AD，idm.example.com 用于 IdM
列表：AD的 ad.example.com 和 IdM 的 example.com
列表：在活动目录 DNS 域中配置 IdM 客户端
命令/配置摘录：

$ ipa dns-update-system-records --dry-run
IPA DNS records:  _kerberos-master._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.  _kerberos-master._udp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.  _kerberos._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.  _kerberos._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.  _kerberos.idm.example.com. 86400 IN TXT "IDM.EXAMPLE.COM"  _kpasswd._tcp.idm.example.com. 86400 IN SRV 0 100 464 server.idm.example.com.  _kpasswd._udp.idm.example.com. 86400 IN SRV 0 100 464 server.idm.example.com.  _ldap._tcp.idm.example.com. 86400 IN SRV 0 100 389 server.idm.example.com.  _ipa-ca.…

注意：注意在 IdM 和 AD 之间具有信任的一些环境中，您可以在是活动目录 DNS 域的一部分的主机上安装 IdM 客户端。然后，主机可以从基于 Linux 的 IdM 功能中获益。这不是推荐的配置，存在一些限制。

7.2. 在 IdM Web UI 中配置 DNS 转发区域

要点：使用 Identity Management (IdM) Web UI 配置 DNS 转发区域。这允许 IdM 服务器将对外部域（如 Active Directory 环境）的查询路由到其相应的 DNS 服务器。
要点：先决条件
列表：使用具有管理员权限的用户帐户访问 IdM Web UI。
列表：正确配置了 DNS 服务器。
列表：使用管理员权限登录到 IdM Web UI。
列表：点 Network Services 选项卡。
列表：点 DNS 选项卡。
列表：在下拉菜单中，点 DNS Forward Zones。
命令/配置摘录：

dnssec-validation no;
# systemctl restart named

注意：注意在配置中添加转发区域后，Web UI 可能会显示一条有关 DNSSEC 验证失败的警告。 DNSSEC（域名系统安全扩展）使用数字签名来保护 DNS 数据，使 DNS 免受攻击。在IdM 服务器中默认启用该服务。出现警告的原因是远程 DNS 服务器没有使用 DNSSEC。在远程 DNS 服务器上启用 DNSSEC。如果您无法在远程服务器上启用 DNSSEC 验证，您可以在 IdM 服务器中禁用 DNSSEC ：打开 IdM 服务器上的 /etc/named/ipa-options-ext.conf 文件。添加以下 DNSSEC 参数： dnssec-validation no; 保存并关闭配置文件。重启 DNS 服务： # systemctl restart named 请注意，DNSSEC 仅在 IdM 中作为技术预览提供。

7.3. 在 CLI 中配置 DNS 转发区域

要点：使用身份管理(IdM) CLI 配置 DNS 转发区域。这允许 IdM 服务器将对外部域（如 Active Directory 环境）的查询路由到其相应的 DNS 服务器。
要点：先决条件
列表：使用具有管理员权限的用户帐户访问 CLI。
列表：正确配置了 DNS 服务器。
列表：为 AD 域创建 DNS 转发区域，并使用 --forwarder 选项指定远程 DNS 服务器的 IP 地址： # ipa dnsforwardzone-add ad.example.com --forwarder=192.168.122.3 --forward-policy=first 注意在向配置添加新的转发区域后，您可能会在 /var/log/messages 系统日志中看到有关 DNSSEC 验证失败的警告： named[2572]: no valid DS resolving 'host.ad.example.com/A/IN': 192.168.100.25#53 DNSSEC（域名系统安全扩展）使用数字签名来保护…
列表：将 nslookup 命令与远程 DNS 服务器名称一起使用： $ nslookup ad.example.com Server: 192.168.122.2 Address: 192.168.122.2#53 No-authoritative answer: Name: ad.example.com Address: 192.168.122.3 如果正确配置了域转发，nslookup 请求会显示远程 DNS 服务器的 IP 地址。
命令/配置摘录：

# ipa dnsforwardzone-add ad.example.com --forwarder=192.168.122.3 --forward-policy=first
named[2572]: no valid DS resolving 'host.ad.example.com/A/IN': 192.168.100.25#53

注意：注意在向配置添加新的转发区域后，您可能会在 /var/log/messages 系统日志中看到有关 DNSSEC 验证失败的警告： named[2572]: no valid DS resolving 'host.ad.example.com/A/IN': 192.168.100.25#53 DNSSEC（域名系统安全扩展）使用数字签名来保护 DNS 数据，使 DNS 免受攻击。在IdM 服务器中默认启用该服务。出现警告的原因是远程 DNS 服务器没有使用 DNSSEC。在远程 DNS 服务器上启用 DNSSEC。如果您无法在远程服务器上启用 DNSSEC 验证，您可以在 IdM 服务器中禁用 DNSSEC ：打开 IdM 服务器上的 /etc/named/ipa-options-ext.conf 文件。添加以下 DNSSEC 参数： dnssec-validation no; 保存并关闭配置文件。重启 DNS 服务： # systemctl restart named 请注意，DNSSEC 仅在 IdM 中作为技术预览提供。

7.4. 在 AD 中配置 DNS 转发

要点：在 Active Directory (AD)中配置条件转发器，以启用 Windows 环境来解析身份管理(IdM)域。这是 AD 来查找 IdM Kerberos 和 LDAP 服务非常重要。
要点：先决条件
列表：已安装 AD 的 Windows Server。
列表：在两个服务器中打开 DNS 端口。
列表：登录到 Windows 服务器。
列表：打开 Server Manager。
列表：打开 DNS Manager。
列表：在 Conditional Forwarders 中，添加新正向解析器并输入： DNS Domain ：完全限定域名，如 server.idm.example.com IP Address ：IdM DNS 服务器的 IP 地址。

7.5. 验证 DNS 配置

要点：验证身份管理(IdM)和 Active Directory (AD)是否可以解析自己的服务记录和对等域的记录。在建立信任关系前，请确保成功的双向解析。
要点：先决条件
列表：您已使用具有 sudo 权限的帐户登录。
列表：对通过 UDP 的 Kerberos 和通过 TCP 服务记录的 LDAP 运行 DNS 查询。 [admin@server ~]# dig +short -t SRV _kerberos._udp.idm.example.com. 0 100 88 server.idm.example.com. [admin@server ~]# dig +short -t SRV _ldap._tcp.idm.example.com. 0 100 389 server.idm.example.com. 命令返回 IdM 服务器的 SRV 记录。
列表：使用 IdM Kerberos 域名称对 TXT 记录运行 DNS 查询。返回的值应与您在安装 IdM 时指定的 Kerberos 域匹配。 [admin@server ~]# dig +short -t TXT _kerberos.idm.example.com. "IDM.EXAMPLE.COM" 如果前面的步骤没有返回所有预期的记录，请使用缺失的记录更新 DNS 配置：如果您的 IdM 环境使用集成的 DNS 服务器，请输入不带任何选项的 ipa dns-update-system-records 命令，来更新您的系统记录： [admin@server ~]$ ipa dns-update-system-records 如…
列表：如果您的 IdM 环境使用集成的 DNS 服务器，请输入不带任何选项的 ipa dns-update-system-records 命令，来更新您的系统记录： [admin@server ~]$ ipa dns-update-system-records
列表：如果您的 IdM 环境没有使用集成的 DNS 服务器：在 IdM 服务器中，将 IdM DNS 记录导出到文件中： [admin@server ~]$ ipa dns-update-system-records --dry-run --out dns_records_file.nsupdate 该命令使用相关的 IdM DNS 记录创建一个名为 dns_records_file.nsupdate 的文件。使用 nsupdate 工具和 dns_records_file.nsupdate 文件向 DNS 服务器提交一个 DNS 更新请求。如需更多信息，请参阅 RHEL 7 文档中的使用 nsupdate 更新外部 DNS 记录…
列表：在 IdM 服务器中，将 IdM DNS 记录导出到文件中： [admin@server ~]$ ipa dns-update-system-records --dry-run --out dns_records_file.nsupdate 该命令使用相关的 IdM DNS 记录创建一个名为 dns_records_file.nsupdate 的文件。
命令/配置摘录：

[admin@server ~]# dig +short -t SRV _kerberos._udp.idm.example.com.
0 100 88 server.idm.example.com.

第 8 章在活动目录 DNS 域中配置 IdM 客户端

要点：虽然 IdM 客户端应该位于单独的 DNS 区域中，但您可以将位于 Active Directory (AD) DNS 域中的客户端加入到 IdM。这为 AD 命名空间中的主机启用特定于 RHEL 的功能。
要点：您的 IdM 客户端配置取决于您是否需要使用 Kerberos 单点登录。
注意：重要不建议使用此配置，它有局限性。始终在与 AD 拥有的 DNS 区域不同的 DNS 区域中部署 IdM 客户端，并使用其 IdM 主机名访问 IdM 客户端。

8.1. 配置没有 Kerberos 单点登录的 IdM 客户端

要点：当 IdM 客户端位于 Active Directory (AD) DNS 域中时，基于密码的身份验证是唯一支持的身份验证方法。在没有 Kerberos 单点登录的情况下手动将客户端加入到 IdM 域。
要点：流程
列表：使用 --domain=IPA_DNS_Domain 选项安装 IdM 客户端，来确保系统安全服务守护进程(SSSD)可以与 IdM 服务器进行通信： [root@idm-client.ad.example.com ~]# ipa-client-install --domain=idm.example.com 这个选项禁用了活动目录 DNS 域的 SRV 记录自动检测。
列表：打开 /etc/krb5.conf 配置文件，并在 [domain_realm] 部分中找到活动目录域的现有映射。 .ad.example.com = IDM.EXAMPLE.COM ad.example.com = IDM.EXAMPLE.COM
列表：将这两个行替换为将活动目录 DNS 区域中 Linux 客户端的完全限定域名(FQDN)映射到 IdM 域的条目： idm-client.ad.example.com = IDM.EXAMPLE.COM 通过替换默认映射，您可以防止 Kerberos 将其对活动目录域的请求发送到 IdM Kerberos 分发中心(KDC)。相反，Kerberos 使用通过 SRV DNS 记录的自动发现来定位 KDC。
命令/配置摘录：

[root@idm-client.ad.example.com ~]# ipa-client-install --domain=idm.example.com
.ad.example.com = IDM.EXAMPLE.COM ad.example.com = IDM.EXAMPLE.COM

8.2. 请求没有单点登录的 SSL 证书

要点：请求在没有 Kerberos SSO 的情况下为身份管理(IdM)客户端使用 certmonger 的 SSL 证书，以启用基于 SSL 的安全服务。
要点：在配置了没有 Kerberos 单点登录的 IdM 客户端后，您可以配置基于 SSL 的服务。
列表：一个没有配置 Kerberos 单点登录的 IdM 客户端。
列表：使用 certmonger 来请求使用 FQDN 的证书： [root@idm-client.ad.example.com ~]# ipa-getcert request -r \ -f /etc/httpd/alias/server.crt \ -k /etc/httpd/alias/server.key \ -N CN=ipa-client.ad.example.com \ -D ipa-client.ad.example.com \ -K host/idm-client.ad.example.com@IDM.EXAMPLE.COM \ -U id-kp-serverAuth certmonger 服务使用存储在 …
命令/配置摘录：

[root@idm-client.ad.example.com ~]# ipa-getcert request -r \  -f /etc/httpd/alias/server.crt \  -k /etc/httpd/alias/server.key \  -N CN=ipa-client.ad.example.com \  -D ipa-client.ad.example.com \  -K host/idm-client.ad.example.com@IDM.EXAMPLE.COM \  -U id-kp-serverAuth

8.3. 配置带有 Kerberos 单点登录的 IdM 客户端

要点：要为跨 DNS 域的 IdM 客户端启用 Kerberos 单点登录(SSO)，您必须将 Active Directory (AD)域的 CNAME 记录映射到 IdM 客户端的 A/AAAA 记录，并将客户端配置为允许灵活的主体接受。
要点：对于基于 Kerberos 的应用服务器，MIT Kerberos 支持一种方法，来允许接受应用程序的 keytab 中任何基于主机的主体。
列表：通过编辑 IdM 客户端上的 /etc/krb5.conf 文件来配置 Kerberos。在 [libdefaults] 部分中，将 ignore_acceptor_hostname 设置为 true。这允许应用程序接受其 keytab 中的任何基于主机的主体： ignore_acceptor_hostname = true
列表：确保 Active Directory DNS 中存在 CNAME 记录，如 idm-client.ad.example.com，指向 IdM DNS 域中的 IdM 客户端的 A/AAAA 记录。
命令/配置摘录：

ignore_acceptor_hostname = true

8.4. 请求带有单点登录的 SSL 证书

要点：要使用 Kerberos SSO 保护服务，您的 SSL 证书必须包含主机的 A/AAAA 和 CNAME 记录。由于 IdM 只向数据库主机对象发布证书，您必须手动创建并链接 CNAME 别名的主机条目。
要点：在 IdM 中为 ipa-client.example.com 创建主机对象，并确保实际的 IdM 机器的主机对象能够管理这个主机。
列表：您已禁用了对 Kerberos 服务器使用哪个 Kerberos 主体的严格检查。
列表：在 IdM 服务器上，为 AD-side 别名创建一个主机条目。use- force，因为名称解析为 CNAME，而不是 A/AAAA 记录。 [root@idm-server.idm.example.com ~]# ipa host-add idm-client.ad.example.com --force
列表：要允许物理 IdM 主机管理 IdM 数据库中的新别名条目，请为主机授予管理权限。 [root@idm-server.idm.example.com ~]# ipa host-add-managedby idm-client.ad.example.com \ --hosts=idm-client.idm.example.com
列表：在 IdM 客户端上，使用 ipa-getcert 来请求证书。确保使用 -D 标志包含 FQDN 和 CNAME。 [root@idm-client.idm.example.com ~]# ipa-getcert request -r \ -f /etc/httpd/alias/server.crt \ -k /etc/httpd/alias/server.key \ -N CN=hostname --fqdn \ -D hostname --fqdn \ -D idm-client.ad.example.com \ -K host/idm-client.idm.example.com@IDM.EXAMPLE…
命令/配置摘录：

[root@idm-server.idm.example.com ~]# ipa host-add idm-client.ad.example.com --force
[root@idm-server.idm.example.com ~]# ipa host-add-managedby idm-client.ad.example.com \  --hosts=idm-client.idm.example.com

第 9 章设置信任

要点：在身份管理(IdM)和活动目录(AD)之间建立信任，支持无缝的跨平台资源访问。了解如何准备 IdM 域，使用 CLI、Web UI 或 Ansible 配置信任协议，并验证跨域 Kerberos 身份验证。

9.1. 先决条件

要点：其他资源
列表：正确配置了 DNS。IdM 和 AD 服务器必须能够解析其他名称。
列表：部署了 AD 和 IdM 的支持版本。
列表：您已获得 Kerberos ticket。
列表：为信任配置 DNS 和域设置
列表：Windows 服务器支持的版本
列表：使用 kinit 手动登录到 IdM

9.2. 为信任准备 IdM 服务器

要点：在与 AD 建立信任前，您必须在 IdM 服务器上使用 ipa-adtrust-install 工具来准备 IdM 域。
要点：在其上运行 ipa-adtrust-install 命令的所有系统都会自动成为 AD 信任控制器。但是，您只能在 IdM 服务器上运行ipa-adtrust-install一次。
列表：IdM 服务器已安装。
列表：您有 root 特权来安装软件包和重启 IdM 服务。
列表：安装所需的软件包： [root@ipaserver ~]# dnf install ipa-server-trust-ad samba-client
列表：以 IdM 管理用户身份进行身份验证： [root@ipaserver ~]# kinit admin
列表：运行ipa-adtrust-install工具： [root@ipaserver ~]# ipa-adtrust-install 如果 IdM 安装了集成的 DNS 服务器，则会自动创建 DNS 服务记录。如果您安装的IdM没有集成 DNS 服务器，ipa-adtrust-install会打印一个服务记录列表，您必须手动将其添加到DNS后才能继续操作。
列表：该脚本会提示您/etc/samba/smb.conf已存在，并将被重写： WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration. Do you wish to continue? [no]: yes
命令/配置摘录：

[root@ipaserver ~]# dnf install ipa-server-trust-ad samba-client
[root@ipaserver ~]# kinit admin

注意：重要红帽强烈建议您在每次运行 ipa-adtrust-install 后验证 DNS 配置，如验证信任的 DNS 配置中所述，特别是在 IdM 或 AD 没有使用集成的 DNS 服务器的情况下。

9.3. 使用命令行设置信任协议

要点：使用命令行在身份管理(IdM)和 Active Directory (AD)之间建立信任。IdM 支持单向、双向和外部林信任，允许您使用 ipa trust-add 工具控制用户在域间访问资源的方式。
要点：Two-way trust— 双向信任使 AD 用户和组可以访问 IdM 中的资源。
列表：One-way trust 默认选项。单向信任使活动目录(AD)用户和组可以访问 IdM 中的资源，但反之则不行。IdM 域信任 AD 林，但 AD 林不信任 IdM 域。
列表：Two-way trust— 双向信任使 AD 用户和组可以访问 IdM 中的资源。您必须为像 Microsoft SQL Server 这样的解决方案配置双向信任，该解决方案希望 Kerberos 协议的 S4U2Self 和 S4U2Proxy Microsoft 扩展能够跨信任边界工作。RHEL IdM 主机上的应用可能会向 Active Directory 域控制器请求有关 AD 用户的 S4U2Self 或 S4U2Proxy 信息，双向信任提供了这一特性。请注意，这个双向信任功能并不允许 IdM 用户登录到 Windows 系统，IdM 中的双向信任并不为用户授予与 AD 中的单向信任解决方案相比的任何额外权利。 …
列表：要创建双向信任，请向命令中添加以下选项：--two-way=true
列表：External trust - 不同林中 IdM 和 AD 域之间的信任关系。虽然林信任总是需要在 IdM 和 Active Directory 林的根域之间建立信任，但可以从 IdM 到林中的域建立外部信任只有由于管理或组织方面的原因而无法在林根域之间建立林信任时，才推荐这么做。要创建外部信任，请在命令中添加以下选项：--external=true
列表：要创建外部信任，请在命令中添加以下选项：--external=true
列表：Windows 管理员的用户名和密码。
命令/配置摘录：

[root@server ~]# ipa trust-add --type=ad ad.example.com --admin <ad_admin_username> --password --range-type=ipa-ad-trust
[root@server ~]# ipa trust-add --type=ad ad.example.com --admin <ad_admin_username> --password --range-type=ipa-ad-trust-posix

注意：警告如果您在创建信任时没有指定 ID range 类型，IdM 会尝试通过在林根域中请求 AD 域控制器的详情来自动选择适当的范围类型。如果 IdM 没有检测到任何 POSIX 属性，则信任安装脚本会选择活动目录域 ID range。如果 IdM 在林根域中检测到任何 POSIX 属性，则信任安装脚本会选择带有 POSIX 属性的活动目录域 ID range，并假定已在 AD 中正确定义了 UID 和 GID。如果没有在 AD 中正确设置了 POSIX 属性，则您将无法解析 AD 用户。例如，如果需要访问 IdM 系统的用户和组不是林根域的一部分，而是位于林域的子域中，则安装脚本可能不会检测子 AD 域中定义的 POSIX 属性。在这种情况下，在建立信任时明确选择 POSIX ID 范围类型。

9.4. 在 IdM Web UI 中设置信任协议

要点：要启用 Active Directory (AD)用户验证和访问资源，您可以使用身份管理(IdM) Web UI 建立跨林信任。此配置可确保两个域都正确解析身份和共享资源。
要点：先决条件
列表：正确配置了 DNS。IdM 和 AD 服务器必须能够解析其他名称。
列表：部署了 AD 和 IdM 的支持版本。
列表：您已获得 Kerberos ticket。
列表：在 Web UI 中创建信任之前，为信任准备 IdM 服务器，如设置信任中所述。
列表：您以 IdM 管理员身份登录。详情请参阅在 Web 浏览器中访问 IdM Web UI。
列表：在 IdM Web UI 中点 IPA Server 标签页。
注意：警告如果您在默认 Detect 选项上保留 Range 类型设置，IdM 会尝试通过请求林根域中 AD 域控制器的详情来自动选择合适的 range 类型。如果 IdM 没有检测到任何 POSIX 属性，则信任安装脚本会选择活动目录域 ID range。如果 IdM 在林根域中检测到任何 POSIX 属性，则信任安装脚本会选择带有 POSIX 属性的活动目录域 ID range，并假定已在 AD 中正确定义了 UID 和 GID。如果没有在 AD 中正确设置了 POSIX 属性，则您将无法解析 AD 用户。例如，如果需要访问 IdM 系统的用户和组不是林根域的一部分，而是位于林域的子域中，则安装脚本可能不会检测子 AD 域中定义的 POSIX 属性。在这种情况下，在建立信任时明确选择 POSIX ID 范围类型。

9.5. 使用 Ansible 设置信任协议

要点：要在身份管理(IdM)和 Active Directory (AD)之间自动创建信任协议，请使用 Ansible playbook 中的 ansible-freeipa 软件包。
要点：您可以配置三种类型的信任协议：
列表：One-way trust 默认选项。单向信任使活动目录(AD)用户和组可以访问 IdM 中的资源，但反之则不行。IdM 域信任 AD 林，但 AD 林不信任 IdM 域。
列表：Two-way trust— 双向信任使 AD 用户和组可以访问 IdM 中的资源。您必须为像 Microsoft SQL Server 这样的解决方案配置双向信任，该解决方案希望 Kerberos 协议的 S4U2Self 和 S4U2Proxy Microsoft 扩展能够跨信任边界工作。RHEL IdM 主机上的应用可能会向 Active Directory 域控制器请求有关 AD 用户的 S4U2Self 或 S4U2Proxy 信息，双向信任提供了这一特性。请注意，这个双向信任功能并不允许 IdM 用户登录到 Windows 系统，IdM 中的双向信任并不为用户授予与 AD 中的单向信任解决方案相比的任何额外权利。 …
列表：要创建双向信任，请在 playbook 任务中添加以下变量： two_way: true
列表：External trust - 不同林中 IdM 和 AD 域之间的信任关系。虽然林信任总是需要在 IdM 和 Active Directory 林的根域之间建立信任，但可以从 IdM 到林中的域建立外部信任只有由于管理或组织方面的原因而无法在林根域之间建立林信任时，才推荐这么做。要创建外部信任，请在 playbook 任务中添加以下变量：external: true
列表：要创建外部信任，请在 playbook 任务中添加以下变量：external: true
列表：Windows 管理员的用户名和密码。
命令/配置摘录：

$ cd ~/MyPlaybooks/
--- - name: Playbook to create a trust  hosts: ipaserver  vars_files:  - /home/user_name/MyPlaybooks/secret.yml  tasks:  - name: ensure the trust is present  ipatrust:  ipaadmin_password: "{{ ipaadmin_password }}"  realm: ad.example.com  admin: Administrator  password: secret_password  state: present

注意：警告如果您在创建信任时没有指定 ID 范围类型，且 IdM 没有在 AD 林根域中检测到任何 POSIX 属性，则信任安装脚本会选择 Active Directory domain ID 范围。如果 IdM 在林根域中检测到任何 POSIX 属性，则信任安装脚本会选择带有 POSIX 属性的活动目录域 ID range，并假定已在 AD 中正确定义了 UID 和 GID。但是，如果 POSIX 属性没有在 AD 中正确设置，则您将无法解析 AD 用户。例如，如果需要访问 IdM 系统的用户和组不是林根域的一部分，而是位于林域的子域中，则安装脚本可能不会检测子 AD 域中定义的 POSIX 属性。在这种情况下，在建立信任时明确选择 POSIX ID 范围类型。

9.6. 验证 Kerberos 配置

要点：通过确认 Active Directory (AD)用户可以成功获取 Kerberos 票据授予票据(TGT)并访问 IdM 域中的服务来验证跨域信任。
要点：流程
列表：为 Active Directory（AD）用户请求一个 ticket（票据）： [root@ipaserver ~]# kinit user@AD.EXAMPLE.COM
列表：为 IdM 域中的服务请求 ticket： [root@server ~]# kvno -S host server.idm.example.com 如果 AD 服务单被成功授予了，则会列出一个跨领域单据授予单（TGT），以及所有其他请求的单子。TGT 命名为 krbtgt/IPA.DOMAIN@AD.DOMAIN。 [root@server ]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_hRtox00 Default principal: user@AD.EXAMPLE.COM Valid starting Expires Service principal 03.…
命令/配置摘录：

[root@ipaserver ~]# kinit user@AD.EXAMPLE.COM
[root@server ~]# kvno -S host server.idm.example.com

9.7. 验证 IdM 上的信任配置

要点：通过验证两个系统可以解析 Kerberos 和 LDAP 所需的 SRV 服务记录，以确保身份管理(IdM)和 Active Directory (AD)环境被正确集成。
要点：先决条件
列表：您需要使用管理员权限登录。
列表：对通过 UDP 的 MS DC Kerberos 和通过 TCP 服务记录的 LDAP 运行 DNS 查询。 [root@server ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.idm.example.com. 0 100 88 server.idm.example.com. [root@server ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.idm.example.com. 0 100 389 server.idm.example.com. 这些命令列出了在其上执行 ipa-adtrust-install 的所有 IdM 服务器。如果…
列表：对 Kerberos 和通过 TCP 服务记录的 LDAP 运行 DNS 查询，来验证 IdM 是否能够为 AD 解析服务记录： [root@server ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com. 0 100 88 addc1.ad.example.com. [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com. 0 100 389 addc1.ad.example.com.
命令/配置摘录：

[root@server ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.idm.example.com.
0 100 88 server.idm.example.com.

9.8. 验证 AD 上的信任配置

要点：使用 Active Directory (AD)服务器上的 nslookup.exe 工具来验证 IdM 服务记录（包括 SRV 和 TXT 类型）可以正确解析，以确保两个域间的通信正确。
要点：先决条件
列表：您需要使用管理员权限登录。
列表：在 AD 服务器上，设置 nslookup.exe 工具来查找服务记录。 C:>nslookup.exe > set type=SRV
列表：通过 UDP 和 LDAP 通过 TCP 服务记录输入 Kerberos 的域名。 > _kerberos._udp.idm.example.com. _kerberos._udp.idm.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = server.idm.example.com > _ldap._tcp.idm.example.com _ldap._tcp.idm.example.com SRV service location: priority = 0 weight = 100 port…
列表：将服务类型改为 TXT，并使用 IdM Kerberos 域名运行对 TXT 记录的 DNS 查询。 C:>nslookup.exe > set type=TXT > _kerberos.idm.example.com. _kerberos.idm.example.com. text = "IDM.EXAMPLE.COM"
列表：对通过 UDP 的 MS DC Kerberos 和通过 TCP 服务记录的 LDAP 运行 DNS 查询。 C:>nslookup.exe > set type=SRV > _kerberos._udp.dc._msdcs.idm.example.com. _kerberos._udp.dc._msdcs.idm.example.com. SRV service location: priority = 0 weight = 100 port = 88 svr hostname = server.idm.example.com > _ldap._tcp.dc._msdcs.idm.example.com. _ldap.…
列表：验证 AD 服务是否可以从 AD 服务器解析。 C:>nslookup.exe > set type=SRV
命令/配置摘录：

C:\>nslookup.exe > set type=SRV
> _kerberos._udp.idm.example.com. _kerberos._udp.idm.example.com. SRV service location:  priority = 0  weight = 100  port = 88  svr hostname = server.idm.example.com > _ldap._tcp.idm.example.com _ldap._tcp.idm.example.com SRV service location:  priority = 0  weight = 100  port = 389  svr hostname = server.idm.example.com

9.9. 创建信任代理

要点：信任代理是一个身份管理(IdM)服务器，它针对 Active Directory (AD)域控制器执行身份查找，而无需是一个完整的 AD 信任控制器。
要点：先决条件
列表：已安装了带有 Active Directory 信任的 IdM 。
列表：sssd-tools 软件包已安装。
列表：在现有的信任控制器上，运行 ipa-adtrust-install --add-agents 命令： [root@existing_trust_controller]# ipa-adtrust-install --add-agents 该命令启动一个交互式配置会话，并提示您配置代理所需的信息。
列表：重启信任代理上的 IdM 服务。 [root@new_trust_agent]# ipactl restart
列表：从信任代理上的 SSSD 缓存中删除所有条目： [root@new_trust_agent]# sssctl cache-remove
列表：验证副本是否安装了 AD 信任代理角色： [root@existing_trust_controller]# ipa server-show new_replica.idm.example.com Enabled server roles: CA server, NTP server, AD trust agent
命令/配置摘录：

[root@existing_trust_controller]# ipa-adtrust-install --add-agents
[root@new_trust_agent]# ipactl restart

9.10. 在 CLI 上为 POSIX ID range 启用自动私有组映射

要点：为 POSIX ID 范围启用自动私有组映射，以解决缺少主组配置的 Active Directory 用户。为 auto_private_groups SSSD 参数设置 hybrid 选项，确保 SSSD 可以在 IdM 中正确映射这些用户。
要点：先决条件
列表：您已成功在 IdM 和 AD 环境之间成功建立了 POSIX 跨林信任。
列表：显示所有 ID range，并记录您要修改的 AD ID range。 [root@server ~]# ipa idrange-find ---------------- 2 ranges matched ---------------- Range name: IDM.EXAMPLE.COM_id_range First Posix ID of the range: 882200000 Number of IDs in the range: 200000 Range type: local domain range Range name: AD.EXAMPLE.COM_id_range First Posix ID…
列表：使用 ipa idrange-mod 命令调整 AD ID range 的自动私有组行为。 [root@server ~]# ipa idrange-mod --auto-private-groups=hybrid AD.EXAMPLE.COM_id_range
列表：重置 SSSD 缓存以启用新的设置。 [root@server ~]# sss_cache -E
列表：为 AD 用户自动映射私有组的选项
命令/配置摘录：

[root@server ~]# ipa idrange-find
---------------- 2 ranges matched ----------------  Range name: IDM.EXAMPLE.COM_id_range  First Posix ID of the range: 882200000  Number of IDs in the range: 200000  Range type: local domain range  Range name: AD.EXAMPLE.COM_id_range  First Posix ID of the range: 1337000000  Number of IDs in the range: 200000  Domain SID of the trusted domain: S-1-5-21-4123312420-990666102-3578675309  Range type: Active Directory trust range with POSIX attributes ---------------------------- Number of entries returned 2 ----------------------------

9.11. 在 IdM WebUI 中为 POSIX ID range 启用自动私有组映射

要点：为 POSIX ID 范围启用自动私有组映射，以解决缺少主组配置的 Active Directory 用户。为 auto_private_groups SSSD 参数设置 hybrid 选项，确保 SSSD 可以在 IdM 中正确映射这些用户。
要点：先决条件
列表：您已成功在 IdM 和 AD 环境之间成功建立了 POSIX 跨林信任。
列表：使用您的用户名和密码登录到 IdM Web UI。
列表：打开 IPA Server → ID Ranges 选项卡。
列表：选择要修改的 ID range，如 AD.EXAMPLE.COM_id_range。
列表：从 Auto private groups 下拉菜单中选择 hybrid 选项。
列表：点击 Save 按钮来保存您的更改。

第 10 章对设置跨林信任进行故障排除

要点：通过分析命令执行序列、验证环境先决条件以及捕获详细的调试日志进行分析来解决跨林信任问题。

10.1. 建立与 AD 的跨林信任时的事件序列

要点：建立跨林信任涉及特定的验证和配置步骤。了解这些内部操作有助于隔离在输入验证或域级通信期间发生失败。
要点：IdM 服务器使用 Samba 套件为活动目录处理域控制器功能，并在目标 AD PDC 上创建信任对象：
列表：验证 IdM 服务器是否具有 Trust Controller 角色。
列表：验证传递给 ipa trust-add 命令的选项。
列表：验证与可信林根域关联的 ID range。如果您没有将 ID range 类型和属性指定为 ipa trust-add 命令的选项，则会从活动目录发现它们。
列表：为每个信任方向创建单独的信任对象。在两端（IdM 和 AD）都会创建每个对象。如果您要建立单向信任，只在每一端上创建一个对象。
列表：IdM 服务器使用 Samba 套件为活动目录处理域控制器功能，并在目标 AD PDC 上创建信任对象： IdM 服务器建立了一个到目标 DC 上 IPC$ 共享的安全连接。从 RHEL 8.4 开始，连接至少需要 Windows Server 2012 及以上版本的 SMB3 协议，以确保会话使用的基于AES 加密的连接足够安全。 IdM 服务器使用 LSA QueryTrustedDomainInfoByName 调用来查询是否存在可信域对象(TDO)。如果 TDO 已存在，则使用 LSA DeleteTrustedDomain 调用删除它。注意如果用来建立信任的 AD 用户帐户没有林根的全部 Enterprise Ad…
列表：IdM 服务器建立了一个到目标 DC 上 IPC$ 共享的安全连接。从 RHEL 8.4 开始，连接至少需要 Windows Server 2012 及以上版本的 SMB3 协议，以确保会话使用的基于AES 加密的连接足够安全。
注意：注意如果用来建立信任的 AD 用户帐户没有林根的全部 Enterprise Admin(EA) 或 Domain Admin(DA) 权限，如 Incoming Forest Trust Builders 组的成员，这个调用会失败。如果旧的 TDO 没有被自动删除，则 AD 管理员必须手动将其从 AD 中删除。
注意：注意此步骤可能会由于以下 3 个原因之一导致冲突： SID 命名空间冲突，报告为 LSA_SID_DISABLED_CONFLICT 错误。无法解决此冲突。 NetBIOS 命名空间冲突，报告为 LSA_NB_DISABLED_CONFLICT 错误。无法解决此冲突。 DNS 命名空间与顶级名称(TLN)的冲突，报告为 LSA_TLN_DISABLED_CONFLICT 错误。如果 TLN 是因另一个林造成的，则 IdM 服务器可以自动解决它。要解决 TLN 冲突，IdM 服务器需要执行以下步骤：检索冲突林的林信任信息。将 IdM DNS 命名空间的排除条目添加到 AD 林中。为冲突的林设置林信任信息。重新尝试建立对原始林的信任。只有通过带有可以更改林信任的 AD 管理员特权的 ipa trust-add 命令进行身份验证，IdM 服务器才能解决这些冲突。如果您没有这些特权的访问权限，则原始林的管理员必须手动执行 Windows UI 的活动目录域和信任部分中提到的步骤。

10.2. 建立 AD 信任的先决条件清单

要点：成功信任建立取决于特定的环境配置。查看产品版本、管理特权、网络和 DNS 设置的要求。
表格样本（共 9 行）：
- 组件 | 配置 | 其它详情
- 产品版本 | 您的活动目录域使用受支持的 Windows 服务器版本。 | Windows 服务器支持的版本
- AD 管理员特权 | 活动目录管理帐户必须是以下组之一的成员： AD 林中的 Enterprise Admin (EA) 组 AD 林的林根域中的 Domain Admins (DA) 组
- 网络 | 所有 IdM 服务器的 Linux 内核中都启用了 IPv6 支持。 | IdM 中的 IPv6 要求

10.3. 收集尝试建立 AD 信任的调试日志

要点：为身份管理(IdM)、Apache 和 Samba 启用调试模式，以收集失败的 Active Directory (AD)信任尝试故障排除或红帽技术支持的详细日志。
要点：先决条件
列表：您需要 root 权限来重启 IdM 服务。
列表：要为 IdM 服务器启用调试，请创建具有以下内容的文件 /etc/ipa/server.conf。 [global] debug=True
列表：重启 httpd 服务以载入调试配置。 [root@trust_controller ~]# systemctl restart httpd
列表：停止 smb 和 winbind 服务。 [root@trust_controller ~]# systemctl stop smb winbind
列表：为 smb 和 winbind 服务设置调试日志级别。 [root@trust_controller ~]# net conf setparm global 'log level' 100
列表：要为 IdM 框架使用的 Samba 客户端代码启用调试日志记录，请编辑 /usr/share/ipa/smb.conf.empty 配置文件使其包含以下内容。 [global] log level = 100
命令/配置摘录：

[global] debug=True
[root@trust_controller ~]# systemctl restart httpd

第 11 章对客户端访问其他林中的服务进行故障排除

要点：通过跟踪 Kerberos 票据请求和环境间的引用来排除跨林信任身份验证的问题。这些逻辑流有助于隔离服务请求链中的故障。

11.1. AD 林根域中的主机请求 IdM 服务器的服务时的信息流

要点：分析在身份管理(IdM)域中请求服务的活动目录(AD)客户端的 Kerberos 通信路径。此序列标识 KDC 如何处理跨域引用和 PAC 验证。
要点：如果您访问 AD 客户端的 IdM 服务时遇到问题，您可以使用此信息缩小故障排除范围，并识别问题源。
列表：AD 客户端联系 AD Kerberos 分发中心(KDC)来在 IdM 域中为服务执行 TGS 请求。
列表：AD KDC 识别该服务属于可信 IdM 域。
列表：AD KDC 向客户端发送跨域票据授予票据(TGT)，以及对可信 IdM KDC 的引用。
列表：AD 客户端使用跨域 TGT 向 IdM KDC 请求票据。
列表：IdM KDC 验证通过跨域 TGT 传输的特权属性证书(MS-PAC)。
列表：IPA-KDB 插件可能会检查 LDAP 目录，以查看是否允许外部主体获取所请求的服务的票据。

11.2. AD 子域中的主机请求 IdM 服务器的服务时的信息流

要点：从 Active Directory (AD)子域验证客户端涉及通过 AD 林根 KDC 访问身份管理(IdM) KDC 进行最终验证的多步骤 Kerberos 引用链。
要点：如果您在访问 AD 客户端的 IdM 服务时遇到问题，并且您的 AD 客户端属于 AD 林根的子域，那么您可以使用这些信息缩小故障排除的范围，并识别问题源。
列表：AD 客户端在其自己的域中联系 AD Kerberos Distribution Center(KDC)，以执行对 IdM 域中服务的 TGS 请求。
列表：子域 child.ad.example.com 中的 AD KDC（子域）识别服务属于可信的 IdM 域。
列表：子域中的 AD KDC 向客户端发送 AD 林根域 ad.example.com 的引用票据。
列表：AD 客户端联系 AD 林根域中的 KDC ，以获取 IdM 域中的服务。
列表：林根域中的 KDC 识别服务属于可信的 IdM 域。
列表：AD KDC 向客户端发送跨域票据授予票据(TGT)，以及对可信 IdM KDC 的引用。

11.3. IdM 客户端请求 AD 服务器的服务时的信息流

要点：从身份管理(IdM)客户端访问 Active Directory (AD)服务需要双向信任，以便于跨域票据授予票据(TGT)和 Privileged Attribute 证书的生成。
要点：如果您访问 IdM 客户端的 AD 服务时遇到问题，您可以使用此信息缩小故障排除的范围，并识别问题源。
列表：IdM 客户端为了其要联系的 AD 服务，请求 IdM Kerberos 分发中心(KDC)的票据授予票据。
列表：IdM KDC 识别服务属于 AD 域，验证域是否已知并可信，以及是否允许客户端请求该域的服务。
列表：使用 IdM 目录服务器关于用户主体的信息，IdM KDC 创建一个跨域 TGT，其中包含有关用户主体的特权属性证书(MS-PAC)记录。
列表：IdM KDC 向 IdM 客户端发回一个跨域 TGT。
列表：IdM 客户端联系 AD KDC 来请求 AD 服务的票据，显示包含 IdM KDC 提供的 MS-PAC 的跨域 TGT。
列表：AD 服务器验证和过滤 PAC，并返回 AD 服务的票据。
注意：注意默认情况下，IdM 建立到 AD 的单向信任，这意味着无法为 AD 林中的资源发出跨域票据授予票据(TGT)。为了能够请求可信 AD 域中服务的票据，请配置双向信任。

第 12 章使用命令行删除信任

要点：使用命令行删除身份管理(IdM)信任协议。这个过程从 IdM 框架中删除信任关系，但默认保留现有的 ID 范围。
要点：先决条件
列表：您已作为 IdM 管理员获得了 Kerberos 单。详情请参阅登录到 Web UI 中的 IdM: 使用 Kerberos 票据。
列表：使用 ipa trust-del 命令从 IdM 中删除信任配置。 [root@server ~]# ipa trust-del ad_domain_name ------------------------------ Deleted trust "ad_domain_name" ------------------------------
列表：从 Active Directory 配置中删除信任对象。注意删除信任配置不会自动删除已为 AD 用户创建的 ID 范围 IdM。这样，如果您再次添加信任，则重新使用现有的 ID 范围。另外，如果 AD 用户已在 IdM 客户端上创建了文件，则其 POSIX ID 会在文件元数据中保留。要删除与 AD 信任相关的所有信息，请在删除信任配置和信任对象后删除 AD 用户 ID 范围： # ipa idrange-del AD.EXAMPLE.COM_id_range # systemctl restart sssd
列表：使用 ipa trust-show 命令来确认信任已删除。 [root@server ~]# ipa trust-show ad.example.com ipa: ERROR: ad.example.com: trust not found
命令/配置摘录：

[root@server ~]# ipa trust-del ad_domain_name
------------------------------ Deleted trust "ad_domain_name" ------------------------------

注意：注意删除信任配置不会自动删除已为 AD 用户创建的 ID 范围 IdM。这样，如果您再次添加信任，则重新使用现有的 ID 范围。另外，如果 AD 用户已在 IdM 客户端上创建了文件，则其 POSIX ID 会在文件元数据中保留。要删除与 AD 信任相关的所有信息，请在删除信任配置和信任对象后删除 AD 用户 ID 范围： # ipa idrange-del AD.EXAMPLE.COM_id_range # systemctl restart sssd

第 13 章使用 IdM Web UI 删除信任

要点：通过身份管理(IdM) Web UI 删除 Active Directory (AD)信任关系。此操作会在 IdM 中删除信任配置，同时保留关联的 ID 范围。
要点：先决条件
列表：您已获得 Kerberos ticket。详情请参阅登录到 Web UI 中的 IdM: 使用 Kerberos 票据。
列表：使用管理员权限登录到 IdM Web UI。详情请参阅在 Web 浏览器中访问 IdM Web UI。
列表：在 IdM Web UI 中点 IPA Server 标签页。
列表：在 IPA Server 选项卡中，点 Trusts 标签页。
列表：选择您要删除的信任。
列表：点击 Delete 按钮。
注意：注意删除信任配置不会自动删除已为 AD 用户创建的 ID 范围 IdM。这样，如果您再次添加信任，则重新使用现有的 ID 范围。另外，如果 AD 用户已在 IdM 客户端上创建了文件，则其 POSIX ID 会在文件元数据中保留。要删除与 AD 信任相关的所有信息，请在删除信任配置和信任对象后删除 ID Ranges 选项卡中的 AD 用户 ID 范围。

第 14 章使用 Ansible 删除信任

要点：为确保在身份管理(IdM)环境中进行一致清理，请使用 ipatrust 模块运行 Ansible playbook，以自动删除 Active Directory (AD)信任。
要点：先决条件
列表：您已作为 IdM 管理员获得了 Kerberos 单。详情请参阅登录到 Web UI 中的 IdM: 使用 Kerberos 票据。
列表：您已配置了 Ansible 控制节点以满足以下要求：您在使用 Ansible 版本 2.15 或更高版本。您已安装了 ansible-freeipa 软件包。示例假定在 ~/MyPlaybooks/ 目录中，您已创建了一个具有 IdM 服务器的完全限定域名(FQDN)的 Ansible 清单文件。示例假定 secret.yml Ansible vault 存储了您的 ipaadmin_password，并且您可以访问存储了保护 secret.yml 文件的密码的文件。
列表：您在使用 Ansible 版本 2.15 或更高版本。
列表：您已安装了 ansible-freeipa 软件包。
列表：示例假定在 ~/MyPlaybooks/ 目录中，您已创建了一个具有 IdM 服务器的完全限定域名(FQDN)的 Ansible 清单文件。
列表：示例假定 secret.yml Ansible vault 存储了您的 ipaadmin_password，并且您可以访问存储了保护 secret.yml 文件的密码的文件。
命令/配置摘录：

$ cd ~/MyPlaybooks/
--- - name: Playbook to delete trust  hosts: ipaserver  vars_files:  - /home/user_name/MyPlaybooks/secret.yml  tasks:  - name: ensure the trust is absent  ipatrust:  ipaadmin_password: "{{ ipaadmin_password }}"  realm: ad.example.com  state: absent

注意：注意删除信任配置不会自动删除已为 AD 用户创建的 ID 范围 IdM。这样，如果您再次添加信任，则重新使用现有的 ID 范围。另外，如果 AD 用户已在 IdM 客户端上创建了文件，则其 POSIX ID 会在文件元数据中保留。要删除与 AD 信任相关的所有信息，请在删除信任配置和信任对象后删除 AD 用户 ID 范围： # ipa idrange-del AD.EXAMPLE.COM_id_range # systemctl restart sssd

第 15 章删除对 AD 的信任后删除 ID 范围

要点：手动删除与已删除 Active Directory (AD)信任关联的 ID 范围，以清理身份管理(IdM)配置。此操作会清除系统中未使用的 ID 分配。
要点：先决条件
列表：您已删除了对 AD 环境的信任。
列表：显示所有当前正在使用的 ID 范围： [root@server ~]# ipa idrange-find
列表：识别与您删除的信任相关联的 ID 范围的名称。ID 范围名称的第一部分是信任的名称，如 AD.EXAMPLE.COM_id_range。
列表：删除范围： [root@server ~]# ipa idrange-del AD.EXAMPLE.COM_id_range
列表：重启 SSSD 服务，来删除对您已删除的 ID 范围的引用。 [root@server ~]# systemctl restart sssd
命令/配置摘录：

[root@server ~]# ipa idrange-find
[root@server ~]# ipa idrange-del AD.EXAMPLE.COM_id_range

注意：警告分配给与可信域相关联的 ID 范围的 ID ，可能仍然用于注册到 IdM 的系统上的文件和目录的所有权。如果您删除了与已删除的 AD 信任对应的 ID 范围，则您将无法解析 AD 用户所拥有的任何文件和目录的所有权。

完整目录

管理 IdM 和 AD 域之间的跨林信任
对红帽文档提供反馈
第 1 章建立信任的先决条件
第 2 章 Windows 服务器支持的版本
第 3 章 IdM 和 AD 之间的信任是如何工作的
第 4 章 AD 管理权利
第 5 章确保支持 AD 和 RHEL 中的通用加密类型
第 6 章 IdM 和 AD 间的通信所需的端口
第 7 章为信任配置 DNS 和域设置
- 7.1. 唯一的主 DNS 域
- 7.2. 在 IdM Web UI 中配置 DNS 转发区域
- 7.3. 在 CLI 中配置 DNS 转发区域
- 7.4. 在 AD 中配置 DNS 转发
- 7.5. 验证 DNS 配置
第 8 章在活动目录 DNS 域中配置 IdM 客户端
- 8.1. 配置没有 Kerberos 单点登录的 IdM 客户端
- 8.2. 请求没有单点登录的 SSL 证书
- 8.3. 配置带有 Kerberos 单点登录的 IdM 客户端
- 8.4. 请求带有单点登录的 SSL 证书
第 9 章设置信任
- 9.1. 先决条件
- 9.2. 为信任准备 IdM 服务器
- 9.3. 使用命令行设置信任协议
- 9.4. 在 IdM Web UI 中设置信任协议
- 9.5. 使用 Ansible 设置信任协议
- 9.6. 验证 Kerberos 配置
- 9.7. 验证 IdM 上的信任配置
- 9.8. 验证 AD 上的信任配置
- 9.9. 创建信任代理
- 9.10. 在 CLI 上为 POSIX ID range 启用自动私有组映射
- 9.11. 在 IdM WebUI 中为 POSIX ID range 启用自动私有组映射
第 10 章对设置跨林信任进行故障排除
- 10.1. 建立与 AD 的跨林信任时的事件序列
- 10.2. 建立 AD 信任的先决条件清单
- 10.3. 收集尝试建立 AD 信任的调试日志
第 11 章对客户端访问其他林中的服务进行故障排除
- 11.1. AD 林根域中的主机请求 IdM 服务器的服务时的信息流
- 11.2. AD 子域中的主机请求 IdM 服务器的服务时的信息流
- 11.3. IdM 客户端请求 AD 服务器的服务时的信息流
第 12 章使用命令行删除信任
第 13 章使用 IdM Web UI 删除信任
第 14 章使用 Ansible 删除信任
第 15 章删除对 AD 的信任后删除 ID 范围