6 使用 Kerberos 进行网络身份验证 #

在首次接触 Kerberos 时，您的操作与在常规网络系统进行的任何登录过程类似。输入您的用户名。这一信息和票据授权服务的名称被发送到身份验证服务器 (Kerberos)。如果身份验证服务器知道您的身份，它会生成一个随机会话密钥，供以后在客户端和票据授权服务器之间使用。身份验证服务器现在将为票据授权服务器准备一个票据。该票据包含以下信息 － 仅认证服务器和票据授权服务器知道的、由会话密钥加密的所有信息：

随后，还是以加密形式将此票据与会话密钥一起发送回客户端，但这次使用的是客户端的私用密钥。只有 Kerberos 和客户端知道此私用密钥，因为它是从您的用户口令派生的。由于客户端已经收到了此响应，计算机将提示您输入口令。此口令被转换为一个密钥，利用它可解密身份验证服务器所发送的包。然后“拆封”此包，并将口令和密钥从工作站的内存中删除。只要没有超过为用于获取其他票据的那个票据指定的有效期，工作站就能证明您的身份。

要从网络中的任何服务器请求服务，客户端应用程序都需要向服务器证明其身份。因此，此应用程序生成一个身份验证器。身份验证器包含以下部分：

所有这些信息都使用客户端为这个特殊服务器接收到的会话密钥进行了加密。用于服务器的身份验证器和票据会被发送到该服务器。该服务器使用自身的会话密钥副本来解密身份验证器，而身份验证器为它提供与请求其服务的客户端相关的全部所需信息，然后服务器将这些信息与票据中包含的信息进行对比。服务器将检查票据和身份验证器是否来自同一客户端。

如果在服务器端没有采取任何安全措施，则这个阶段的过程将成为重放攻击的理想目标。某些人可能试图重发先前从网络上窃取的请求。为防止出现这种情况，服务器将不接受具有先前已收到过的时间戳和票据的任何请求。此外，忽略时间戳与接收请求时的时间相差太大的请求。

Kerberos 身份验证可以双向使用。它不仅可以验证客户端是否为它所声称的客户端，服务器本身也应能够向请求其服务的客户端身份验证自己。因此，它本身会发送身份验证器。它将在客户端的身份验证器中接收的校验和加 1，然后使用它和客户端共享的会话密钥对其加密。客户端将此响应作为对服务器的真实性的校验，然后它们开始协作。

票据每次仅供一个服务器使用。因此，每当您请求另一个服务时，就需要获取一个新票据。Kerberos 实施了一种机制来获取用于各个服务器的票据。这种服务被称为“票据授权服务”。票据授权服务与前面提到的任何服务一样，也使用已介绍过的相同访问协议。当应用程序需要一个尚未请求过的票据时，就会联系票据授权服务器。此请求包含以下部分：

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

新票据具有一个有效期，该有效期是票据授权票据的剩余有效期，或服务的默认有效期。系统将指派这两个值中较小的一个。客户端会接收票据授权服务发送的此票据和会话密钥。但这一次，响应已通过原始票据授权票据附带的会话密钥加密。当联系新服务时，客户端可以解密此响应而不需要用户的口令。因此，Kerberos 无需烦扰用户就能获取客户端的一个又一个票据。

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

下图描绘了一个简单的示例网络，其中仅包含构建 Kerberos 基础结构至少所需的组件。根据您的部署大小和拓扑，您的设置可能与此不同。

图 6.1︰ Kerberos 网络拓扑 #

 

提示：配置子网路由

对于类似于图 6.1 “Kerberos 网络拓扑”中所示的设置，需在两个子网（192.168.1.0/24 和 192.168.2.0/24）之间配置路由。有关使用 YaST 配置路由的详细信息，请参见第 19.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 继承主体。相反，您拥有的是三个独立的领域，并需要为每个领域配置跨领域的身份验证，使一个领域中的用户能够与另一个领域中的服务器或其他用户交互。

为了便于说明，假设您只为整个组织设置一个领域。在本章剩余部分中，将在所有示例中使用领域名 SAMPLE.COM。

要使用 Kerberos，首先需要一台用作密钥分发中心（或简称 KDC）的计算机。这台计算机将储存整个 Kerberos 用户数据库，其中包含口令和所有信息。

