Red Hat Training

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

11.5. 设置跨 Realm Kerberos 信任

Kerberos V5 域是 Kerberos 数据库中在所有连接的主和从设备上定义的一组 Kerberos 主体。如果您希望不同域的主体相互通信，则必须配置跨域 Kerberos 信任关系。
许多 Linux 环境以及混合环境已部署 Kerberos 域，以进行单点登录、应用身份验证和用户管理。这使得 Kerberos 成为不同域和混合系统（如 Windows 和 Linux）环境可能常用的集成路径，特别是 Linux 环境没有使用诸如身份管理这样的结构化域配置。

11.5.1. 信任关系

信任 意味着一个域中的用户信任访问另一域中的资源，就像他们属于该域一样。这可以通过为两个域共同持有的单一主体创建一个共享密钥。

图 11.2. 基本信任

基本信任
在 图 11.2 “基本信任” 中，共享主体将属于域 B (krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM)。如果该主体也添加到 Domain A 中，则 Domain A 中的客户端可以访问 Domain B 中的资源。配置的主体存在于两个域中。该共享主体具有三个特征：
  • 它存在于两个域中。
  • 创建密钥时，两个域中都使用相同的密码。
  • 密钥具有相同的密钥版本号(kvno)。
默认情况下 ，跨域信任是单向 的。这个信任不会被自动恢复，以便 B.EXAMPLE.COM 域被信任以向 A.EXAMPLE.COM 域中的服务进行身份验证。要在其他方向建立信任，这两个域都需要共享 krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM 服务的密钥 - 上例中带有反向映射的条目。
个域可以有多个信任关系，它信任的域和它值得信任的域。借助 Kerberos 信任，信任可以在链中流动。如果 Realm A 信任 Realm B 和 Realm B，则 Realm A 也信任 Realm A。信任流向域；这是 传递 信任。

图 11.3. 传输信任

传输信任
传输信任的方向是 信任流。必须定义信任流，首先识别服务所属的域，然后确定客户端必须联系才能访问该服务的域。
Kerberos 主体名称的结构为 service/hostname@REALM 格式。服务 通常是一个协议，如 LDAP、IMAP、HTTP 或主机。hostname 是主机系统的完全限定域名，REALM 则是 它所属的 Kerberos 域。Kerberos 客户端通常使用主机名或 DNS 域名进行 Kerberos 域映射。此映射可以是显式或隐式的。显式映射使用 /etc/krb5.conf 文件的 [domain_realm] 部分。通过隐式映射，域名将转换为大写；然后，转换的名称假定为要搜索的 Kerberos 域。
遍历信任时，Kerberos 假定每个域的结构与具有根域和子域的分层 DNS 域类似。这意味着信任可以流向共享的根用户。每个步骤或 跃点 都具有共享密钥。在 图 11.4 “同一域中的信任” 中，SALES.EXAMPLE.COM 共享带有 EXAMPLE.COM 的密钥，EXAMPLE.COM 与 EVERYWHERE.EXAMPLE.COM 共享一个密钥。

图 11.4. 同一域中的信任

同一域中的信任
客户端将域名视为 DNS 名称，并且通过剥离其自身域名的元素来确定其信任路径，直至到达根名称。然后开始前置名称，直到到达服务的域。

图 11.5. 相同域中子/优先级信任

相同域中子/优先级信任
信任是传递的本质。SITE.SALES.EXAMPLE.COM 只有一个共享密钥，带有 SALES.EXAMPLE.COM。但因为存在一系列较小的信任关系，因此存在一个很大的信任流，允许信任从 SITE.SALES.EXAMPLE.COM 到 EVERYWHERE.EXAMPLE.COM。
这种信任流程甚至可以在域级别上创建共享密钥，从而完全不同的域之间，其中站点没有共同后缀。

图 11.6. 不同域的信任

不同域的信任

[capaths] 部分

也可以通过明确定义流来减少跃点数和表示非常复杂的信任流。/etc/krb5.conf 文件的 [capaths] 部分定义了不同域之间的信任流。
[capaths] 部分的格式相对简单：每个域都有一个主条目，其中客户端具有主体，然后在每个 realm 部分中是客户端必须获取凭证的中间域列表。
例如，[capaths] 可用于指定以下用于获取凭证的进程：
  1. 使用 Realm A 的凭据，客户端从 KDC 域 A 获取 krbtgt/A@A ticket。使用此票据，然后要求提供 krbtgt/B@A 票据。
    KDC of Realm A 发布的 krbtgt/B@A ticket 是一个跨域票据授予票据。它允许客户端向 Realm B 的 KDC 寻求 Realm B 服务主体的票据。
  2. 使用 krbtgt/B@A 票据时，客户端会要求提供 krbtgt/C@B 跨域票据。
  3. 使用 KDC Realm B 发布的 krbtgt/C@B ticket，客户端会要求提供 krbtgt/D@C 跨域票据。
  4. 当 KDC 由 Realm C 签发的 krbtgt/D@C ticket 时，客户端会询问 KDC D 以获得 Realm D 的票据，以便在 Realm D 中进入服务主体。
之后，凭据缓存包含 krbtgt/A@A、krbtgt/B@A、krbtgt/C@B、krbtgt/D@C 以及 service/hostname@D 的票据。要获得 service/hostname@D ticket，需要获取三个中间跨域票据。
有关 [capaths] 部分的详情，包括 [capaths] 配置示例，请参阅 krb5.conf(5) man page。

11.5.2. 设置 Realm Trust

在本例中，Kerberos 域是 A.EXAMPLE.COM 和 B.EXAMPLE.COM。
使用 kadmin 为 A 域中 B 域的共享主体创建条目。 
[root@server ~]# kadmin -r A.EXAMPLE.COM
kadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM
Enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM":
Re-enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM":
Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created.
quit
这意味着 A realm 将信任 B 主体。
重要
建议您为跨域主体选择非常强大的密码。与许多其他密码不同，用户可以如此频繁地在一天中多次提示用户，系统不会要求您频繁地请求输入跨域主体的密码，这就是为什么它不需要易于记忆的原因。
要建立双向信任，请按照相反的方式创建主体。使用 kadmin 为 B realm 中的 A 域创建主体。 
[root@server ~]# kadmin -r B.EXAMPLE.COM
kadmin: add_principal krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM
Enter password for principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM":
Re-enter password for principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM":
Principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM" created.
quit
使用 get_principal 命令来验证这两个条目是否具有匹配的密钥版本号(kvno 值)和加密类型。
重要
一个常见，但不正确的情况是管理员尝试使用 add_principal 命令的 -randkey 选项来分配随机密钥，而不是密码，从第一个域的数据库中转储新条目，并将它导入到第二个域。除非域数据库的主密钥相同，否则这将不起作用，因为数据库转储中包含的密钥本身将使用主密钥进行加密。