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] 可用于指定以下用于获取凭证的进程：
- 使用 Realm A 的凭据，客户端从 KDC 域 A 获取
krbtgt/A@Aticket。使用此票据，然后要求提供krbtgt/B@A票据。KDC of Realm A 发布的krbtgt/B@Aticket 是一个跨域票据授予票据。它允许客户端向 Realm B 的 KDC 寻求 Realm B 服务主体的票据。 - 使用
krbtgt/B@A票据时，客户端会要求提供krbtgt/C@B跨域票据。 - 使用 KDC Realm B 发布的
krbtgt/C@Bticket，客户端会要求提供krbtgt/D@C跨域票据。 - 当 KDC 由 Realm C 签发的
krbtgt/D@Cticket 时，客户端会询问 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 选项来分配随机密钥，而不是密码，从第一个域的数据库中转储新条目，并将它导入到第二个域。除非域数据库的主密钥相同，否则这将不起作用，因为数据库转储中包含的密钥本身将使用主密钥进行加密。