KDC 是安全基础设施中最重要的部分 － 如果有人侵入，则 Kerberos 保护的所有用户帐户和基础设施都会受到损害。能够访问 Kerberos 数据库的攻击者可以冒充数据库中的任何主体。所以应尽可能提高此计算机的安全性：

要成功使用 Kerberos，应确保您的组织内的所有系统时钟都在给定范围内同步。这一点非常重要，因为 Kerberos 需要防范重放的身份凭证。攻击者可能会在网络上获取 Kerberos 身份凭证，并再使用它们来攻击服务器。Kerberos 采取多种保护措施进行防范。其中之一是在它们的票据中放入时间戳。如果服务器收到的票据的时间戳与当前时间不同，就会拒绝此票据。

Kerberos 在比较时间戳时允许一定的偏差。但计算机时钟的走时可能非常不准确 — 在一周内快或慢半个小时并不罕见。因此，应对网络上的所有主机进行配置，使它们的时钟与中央时间源同步。

要实现此目的，一种简单的方法就是在一台计算机上安装 NTP 时间服务器，并使所有客户端的时钟与该服务器同步。为此，请在所有这些计算机上以客户端的身份运行 NTP 守护程序 chronyd。KDC 本身也需要与公用时间源同步。由于在此计算机上运行 NTP 守护程序会有安全风险，通过 cron 作业运行 chronyd -q 执行此操作可能是个不错的选择。要将您的机器配置成 NTP 客户端，如第 30.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

tux > 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 will be 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

tux > kadmin.local

kadmin> listprincs

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

tux > kadmin.local

kadmin> ank geeko

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

tux > sudo systemctl start krb5kdc
sudo systemctl start kadmind

tux > 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 数据库添加和去除主体，请编辑 /var/lib/kerberos/krb5kdc/kadm5.acl 以告知 Kerberos 管理服务器要允许哪些主体执行哪些操作。ACL（访问控制列表）文件可让您以精确的控制度指定特权。有关详细信息，请使用 man 8 kadmind 来参考手册页。

目前请通过在该文件中插入以下一行向您自己授予管理数据库的特权：

geeko/admin              *

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

您现在应该能够使用 kadmin 工具远程执行 Kerberos 管理任务。首先，为您的 admin 角色获得一个票据，并在连接到 kadmin 服务器时使用此票据：

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

使用 getprivs 命令验证您有哪些特权。上面的列表中列出了全部特权。

例如，修改主体 geeko：

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

