您与 Kerberos 的首次联系类似于正常网络系统中的任何登录过程。输入您的用户名。此信息和票证授予服务的名称被发送到身份验证服务器 (Kerberos)。如果身份验证服务器知道您，它将生成一个随机会话密钥，用于您客户端和票证授予服务器之间的进一步使用。现在，身份验证服务器准备一个票证，用于票证授予服务器。该票证包含以下信息——所有都使用身份验证服务器和票证授予服务器都知道的会话密钥进行加密

然后，此票证会连同会话密钥一起发送回客户端，再次以加密形式发送，但这次使用客户端的私钥。此私钥仅为 Kerberos 和客户端所知，因为它源自您的用户密码。现在，客户端收到此响应后，系统会提示您输入密码。此密码转换为可以解密身份验证服务器发送的包的密钥。该包被“解开”，密码和密钥从工作站的内存中删除。只要用于获取其他票证的票证的生存期未过期，您的工作站就可以证明您的身份。

要从网络中的任何服务器请求服务，客户端应用程序需要向服务器证明其身份。因此，应用程序生成一个认证器。认证器由以下组件组成

所有这些信息都使用客户端已经为该特定服务器收到的会话密钥进行加密。认证器和服务器的票证被发送到服务器。服务器使用其会话密钥的副本来解密认证器，这使其获得有关请求其服务的所有客户端的信息，以将其与票证中包含的信息进行比较。服务器检查票证和认证器是否来自同一个客户端。

如果未在服务器端实施任何安全措施，此过程的这一阶段将是重放攻击的理想目标。有人可能会尝试重新发送之前从网络上窃取到的请求。为了防止这种情况，服务器不接受任何带有时间戳和先前收到的票证的请求。与接收请求的时间戳差异过大的请求将被忽略。

Kerberos 身份验证可以在两个方向上使用。这不仅仅是客户端是其声称的身份的问题。服务器也应该能够向请求其服务的客户端证明其身份。因此，它自己发送一个认证器。它将一个添加到它在客户端的认证器中收到的校验和，并使用客户端和服务器之间共享的会话密钥对其进行加密。客户端将此响应视为服务器身份的证明，然后他们开始合作。

票证设计为一次用于一个服务器。因此，每次您请求另一个服务时，都需要获取一个新的票证。Kerberos 实施了一种机制来获取单个服务器的票证。此服务称为“票证授予服务”。票证授予服务是一种服务（如前面提到的任何其他服务），并使用已经概述的访问协议。每当应用程序需要尚未请求的票证时，它都会联系票证授予服务器。此请求由以下组件组成

与任何其他服务器一样，票证授予服务器现在检查票证授予票证和认证器。如果它们被认为有效，票证授予服务器将构建一个新的会话密钥，用于原始客户端和新服务器之间。然后构建新服务器的票证，其中包含以下信息

新票证的生存期是票证授予票证的剩余生存期或服务的默认生存期，以较小者为准。客户端收到此票证和会话密钥，这些票证由票证授予服务发送。但这次，响应使用原始票证授予票证中的会话密钥进行加密。客户端可以在不要求用户密码的情况下解密响应，从而在联系新服务时 Kerberos 可以获取票证。 Kerberos 从而可以在不打扰用户的情况下为客户端获取票证。

任何 Kerberos 环境都必须满足以下要求才能完全正常运行

下图描绘了一个简单的示例网络，其中仅包含构建 Kerberos 基础设施所需的最低组件。根据您的部署规模和拓扑，您的设置可能会有所不同。

图 6.1： Kerberos 网络拓扑 #

提示：配置子网路由

对于类似于图 6.1，“Kerberos 网络拓扑”的设置，配置两个子网（192.168.1.0/24 和 192.168.2.0/24）之间的路由。有关使用 YaST 配置路由的更多信息，请参阅“参考”手册，第 13 章“基本网络”，第 13.4.1.5 节“配置路由”。

Kerberos 安装的域称为领域，并由一个名称标识，例如 EXAMPLE.COM 或简单地 ACCOUNTING。Kerberos 区分大小写，因此 example.com 是一个与 EXAMPLE.COM 不同的领域。使用您喜欢的字母大小写。但是，通常的做法是使用大写领域名称。