kadmin:  getprinc geeko
Principal: geeko@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" geeko
Principal "geeko@EXAMPLE.COM" modified.
kadmin:  getprinc geeko
Principal: geeko@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 (geeko/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:

这将票据的最长生命周期更改为 8 小时。有关 kadmin 命令和可用选项的详细信息，请参见 krb5-doc 软件包或 man 8 kadmin 手册页。

到目前为止，我们仅讨论了用户身份凭证。但与 Keberos 兼容的服务通常也需要将它们自己认证到客户端。因此，对于领域中提供的每个服务，Kerberos 数据库中必须存在特殊的服务主体。例如，如果 ldap.example.com 提供 LDAP 服务，您将需要一个服务主体 ldap/ldap.example.com@EXAMPLE.COM，以使此服务向所有客户端验证身份。

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

有效的服务描述符为：

服务主体类似于用户主体，但存在一些重大差别。用户主体与服务主体之间的主要差别在于，前者的密钥受口令保护。当用户从 KDC 获取票据授权票据时，他们需要键入其口令，以使 Kerberos 能够解密该票据。如果系统管理员大约每 8 小时就必须为 SSH 守护程序获取一次新的票据，将会很不方便。

实际上，用来解密服务主体的初始票据的密钥是由管理员从 KDC 一次性提取的，并储存在名为 keytab 的本地文件中。SSH 守护程序等服务将读取此密钥并在需要时使用它来自动获取新票据。默认 keytab 文件位于 /etc/krb5.keytab 中。

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

tux > kadmin -p geeko/admin
Authenticating as principal geeko/admin@EXAMPLE.COM with password.
Password for geeko/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 获得的 admin 票据。

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

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

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

这会指示 pam_krb5 模块忽略某些错误，如不忽略，帐户阶段将会失败。

SUSE® Linux Enterprise Server 随附了一个名为 pam_krb5 的 PAM 模块，该模块支持 Kerberos 登录和口令更新。su 等控制台登录应用程序以及 GDM 等图形登录应用程序可以使用此模块。也就是说，在希望用户输入口令后由身份验证应用程序代表其获取初始 Kerberos 票据的所有场合，都可以使用此模块。要为 Kerberos 配置 PAM 支持，请使用下面的命令：

tux > sudo pam-config --add --krb5

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

pam_krb5 模块的设计特意不用于接受 Kerberos 票据作为部分用户身份验证的网络服务。这一点很特别，后面将会讨论。

OpenSSH 在协议版本 1 和 2 中均支持 Kerberos 身份验证。在版本 1 中，会通过特殊协议消息传输 Kerberos 票据。版本 2 不再直接使用 Kerberos，而是依赖于 GSSAPI，即通用安全服务 API.这是一种不特定于 Kerberos 的编程接口 － 其设计目的是隐藏基础身份验证系统的特性，无论它是 Kerberos、公共密钥认证系统（如 SPKM）还是其他系统。但是，包含的 GSSAPI 库仅支持 Kerberos。

要将 sshd 与 Kerberos 身份验证一起使用，请编辑 /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 守护程序。

要将 Kerberos 认证与协议版本 2 一起使用，需要在客户端也启用它。此操作可在整个系统范围的配置文件 /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 目录服务器支持以不同的方式加密数据：SSL/TLS 连接、启动 TLS 连接和 SASL 身份验证。简单身份验证和安全层 (SASL) 是用于进行身份验证的网络协议。在 SUSE Linux Enterprise Server 中使用的 SASL 实现是 cyrus-sasl。Kerberos 身份验证是通过 GSS-API（常规安全服务 API）执行的，在 cyrus-sasl-gssapi 包中提供。389 目录服务器通过 GSS-API 使用 Kerberos 票据对会话进行身份验证和加密数据。

借助 SASL 框架，您可以使用不同的机制向服务器验证用户的身份。在 Kerberos 中，身份验证永远是相互的。这表示您不仅向 389 目录服务器验证了您自己的身份，389 目录服务器本身也向您验证了它的身份。具体而言，这表示您是与所需的服务器而不是攻击者设置的随机服务进行通讯。

为了使 Kerberos 能够绑定到 389 目录服务器，请创建一个主体 ldap/ldap.example.com 并将其添加到 keytab。389 目录服务器用来进行身份验证的身份凭证将由 keytab 提供给其他服务器。389 目录服务器通过 KRB5_KTNAME 环境变量指派 keytab。

tux > kinit geeko@EXAMPLE.COM

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

sec=sys 与各种 Kerberos 安全级别之间的一个可以察觉到的行为差异与组成员资格相关。在 Unix 和 Linux 中，每个文件系统访问请求都来自某个进程，该进程由特定的用户拥有，并具有特定的组拥有者和多个补充组。对文件的访问权限因拥有者和各个组而异。

在每个请求中，使用 sec=sys 将 user-id、group-id 以及最多包含 16 个补充组的列表发送到服务器。

如果某个用户是 16 个以上的补充组的成员，超额的组将会丢失，并且在正常情况下用户本应可以访问的某些文件可能无法通过 NFS 访问。因此，使用 NFS 的大多数站点会通过某种方法将所有用户限制为最多 16 个补充组。

如果用户运行 newgrp 命令或运行 set-group-id 程序，并且该命令或程序可以更改用户所属的组列表，则这些更改会立即生效，并提供 NFS 上的不同访问权限。

使用 Kerberos 时，请求中不会发送组信息。只会标识用户（使用 Kerberos “主体”），服务器将执行查找来确定该主体的用户 ID 和组列表。这意味着，如果用户是 16 个以上的组的成员，则会使用所有这些组成员资格来确定文件访问权限。但也意味着，如果用户在客户端上以某种方式更改 group-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。通过在域之间设置信任关系，一个域中的用户仍可访问另一个域中的资源。

要安排多个域，最轻松的方式是使用一个全局域（例如 EXAMPLE.COM）和不同的本地域（例如 ASIA.EXAMPLE.COM、EUROPE.EXAMPLE.COM）。如果全局域配置为信任每个本地域，并且每个本地域配置为信任全局域，则任何一对域之间都将具有完全可传递的信任，并且任何主体都可以与任何服务建立安全连接。如何确保对资源（例如该服务提供的文件）的适当访问权限将取决于所用的用户名查找服务，以及 NFS 文件服务器的功能，这不在本文档的范畴内。