使用您的 DNS 域名（或子域名，例如 ACCOUNTING.EXAMPLE.COM）也是一个好主意。如下所示，如果您配置 Kerberos 客户端通过 DNS 查找 KDC 和其他 Kerberos 服务，您的管理员生活可能会更容易。为此，如果您的领域名称是您的 DNS 域名名称的子域名，这将很有帮助。

与 DNS 命名空间不同，Kerberos 不是分层的。因此，如果您有一个名为 EXAMPLE.COM 的领域，其中有两个“子领域”名为 DEVELOPMENT 和 ACCOUNTING，这些子领域不会从 EXAMPLE.COM 继承主体。相反，您将有三个独立的领域，并且需要为每个领域配置跨领域身份验证，以便一个领域中的用户可以与另一个领域中的服务器或其他用户交互。

为了简单起见，我们假设您正在为您的整个组织设置一个领域。在本节的其余部分中，领域名称 EXAMPLE.COM 在所有示例中均使用。

使用 Kerberos 的第一件事是充当密钥分发中心（简称 KDC）的机器。该机器保存包含密码和所有需要进行身份验证的信息的整个 Kerberos 用户数据库。

KDC 是您的安全基础设施中最重要的部分——如果有人攻破它，所有用户帐户以及受 Kerberos 保护的基础设施都将受到损害。访问 Kerberos 数据库的攻击者可以冒充数据库中的任何主体。尽可能加强此机器的安全性

要成功使用 Kerberos，请确保您组织内的所有系统时钟都同步在一定的范围内。这很重要，因为 Kerberos 可以防止重放凭据。攻击者可能能够在网络上观察 Kerberos 凭据并重用它们来攻击服务器。Kerberos 采用多种防御措施来防止这种情况。其中之一是它将时间戳放入其票据中。接收到带有与当前时间不同的时间戳的票据的服务器将拒绝该票据。

Kerberos 允许在比较时间戳时有一定的偏差。但是，计算机时钟在保持时间方面可能不准确——PC 时钟在一周内损失或增加半小时的情况并不罕见。因此，配置网络上的所有主机与中央时间源同步时钟。

一种简单的方法是在一台机器上安装 NTP 时间服务器，并让所有客户端与此服务器同步时钟。通过以客户端身份运行 NTP 守护程序 chronyd 在所有这些机器上执行此操作。KDC 本身也需要与公共时间源同步。由于在此机器上运行 NTP 守护程序会带来安全风险，因此最好通过 cron 作业运行 chronyd -q 来执行此操作。要将您的机器配置为 NTP 客户端，请按照“参考”手册，第 18 章“使用 NTP 进行时间同步”，第 18.1 节“使用 YaST 配置 NTP 客户端”中的说明进行操作。

另一种保护时间服务并仍然使用 NTP 守护程序的方法是将硬件参考时钟连接到专用的 NTP 服务器，并将额外的硬件参考时钟连接到 KDC。

也可以调整 Kerberos 允许在检查时间戳时的时间偏差。此值（称为 时钟偏差）可以在 krb5.conf 文件中设置，如第 6.5.6.3 节，“调整时钟偏差”中所述。

本节涵盖 KDC 的初始配置和安装，包括创建管理主体。此过程包括几个步骤

[libdefaults]
 dns_canonicalize_hostname = false
 rdns = false
 default_realm = example.com
 ticket_lifetime = 24h
 renew_lifetime = 7d

[realms]
  example.com = {
  kdc = kdc.example.com.:88
  admin_server = kdc.example.com
  default_domain = example.com
 }

 [logging]
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
 default = SYSLOG:NOTICE:DAEMON

[domain_realm]
 .example.com = example.com
 example.com = example.com

> sudo kdb5_util create -r EXAMPLE.COM -s

Initializing database '/var/lib/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM',
master key name 'K/M@EXAMPLE.COM'
You are prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:  1
Re-enter KDC database master key to verify:  2

> kadmin.local

kadmin> listprincs

K/M@EXAMPLE.COM
kadmin/admin@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM
krbtgt/EXAMPLE.COM@EXAMPLE.COM

> kadmin.local

kadmin> ank suzanne

suzanne@EXAMPLE.COM's Password: 1
Verifying password: 2

> sudo systemctl start krb5kdc
sudo systemctl start kadmind

> sudo systemctl enable krb5kdc kadmind

当支持基础设施到位（DNS、NTP）并且 KDC 已正确配置并启动后，配置客户端机器。要配置 Kerberos 客户端，请使用下面描述的两种手动方法之一。

在配置 Kerberos 时，您可以采取两种方法：在 /etc/krb5.conf 文件中进行静态配置，或使用 DNS 进行动态配置。使用 DNS 配置时，Kerberos 应用程序尝试使用 DNS 记录查找 KDC 服务。使用静态配置时，将 KDC 服务器的主机名添加到 krb5.conf（并在移动 KDC 或以其他方式重新配置领域时更新该文件）。

基于 DNS 的配置通常更加灵活，并且每台机器上的配置工作量也更少。但是，它要求您的领域名称与您的 DNS 域相同或为其子域。通过 DNS 配置 Kerberos 还会创建一个安全问题：攻击者可以通过您的 DNS（通过关闭名称服务器、欺骗 DNS 记录等）严重破坏您的基础设施。但是，最坏的情况是拒绝服务。除非您在 krb5.conf 中输入 IP 地址而不是主机名，否则静态配置的情况也适用。

[libdefaults]
        default_realm = EXAMPLE.COM

[realms]
        EXAMPLE.COM = {
                kdc = kdc.example.com
                admin_server = kdc.example.com
        }

[domain_realm]
.example.com = EXAMPLE.COM
www.example.org = EXAMPLE.COM

_kerberos.www.example.org.  IN TXT "EXAMPLE.COM"

[libdefaults]
        clockskew = 60

为了能够无需直接访问 KDC 控制台即可向 Kerberos 数据库添加和删除主体，请告知 Kerberos 管理服务器哪些主体被允许执行哪些操作，方法是编辑 /var/lib/kerberos/krb5kdc/kadm5.acl。ACL（访问控制列表）文件允许您以精确的程度指定权限。有关详细信息，请参阅带有 man 8 kadmind 的手册页。

现在，通过将以下行放入文件中，授予您管理数据库的权限

suzanne/admin              *

将用户名 suzanne 替换为您自己的。重新启动 kadmind 以使更改生效。

您现在应该能够使用 kadmin 工具远程执行 Kerberos 管理任务。首先，获取您管理员角色的票证，并在连接到 kadmin 服务器时使用该票证

> kadmin -p suzanne/admin
Authenticating as principal suzanne/admin@EXAMPLE.COM with password.
Password for suzanne/admin@EXAMPLE.COM:
kadmin:  getprivs
current privileges: GET ADD MODIFY DELETE
kadmin:

使用 getprivs 命令，验证您拥有的权限。上面显示的列表是完整的权限集。

例如，修改主体 suzanne

> kadmin -p suzanne/admin
Authenticating as principal suzanne/admin@EXAMPLE.COM with password.
Password for suzanne/admin@EXAMPLE.COM:

kadmin:  getprinc suzanne
Principal: suzanne@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:47:17 CET 2005 (admin/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]

kadmin:  modify_principal -maxlife "8 hours" suzanne
Principal "suzanne@EXAMPLE.COM" modified.
kadmin:  getprinc suzanne
Principal: suzanne@EXAMPLE.COM
Expiration date: [never]
Last password change: Wed Jan 12 17:28:46 CET 2005
Password expiration date: [none]
Maximum ticket life: 0 days 08:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Wed Jan 12 17:59:49 CET 2005 (suzanne/admin@EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin:

这将更改最大票证生存时间为八小时。有关 kadmin 命令和可用选项的更多信息，请参阅 krb5-doc 包或参阅 man 8 kadmin 手册页。

到目前为止，仅讨论了用户凭据。但是，与 Kerberos 兼容的服务还需要向客户端用户证明其身份。因此，Kerberos 数据库中必须为领域中提供的每个服务提供特殊的服务主体。例如，如果 ldap.example.com 提供 LDAP 服务，则需要一个服务主体 ldap/ldap.example.com@EXAMPLE.COM 来向所有客户端证明此服务的身份。

服务主体的命名约定是 SERVICE/HOSTNAME@REALM，其中 HOSTNAME 是主机的完全限定主机名。

有效的服务描述符是

服务主体类似于用户主体，但存在显着差异。用户主体和服务器主体之间的主要区别在于，前者的密钥由密码保护。当用户从 KDC 获取票证授予票证时，他们需要输入密码，以便 Kerberos 可以解密票证。对于系统管理员来说，每八小时获得一次 SSH 守护程序的票证会不方便。

相反，用于解密服务主体的初始票证的密钥仅由管理员从 KDC 提取一次并存储在本地文件（称为 keytab）中。诸如 SSH 守护程序之类的服务读取此密钥并在需要时自动获取新票证。默认 keytab 文件位于 /etc/krb5.keytab。

要为 jupiter.example.com 创建主机服务主体，请在 kadmin 会话期间输入以下命令

> kadmin -p suzanne/admin
Authenticating as principal suzanne/admin@EXAMPLE.COM with password.
Password for suzanne/admin@EXAMPLE.COM:
kadmin:  addprinc -randkey host/jupiter.example.com
WARNING: no policy specified for host/jupiter.example.com@EXAMPLE.COM;
defaulting to no policy
Principal "host/jupiter.example.com@EXAMPLE.COM" created.

与其为新主体设置密码，不如 -randkey 标志告诉 kadmin 生成随机密钥。由于不希望此主体进行任何用户交互，因此在此处使用它。它是一个机器帐户。

最后，将密钥提取并存储在本地 keytab 文件 /etc/krb5.keytab 中。该文件由超级用户拥有，因此您必须是 root 才能在 kadmin shell 中执行下一个命令

kadmin:  ktadd host/jupiter.example.com
Entry for principal host/jupiter.example.com with kvno 3, encryption type Triple
DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/jupiter.example.com with kvno 3, encryption type DES
cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
kadmin:

完成后，请确保使用 kdestroy 销毁上面使用 kinit 获取的管理员票证。

警告：不完整的配置会锁定用户

不完整的 Kerberos 配置可能会将您锁定在系统之外，包括 root 用户。为了防止这种情况，请在将 pam_krb5 模块添加到现有的 PAM 配置文件中后（如下面所述），将 ignore_unknown_principals 指令添加到 pam_krb5 模块 之后。

> sudo pam-config --add --krb5-ignore_unknown_principals

这会指示 pam_krb5 模块忽略否则会导致帐户阶段失败的错误。

openSUSE® Leap 附带一个名为 pam_krb5 的 PAM 模块，它支持 Kerberos 登录和密码更新。此模块可用于控制台登录、su 以及 GDM 等图形登录应用程序等应用程序。也就是说，它可以在用户输入密码并期望身份验证应用程序代表他们获取初始 Kerberos 票据的任何情况下使用。要配置 PAM 对 Kerberos 的支持，请使用以下命令

> sudo pam-config --add --krb5

上述命令将 pam_krb5 模块添加到现有的 PAM 配置文件中，并确保它以正确的顺序调用。要对 pam_krb5 的使用方式进行精确调整，请编辑文件 /etc/krb5.conf 并将默认应用程序添加到 PAM。有关详细信息，请参阅带有 man 5 pam_krb5 的手册页。

特别地，pam_krb5 模块并非专门为接受 Kerberos 票据作为用户身份验证一部分的网络服务而设计的。这是一个完全不同的问题，如下面讨论。

OpenSSH 支持协议版本 1 和 2 中的 Kerberos 身份验证。在版本 1 中，有特殊的协议消息来传输 Kerberos 票据。版本 2 不再直接使用 Kerberos，而是依赖于 GSSAPI（通用安全服务 API）。这是一个编程接口，并非 Kerberos 特有的——它旨在隐藏底层身份验证系统的怪癖，无论是 Kerberos、SPKM 等公钥身份验证系统，还是其他系统。但是，包含的 GSSAPI 库仅支持 Kerberos。

要使用 Kerberos 身份验证的 sshd，请编辑 /etc/ssh/sshd_config 并设置以下选项

# These are for protocol version 1
#
# KerberosAuthentication yes
# KerberosTicketCleanup yes

# These are for version 2 - better to use this
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

然后使用 sudo systemctl restart sshd 重新启动 SSH 守护程序。

要使用协议版本 2 进行 Kerberos 身份验证，也需要在客户端启用它。通过编辑系统范围内的配置文件 /etc/ssh/ssh_config 或在每个用户级别编辑 ~/.ssh/config 来执行此操作。在两种情况下，添加选项 GSSAPIAuthentication yes。

现在您应该可以使用 Kerberos 身份验证进行连接。使用 klist 验证您是否具有有效的票据，然后连接到 SSH 服务器。要强制使用 SSH 协议版本 1，请在命令行中指定 -1 选项。

提示：更多信息

文件 /usr/share/doc/packages/openssh/README.kerberos 更详细地讨论了 OpenSSH 和 Kerberos 的交互。

提示：协议版本 2 的附加指令

支持 GSSAPIKeyExchange 机制 (RFC 4462)。此指令指定如何交换主机密钥。有关更多信息，请参阅 sshd_config 手册页 (man sshd_config)。

虽然 Kerberos 提供身份验证，但 LDAP 用于授权和标识。这两种服务可以协同工作。

为了安全连接，389 Directory Server 支持加密数据的不同方式：SSL/TLS 连接、Start TLS 连接和 SASL 身份验证。简单身份验证和安全层 (SASL) 是一种专为身份验证设计的网络协议。 openSUSE Leap 中使用的 SASL 实现是 cyrus-sasl。Kerberos 身份验证通过 GSS-API（通用安全服务 API）执行，由 cyrus-sasl-gssapi 包提供。使用 GSS-API，389 Directory Server 使用 Kerberos 票据来验证会话并加密数据。

使用 SASL 框架，您可以使用不同的机制将用户身份验证到服务器。在 Kerberos 中，身份验证始终是相互的。这意味着您不仅已向 389 Directory Server 验证了您的身份，而且 389 Directory Server 也已向您验证了其身份。特别是，这意味着通信是与所需的服务器进行的，而不是由攻击者设置的随机服务。

要启用 Kerberos 与 389 Directory Server 绑定，请创建一个主密钥 ldap/ldap.example.com 并将其添加到 keytab。389 Directory Server 用于验证的凭据通过 keytab 提供给其他服务器。389 Directory Server 通过 KRB5_KTNAME 环境变量分配 keytab。

> kinit suzanne@EXAMPLE.COM

> ldapwhoami -Y GSSAPI -H ldap://ldapkdc.example.com
dn: uid=testuser,ou=People,dc=example,dc=com
    

在 sec=sys 和 Kerberos 安全级别之间可能可见的行为差异与组员身份有关。在 Unix 和 Linux 中，每个文件系统访问都来自由特定用户拥有的进程，并具有特定的组所有者和几个辅助组。文件访问权限可以根据所有者和组而变化。

使用 sec=sys，用户 ID、组 ID 和最多 16 个辅助组的列表会发送到服务器中的每个请求。

如果用户是 16 个辅助组以上的成员，则额外的组会丢失，并且用户通常期望可以访问的文件可能无法通过 NFS 访问。出于这个原因，大多数使用 NFS 的站点会找到一种方法来限制所有用户最多使用 16 个辅助组。

如果用户运行 newgrp 命令或运行设置组 ID 的程序，这些程序都可以更改他们所属的组的列表，这些更改会立即生效，并提供不同的 NFS 访问权限。

使用 Kerberos，组信息不会在请求中发送。仅标识用户（使用 Kerberos “主密钥”），服务器执行查找以确定该主密钥的用户 ID 和组列表。这意味着如果用户是 16 个组以上的成员，这些组员身份将用于确定文件访问权限。但是，这也意味着如果用户在客户端上更改组 ID，服务器不会注意到更改，并且不会在确定访问权限时将其考虑在内。

拥有更多组的好处得到了改善，并且无法更改组的损失不被注意到，因为它不常用。考虑使用 Kerberos 的站点管理员应该意识到这种差异，并确保它不会导致问题。

使用 Kerberos 进行安全需要额外的 CPU 功率来加密和解密消息。需要多少额外的 CPU 功率以及差异是否明显取决于不同的硬件和不同的应用程序。如果服务器或客户端已经饱和了可用的 CPU 功率，那么从 sec=sys 切换到 Kerberos 时，可测量的性能下降的可能性很大。如果还有剩余的 CPU 容量，那么过渡可能不会导致任何吞吐量变化。确定 Kerberos 的使用对性能产生的影响的唯一方法是在您的硬件上测试您的负载。

可能减少负载的唯一配置选项也会降低提供的保护质量。 sec=krb5 应该产生明显低于 sec=krb5p 的负载，但如上所述，它不会产生强大的安全性。同样，可以调整 Kerberos 可以选择的密码列表，这可能会改变 CPU 要求。但是，默认值经过精心选择，不应在没有类似仔细考虑的情况下进行更改。

配置 NFS 以使用 Kerberos 涉及的另一个潜在性能问题是 Kerberos 身份验证服务器的可用性，称为 KDC 或密钥分发中心。

将 NFS 添加到负载与添加 Kerberos 用于任何其他服务的负载相同程度。每次给定用户（Kerberos 主密钥）与服务建立会话，例如通过访问特定 NFS 服务器导出的文件时，客户端都需要与 KDC 协商。协商会话密钥后，客户端服务器可以在许多小时内进行通信，而无需进一步的帮助，具体取决于 Kerberos 配置的详细信息，特别是 ticket_lifetime 设置。

最有可能影响 Kerberos KDC 服务器配置的担忧是可用性和峰值使用量。

与 DNS、LDAP 或类似的查找服务等其他核心服务一样，在每个客户端附近提供两个合理 “接近” 的服务器可以为适度的资源提供良好的可用性。Kerberos 允许使用灵活的数据库传播模型使用多个 KDC 服务器，因此根据需要将服务器分布在校园、建筑物甚至机柜中是直接的。确保每个客户端找到附近 Kerberos 服务器的最佳机制是使用拆分视界 DNS，每个建筑物（或类似建筑物）从 DNS 服务器获取不同的详细信息。如果这不可行，那么在不同的位置上管理 /etc/krb5.conf 文件是一个合适的替代方案。

由于访问 Kerberos KDC 的频率较低，负载问题很可能只会在高峰时段出现。如果数千人都在 9:00 到 9:05 之间登录，那么服务器每分钟收到的请求数量将远高于午夜时段。Kerberos 服务器上的负载可能高于 LDAP 服务器，但不会高出几个数量级。一个合理的指导原则是，以与配置 LDAP 副本相同的方式配置 Kerberos 副本，然后监控性能以确定需求是否超过容量。

Kerberos KDC 的一项不容易分布式处理的服务是处理更新，例如密码更改和新用户创建。这些必须在一个主 KDC 上进行。

这些更新不太可能频繁到产生任何显著负载，但可用性可能是一个问题。创建新用户或更改密码可能会令人烦恼，而位于世界另一端的 KDC 主服务器暂时不可用。

当组织在地理上分布且制定了在每个站点本地处理管理任务的策略时，创建多个 Kerberos 域（每个管理中心一个）可能是有益的。每个域将拥有自己的主 KDC，该 KDC 在地理上位于本地。一个域中的用户仍然可以通过在域之间建立信任关系来访问另一个域中的资源。

多个域最简单的配置是拥有一个全局域（例如，EXAMPLE.COM）和本地域（例如，ASIA.EXAMPLE.COM、EUROPE.EXAMPLE.COM）。如果全局域配置为信任每个本地域，并且每个本地域配置为信任全局域，那么任何两个域之间都将提供完全传递的信任，并且任何主体都可以与任何服务建立安全连接。确保对资源的适当访问权限，例如由该服务提供的文件，取决于所使用的用户名查找服务以及 NFS 文件服务器的功能，这超出了本文档的范围。