跳到内容跳到页面导航:上一页 [access key p]/下一页 [access key n]
documentation.suse.com / SUSE Linux Enterprise Server 文档 / 安全和强化指南 / 身份验证 / 使用 Kerberos 进行网络身份验证
适用范围 SUSE Linux Enterprise Server 15 SP3

7 使用 Kerberos 进行网络身份验证

Kerberos 是一个网络身份验证协议,同时还提供加密。本章介绍如何设置 Kerberos 以及集成 LDAP 和 NFS 等服务。

7.1 概念概述

除了通常的口令机制外,开放网络没有提供任何其他方法来确保工作站能够正确识别其用户。在一般的安装中,用户每次访问网络中的服务时都必须输入口令。Kerberos 提供了一种身份验证方法,采用这种方法,用户只要注册一次,就可在整个网络中获得信任以完成会话的剩余操作。要拥有安全的网络,必须满足以下要求:

  • 使所有用户可以对每个所需服务证明他们自己的身份,并确保任何用户都不能使用其他用户的身份。

  • 确保每个网络服务器也能证明其身份。否则攻击者就可能冒充服务器并获取传送给服务器的敏感信息。这种概念被称为相互身份验证,因为在客户端和服务器之间进行了相互身份验证。

Kerberos 通过提供严格加密的认证来帮助您满足这些要求。这里仅讨论 Kerberos 的基本原理。有关详细技术说明,请参见 Kerberos 文档。

7.2 Kerberos 术语

以下词汇表定义了一些 Kerberos 术语。

身份凭证

用户或客户端需要提供某种身份凭证才能获得授权来请求服务。Kerberos 支持两种身份凭证 - 票据和身份验证器。

票据

票据是随服务器而不同的身份凭证,客户端使用票据向它请求提供服务的服务器进行身份验证。它包含服务器的名称、客户端的名称、客户端的因特网地址、时戳、有效期和随机会话密钥。所有这些数据都使用服务器的密钥进行了加密。

身份验证器

身份验证器与票据结合使用,可用于证明提供票据的客户端确实与其声称的身份相符。身份验证器是使用客户端的名称、工作站的 IP 地址和当前工作站的时间(所有这些信息都通过只有客户端和相关服务器知道的会话密钥加密)构建的。与票据不同,身份验证器只能使用一次。客户端可以自己构建身份验证器。

主体

Kerberos 主体是可以对其指派票据的独特实体(用户或服务)。主体包含以下部分:

USER/INSTANCE@REALM
  • primary: 主体的第一个部分。对于用户,这通常与用户名相同。

  • instance(可选):: 描述 primary 特征的附加信息。此字符串与 primary 之间通过一个 / 分隔。

    tux@example.orgtux/admin@example.org 可以存在于同一个 Kerberos 系统上,它们被视为不同的主体。

  • realm:: 指定 Kerberos 领域。通常情况下,领域就是您的大写域名。

相互身份验证

Kerberos 确保客户端和服务器都可以确认对方的身份。它们共享一个可用来安全通讯的会话密钥。

会话密钥

会话密钥是由 Kerberos 生成的临时私用密钥。客户端知道这些密钥。当客户端向服务器请求并收到票据后,将使用这些密钥来加密客户端和服务器之间的通讯。

重放

几乎所有在网络中发送的消息都能够被窃听、盗取和重发送。在使用 Kerberos 的情况下,如果攻击者获取了包含您的票据和身份验证器的服务请求,则会非常危险。攻击者随后可能会试图重新发送此请求(重放)来冒充您。然而,Kerberos 实施了多种机制来应对此问题。

服务器或服务

服务用来指要执行的特定操作。此操作幕后的进程称为服务器

7.3 Kerberos 的工作原理

Kerberos 常常被称为第三方可信身份验证服务,这意味着其所有客户端都信任 Kerberos 对另一个客户端身份的判断。Kerberos 保存着一个包含它的所有用户及其私用密钥的数据库。

为确保 Kerberos 正常工作,请在专用计算机上运行身份验证和票据授权服务器。确保只有管理员能直接或通过网络访问此计算机。将此计算机上运行的(网络)服务数目降到最低 — 甚至不要运行 sshd

7.3.1 首次联系

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

  • 客户端和票据授权服务器的名称

  • 当前时间

  • 为此票据指派的有效期

  • 客户端的 IP 地址

  • 新生成的会话密钥

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

7.3.2 请求服务

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

  • 客户端的主体

  • 客户端的 IP 地址

  • 当前时间

  • 校验和(由客户端选择)

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

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

7.3.3 相互身份验证

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

7.3.4 票据授予 - 联系所有服务器

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

  • 被请求的主体

  • 票据授权票据

  • 认证器

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

  • 客户端的主体

  • 服务器的主体

  • 当前时间

  • 客户端的 IP 地址

  • 新生成的会话密钥

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

7.4 Kerberos 的用户视图

理想情况下,用户与 Kerberos 的唯一接触是在工作站登录时发生的。登录进程包括获得一个票据授权票据。注销时,用户的 Kerberos 票据会自动损坏,这样其他人就不能模仿该用户。

当用户的登录会话持续时间超过为票据授权票据指定的最长时间限制(合理的设置是 10 小时)时,票据的自动失效可能会造成某种不便。但用户可以通过运行 kinit 来获得一个新的票据授权票据。再次输入口令,Kerberos 无需附加身份验证即可获得对所需服务的访问。要获得由 Kerberos 为您静默获取的所有票据的列表,请运行 klist

下面的短列表列出了使用 Kerberos 身份验证的应用程序。安装 krb5-apps-clients 软件包后,可在 /usr/lib/mit/bin/usr/lib/mit/sbin 下找到这些应用程序。它们拥有普通 Unix 和 Linux 应用程序的所有功能,同时具有 Kerberos 管理的透明身份验证的优势:

  • telnettelnetd

  • rlogin

  • rshrcprshd

  • ftpftpd

  • ksu

您不再需要输入口令即可使用这些应用程序,因为 Kerberos 已证明您的身份。如果为其编译了 Kerberos 支持,ssh 甚至可以将为一个工作站获取的所有票据转发到另一个工作站。如果您使用 ssh 登录到另一个工作站,ssh 将确保票据的加密内容会根据新情况而调整。仅在工作站之间复制票据是不够的,因为票据中包含工作站特定信息(IP 地址)。XDM 和 GDM 也提供 Kerberos 支持。请阅读 https://web.mit.edu/kerberos 上的《Kerberos V5 UNIX User's Guide》(Kerberos V5 UNIX 用户指南)中有关 Kerberos 网络应用程序的详细信息。

7.5 安装和管理 Kerberos

Kerberos 环境由多个组件构成。密钥分发中心 (KDC) 用于容纳中心数据库,该数据库包含所有 Kerberos 相关数据。所有客户端均依赖于 KDC 在整个网络中正确进行身份验证。KDC 和客户端都需要配置为与您的设置相匹配:

一般准备工作

检查网络设置,确保它符合第 7.5.1 节 “Kerberos 网络拓扑”中所述的最低要求。为 Kerberos 设置选择适当的领域,请参见第 7.5.2 节 “选择 Kerberos 领域”。谨慎设置要充当 KDC 的计算机并应用严格的安全策略,请参见第 7.5.3 节 “设置 KDC 硬件”。在网络中设置可靠的时间源以确保所有票据都包含有效时戳,请参见第 7.5.4 节 “配置时间同步”

基本配置

配置 KDC 和客户端,请参见第 7.5.5 节 “配置 KDC”第 7.5.6 节 “配置 Kerberos 客户端”。启用 Kerberos 服务的远程管理,这样您就无需对 KDC 计算机进行物理访问,请参见第 7.5.7 节 “配置远程 Kerberos 管理”。为领域中的每个服务创建服务主体,请参见第 7.5.8 节 “创建 Kerberos 服务主体”

启用 Kerberos 身份验证

网络中的各种服务都可以使用 Kerberos。要使用 PAM 在应用程序中添加 Kerberos 口令检查,请按第 7.5.9 节 “对 Kerberos 启用 PAM 支持”中所述操作。要使用 Kerberos 身份验证配置 SSH 或 LDAP,请按第 7.5.10 节 “配置 SSH 进行 Kerberos 身份验证”第 7.5.11 节 “使用 LDAP 和 Kerberos”中所述操作。

7.5.1 Kerberos 网络拓扑

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

  • 提供用于在网络中进行名称解析的 DNS 服务器,以便客户端和服务器能够找到彼此。有关 DNS 设置的信息,请参见第 31 章 “域名系统

  • 在网络中提供一个时间服务器。使用准确的时戳对于 Kerberos 设置而言至关重要,因为有效的 Kerberos 票据必须包含正确的时戳。有关 NTP 设置的信息,请参见第 30 章 “使用 NTP 同步时间

  • 提供一个密钥分发中心 (KDC) 作为 Kerberos 体系结构的中心组件。KDC 用于容纳 Kerberos 数据库。在此计算机上使用尽可能最严格的安全策略,以防止此计算机上的任何攻击破坏整个基础结构。

  • 将客户端计算机配置为使用 Kerberos 身份验证。

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

Kerberos 网络拓扑
图 7.1︰ Kerberos 网络拓扑
提示
提示:配置子网路由

对于类似于图 7.1 “Kerberos 网络拓扑”中所示的设置,需在两个子网(192.168.1.0/24 和 192.168.2.0/24)之间配置路由。有关使用 YaST 配置路由的详细信息,请参见第 19.4.1.5 节 “配置路由”

7.5.2 选择 Kerberos 领域

Kerberos 安装的域称为领域,通过一个名称(如 EXAMPLE.COM 或简单的 ACCOUNTING)来标识。Kerberos 区分大小写,因此 example.com 实际上是与 EXAMPLE.COM 不同的领域。您可根据自己的偏好选择使用大小写。但通常的做法是使用大写领域名。

使用您的 DNS 域名(或子域,如 ACCOUNTING.EXAMPLE.COM)也是个不错的选择。如下所示,如果将 Kerberos 客户端配置为通过 DNS 来查找 KDC 和其他 Kerberos 服务,则系统管理员的工作就轻松多了。要做到这一点,将领域名设为 DNS 域名的子域会很有帮助。

与 DNS 名称空间不同,Kerberos 是不分级的。因此,如果您有一个名为 EXAMPLE.COM 的领域,该领域包含名为 DEVELOPMENTACCOUNTING 的两个子领域,这些从属领域不会从 EXAMPLE.COM 继承主体。相反,您拥有的是三个独立的领域,并需要为每个领域配置跨领域的身份验证,使一个领域中的用户能够与另一个领域中的服务器或其他用户交互。

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

7.5.3 设置 KDC 硬件

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

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

  1. 将服务器计算机放在一个以物理方式保护的位置,如只有极少数人才可进入的加锁服务器室。

  2. 除了 KDC 以外,不要在其上运行任何网络应用程序。其中包括服务器和客户端- 例如,KDC 不应通过 NFS 导入任何文件系统或使用 DHCP 检索其网络配置。

  3. 首先安装最小系统,然后检查已安装的软件包列表并除去任何不需要的软件包。其中包括服务器,如 inetdportmap、CUPS 以及任何基于 X 的软件。甚至安装 SSH 服务器也应该视为潜在的安全风险。

  4. 在此计算机上不提供图形登录,因为 X 服务器具有潜在的安全风险。Kerberos 提供它自己的管理界面。

  5. /etc/nsswitch.conf 配置为仅使用本地文件来进行用户和组查找。将 passwdgroup 的行进行如下更改:

    passwd:         files
    group:          files

    编辑 /etc 中的 passwdgroupshadow 文件,并去除任何以 + 字符开头的行(这些行用于 NIS 查找)。

  6. 禁用 root 帐户以外的所有其他用户帐户,方法是编辑 /etc/shadow 并将哈希口令替换为 *! 字符。

7.5.4 配置时间同步

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

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

要实现此目的,一种简单的方法就是在一台计算机上安装 NTP 时间服务器,并使所有客户端的时钟与该服务器同步。为此,请在所有这些计算机上以客户端的身份运行 NTP 守护程序 chronyd。KDC 本身也需要与公用时间源同步。由于在此计算机上运行 NTP 守护程序会有安全风险,通过 cron 作业运行 chronyd -q 执行此操作可能是个不错的选择。要将您的机器配置成 NTP 客户端,如第 30.1 节 “使用 YaST 配置 NTP 客户端”中概述的那样继续操作。

另一种保护时间服务并仍旧使用 NTP 守护程序的做法是,将一个硬件参考时钟挂接到专用的 NTP 服务器,并将另一个硬件参考时钟挂接到 KDC。

也可以调整 Kerberos 在检查时间戳时所允许的最大偏差。此值(称为时钟扭斜)可以在 krb5.conf 文件中进行设置,请参见第 7.5.6.3 节 “调整时钟偏差”一节。

7.5.5 配置 KDC

本节介绍 KDC 的初始配置和安装,包括创建管理主体。此过程包括几个步骤:

  1. 安装 RPM: 在指定用作 KDC 的计算机上安装 krb5krb5-serverkrb5-client 软件包。

  2. 调整配置文件: 必须根据您的方案调整 /etc/krb5.conf/var/lib/kerberos/krb5kdc/kdc.conf 配置文件。这些文件 KDC 上的所有信息。请参见第 7.5.5.1 节 “配置服务器”

  3. 创建 Kerberos 数据库: Kerberos 保持所有主体标识和需要被认证的所有主体密码的数据库。有关详细信息,请参考 第 7.5.5.2 节 “设置数据库”

  4. 调整 ACL 文件:添加管理员: 可以远程管理 KDC 上的 Kerberos 数据库。要防止未授权的主体篡改数据库,Kerberos 使用访问控制列表。必须为管理员主体显式启用远程访问,以使其能够管理数据库。Kerberos ACL 文件位于 /var/lib/kerberos/krb5kdc/kadm5.acl 下。有关详细信息,请参考 第 7.5.7 节 “配置远程 Kerberos 管理”

  5. 调整 Kerberos 数据库:添加管理员: 您至少需要一个管理主体来运行和管理 Kerberos。必须在启动 KDC 之前添加了该主体。有关详细信息,请参考 第 7.5.5.3 节 “创建主体”

  6. 启动 Kerberos 守护程序: 安装并正确配置 KDC 软件后,启动 Kerberos 守护程序以便为您的领域提供 Kerberos 服务。有关详细信息,请参考 第 7.5.5.4 节 “启动 KDC”

  7. 为您自己创建主体: 您自己需要一个主体。有关详细信息,请参考 第 7.5.5.3 节 “创建主体”

7.5.5.1 配置服务器

Kerberos 服务器的配置存在很多的变数,涉及到您的网络体系结构、DNS 和 DHCP 配置、领域及其他考虑因素。您必须准备好一个默认领域以及域到领域的映射。下面的示例演示了一个极简配置。这并非复制粘贴而来的示例;有关 Kerberos 配置的详细信息,请参见 https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/index.html

例 7.1︰ 示例 KDC 配置 /etc/krb5.conf
[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

7.5.5.2 设置数据库

下一步是初始化 Kerberos 用来保存所有主体信息的数据库。设置数据库主密钥,此密钥用于防范数据库意外泄漏(特别是当它备份到磁带时)。主密钥是从通行口令派生的,储存在称为暂存文件的文件中。这就是您每次重启动 KDC 时无需键入口令的原因。确保选择一个适当的通行密码,如从一本书随机打开的一页中找出的一句话。

在对 Kerberos 数据库 (/var/lib/kerberos/krb5kdc/principal) 进行磁带备份时,切勿备份暂存文件(它位于 /var/lib/kerberos/krb5kdc/.k5.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

1

Type the master password.

2

再次键入口令。

要进行校验,请使用 list 命令:

tux > kadmin.local

kadmin> listprincs

您将看到数据库中的多个主体,这些主体供 Kerberos 内部使用:

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

7.5.5.3 创建主体

为自己创建两个 Kerberos 主体,一个常规主体用于日常工作,另一个用于与 Kerberos 相关的管理任务。假设您的登录名是 geeko,请执行以下操作:

tux > kadmin.local

kadmin> ank geeko

您将看到以下输出:

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

1

键入 geeko 的口令。

1

再次键入 geeko 的口令。

接下来,在 kadmin 提示符处键入 add geeko/admin 以创建名为 geeko/admin 的另一个主体。您的用户名的 admin 后缀指定了您的角色。稍后在管理 Kerberos 数据库时将使用此角色。一个用户可以有用于不同目的的多个角色。角色的作用就像名称类似但彼此完全不同的帐户。

7.5.5.4 启动 KDC

启动 KDC 守护程序和 Kadmin 守护程序。要手动启动守护程序,请输入:

tux > sudo systemctl start krb5kdc
sudo systemctl start kadmind

另请确保在服务器计算机重引导时,默认会启动服务 KDC (krb5kdc) 和 kadmind (kadmind)。请输入以下命令启用这些服务:

tux > sudo systemctl enable krb5kdc kadmind

或使用 YaST 服务管理器来启用。

7.5.6 配置 Kerberos 客户端

当已部署好支持基础结构(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 地址而非主机名,否则静态配置也会发生相同的情况。

7.5.6.1 静态配置

一种配置 Kerberos 的方法是编辑 /etc/krb5.conf。默认安装的文件中包含多个示例项。在开始之前,请擦除所有这些项。krb5.conf 由多个部分(段落)构成,每个部分通过括在方括号中的部分名称引入,类似于 [this]

要配置 Kerberos 客户端,请将下面的段落添加到 krb5.conf(其中 kdc.example.com 是 KDC 的主机名)中:

[libdefaults]
        default_realm = EXAMPLE.COM

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

default_realm 行设置了 Kerberos 应用程序的默认领域。如果您有多个领域,请在 [realms] 部分添加附加语句。

此外还要向此文件添加一个语句,指示应用程序如何将主机名映射到领域。例如,当连接到远程主机时,Kerberos 库需要知道此主机位于哪个领域中。必须在 [domain_realms] 节中对此进行配置:

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

此语句向库说明 example.com DNS 域中的所有主机均位于 SAMPLE.COM Kerberos 领域中。此外,还应将一个名为 www.example.org 的外部主机视为 EXAMPLE.COM 领域的成员。

7.5.6.2 基于 DNS 的配置

基于 DNS 的 Kerberos 配置大量使用 SRV 记录。请参见 (RFC2052) 用于指定服务位置的 DNS RR,网址是 http://www.ietf.org

对于 Kerberos 而言,SRV 记录的名称始终采用 _service._proto.realm 格式,其中 realm 是 Kerberos 领域。DNS 中的域名不区分大小写,因此当使用这种配置方法时,Kerberos 领域将无法再区分大小写。_service 是一个服务名(例如当尝试联系 KDC 或密码服务时会使用不同的名称)。_proto 可以是 _udp_tcp,但不是所有服务都支持这两种协议。

SRV 资源记录的数据部分包括一个优先级值、一个权重、一个端口号和一个主机名。优先级确定了主机被尝试的顺序(值越低则优先级越高)。权重值用于支持在优先级相同的服务器之间实现一定程度的负载平衡。您也许不需要它们,所以将它们设为 0 即可。

MIT Kerberos 当前查找服务时将查找以下名称:

_kerberos

它定义了 KDC 守护程序(身份验证和票据授权服务器)的位置。典型记录如下:

_kerberos._udp.EXAMPLE.COM.  IN  SRV    0 0 88 kdc.example.com.
_kerberos._tcp.EXAMPLE.COM.  IN  SRV    0 0 88 kdc.example.com.
_kerberos-adm

它描述了远程管理服务的位置。典型记录如下:

_kerberos-adm._tcp.EXAMPLE.COM. IN  SRV    0 0 749 kdc.example.com.

因为 kadmind 不支持 UDP,所以没有 _udp 记录。

与静态配置文件一样,这里也提供了一种机制来向客户端指示特定主机位于 EXAMPLE.COM 领域中,即使它不是 example.com DNS 的一部分。通过将一个 TXT 记录附加到 _kerberos.host_name 即可做到这一点,如下所示:

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

7.5.6.3 调整时钟偏差

时钟偏差是容许票据时戳与主机系统时钟相差的范围,超过此范围将不接受此票据。时钟偏差通常设置为 300 秒(5 分钟)。这意味着,票据中的时戳最多可以比服务器时钟慢五分钟,并且最多可以快五分钟。

当使用 NTP 同步所有主机时,可以将此值减少为大约一分钟。可以在 /etc/krb5.conf 中设置时钟偏差值,如下所示:

[libdefaults]
        clockskew = 60

7.5.7 配置远程 Kerberos 管理

为了无需直接访问 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 手册页。

7.5.8 创建 Kerberos 服务主体

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

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

有效的服务描述符为:

服务描述符

服务

主机

Telnet、RSH、SSH

nfs

NFSv4(提供 Kerberos 支持)

HTTP

HTTP(提供 Kerberos 身份验证)

imap

IMAP

pop

POP3

ldap

LDAP

服务主体类似于用户主体,但存在一些重大差别。用户主体与服务主体之间的主要差别在于,前者的密钥受口令保护。当用户从 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 票据。

7.5.9 对 Kerberos 启用 PAM 支持

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

不完整的 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 票据作为部分用户身份验证的网络服务。这一点很特别,后面将会讨论。

7.5.10 配置 SSH 进行 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)。

7.5.11 使用 LDAP 和 Kerberos

Kerberos 提供身份验证,而 LDAP 则用于授权和标识。这两个服务可以配合工作。

为建立安全连接,389 目录服务器支持以不同的方式加密数据:SSL/TLS 连接、启动 TLS 连接和 SASL 身份验证。简单身份验证和安全层 (SASL) 是用于进行身份验证的网络协议。在 SUSE Linux Enterprise Server 中使用的 SASL 实现是 cyrus-sasl。Kerberos 身份验证是通过 GSS-API(常规安全服务 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。

要设置该变量,请执行以下操作:

  1. tux > sudo systemctl edit dirsrv@INSTANCE

    如果您为 389 目录服务器实例使用了默认名称,请将 INSTANCE 替换为 localhost

  2. 添加以下命令:

    [Service]
      Environment=KRB5_KTNAME=/etc/dirsrv/slapd-INSTANCE/krb5.keytab
  3. keytab 文件需可供用于运行 389 目录服务器的帐户(例如 dirserv)读取:

    tux > sudo chown dirsrv:dirsrv /etc/dirsrv/slapd-INSTANCE/krb5.keytab
    tux > sudo chmod 600 /etc/dirsrv/slapd-INSTANCE/krb5.keytab

7.5.11.1 将 Kerberos 身份验证与 LDAP 搭配使用

要获取并缓存初始票据授权票据,请使用在第 7.5.5.3 节 “创建主体”中创建的主体:

tux > kinit geeko@EXAMPLE.COM

要检查 GSSAPI 身份验证是否正常工作,请运行:

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

GSSAPI 使用 ccache 向 389 目录服务器验证用户身份,无需用户提供其口令。

7.5.11.2 配置 SASL 身份映射

在处理 SASL 绑定请求时,389 目录服务器会将 SASL 身份验证 ID(用于向目录服务器进行身份验证)映射到服务器中储存的 LDAP 项。使用 Kerberos 时,SASL 用户 ID 通常采用以下格式:userid@REALM,例如 tux@example.com。必须将此 ID 转换为用户目录服务器项的 DN,例如 uid=tux,ou=people,dc=example,dc=com。389 目录服务器为大多数常用配置随附了一些默认映射。不过,您可以创建自定义的映射。过程 7.1 “管理映射”说明了如何列出和显示映射、如何删除映射,以及如何创建自定义映射。

过程 7.1︰ 管理映射
  1. 要列出现有的 SASL 映射,请运行以下命令:

    tux > dsconf INSTANCE sasl list
    Kerberos uid mapping
    rfc 2829 dn syntax
    rfc 2829u syntax
    uid mapping
  2. 要显示映射,请运行以下命令:

    tux > sudo dsconf INSTANCE sasl get "Kerberos uid mapping"
    dn: cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
    cn: Kerberos uid mapping
    nsSaslMapBaseDNTemplate: dc=\2,dc=\3
    nsSaslMapFilterTemplate: (uid=\1)
    nsSaslMapRegexString: \(.*\)@\(.*\)\.\(.*\)
    objectClass: top
    objectClass: nsSaslMapping
  3. 仅当您的 dc 包含两个组件时,默认映射才起作用。要删除映射(如果它不适合您),请运行以下命令:

    tux > sudo dsconf INSTANCE sasl delete "Kerberos uid mapping"
    Deleting SaslMapping cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config :
    Successfully deleted cn=Kerberos uid mapping,cn=mapping,cn=sasl,cn=config
  4. 要创建新映射,请运行以下命令:

    tux > sudo dsconf localhost sasl create --cn=bhgssapi --nsSaslMapRegexString "\
    (.*\)@EXAMPLE.NET.DE" --nsSaslMapBaseDNTemplate="dc=example,dc=net,dc=de" --nsSaslMapFilterTemplate="(uid=\1)"
    tux > sudo Enter value for nsSaslMapPriority :
    Successfully created bhgssapi
  5. 使用以下命令显示新创建的映射:

    tux > sudo dsconf localhost sasl get "bhgssapi"
    dn: cn=bhgssapi,cn=mapping,cn=sasl,cn=config
    cn: bhgssapi
    nsSaslMapBaseDNTemplate: dc=example,dc=net,dc=de
    nsSaslMapFilterTemplate: (uid=\1)
    nsSaslMapPriority: 100
    nsSaslMapRegexString: \(.*\)@EXAMPLE.NET.DE
    objectClass: top
    objectClass: nsSaslMapping

    使用这些命令,您可以仅检查特定领域的用户,并将其重新映射到不同的 dc 库。可以看到,新映射包含 3 个 dc 组件,因此默认映射不适合此领域 (EXAMPLE.NET.DE),而只适合 EXAMPLE.NET 这样的领域。

7.6 Kerberos 和 NFS

大多数 NFS 服务器都可以使用默认信任网络形式的安全性(称为 sec=sys)与基于 Kerberos 的三种不同级别的安全性(sec=krb5sec=krb5isec=krb5p)的任意组合来导出文件系统。sec 选项设置为客户端上的装入选项。一种常见的情况是先配置 NFS 并将其与 sec=sys 配合使用,然后便可以实施 Kerberos。在这种情况下,服务器有可能会配置为同时支持 sec=sys 以及某种 Kerberos 级别,在转换所有客户端后,将会去除 sec=sys 支持,从而实现真正的安全性。转换到 Kerberos 的过程应该非常透明(如果有序进行)。但是,如果使用了 Kerberos,NFS 行为的一个微小细节的工作方式会有所不同,您需要了解并可能需要解决这种差异造成的影响。请参见第 7.6.1 节 “组成员资格”

三种 Kerberos 级别表示不同的安全级别。安全性越高,加密和解密消息所需的处理器资源就越多。在计划对 NFS 实施 Kerberos 时,选择适当的平衡是一个重要考虑因素。

krb5 仅提供身份验证。服务器知道谁发送了请求,而客户端知道服务器发送了答复。它不会为请求或答复的内容提供安全性,因此获得物理网络访问权限的攻击者可能会以各种方式转换请求和/或答复,以欺骗服务器或客户端。他们不能直接读取或更改经过身份验证的用户所不能读取或更改的任何文件,但从理论上说,任何事情几乎都有可能发生。

krb5i 添加了对所有消息的完整性检查。使用 krb5i 时,攻击者无法修改任何请求或答复,但可以查看所有交换的数据,因此可能会看到所读取的任何文件的内容。

krb5p 在协议中添加了隐私保护。除了可靠的身份验证和完整性检查外,消息将完全加密,这样攻击者只能知道在客户端与服务器之间交换了消息,但不能直接从消息中提取其他信息。能否从消息计时中提取信息是 Kerberos 无法解决的另一个问题。

7.6.1 组成员资格

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 的站点管理员应该了解这种差异,并确保它不会真正造成问题。

7.6.2 性能和可伸缩性

利用 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 复本,然后监视性能以确定需求是否超过容量。

7.6.3 主 KDC、多个域和信任关系

Kerberos KDC 的一个不容易分发的服务是更新处理,例如口令更改和新用户的创建。这些操作必须在单个主 KDC 上进行。

这些更新不太可能会以很高的频率发生,因而不会产生任何繁重负载,但可能出现可用性方面的问题。创建新用户或更改口令可能很麻烦,并且世界另一端的主 KDC 有时会暂时不可用。

如果组织分布于不同地理位置并且其政策规定在每个站点本地处理管理任务,创建多个 Kerberos 域(为每个管理中心创建一个)可能会是比较好的做法。这样每个域都会有位于本地的自己的主 KDC。通过在域之间设置信任关系,一个域中的用户仍可访问另一个域中的资源。

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

7.7 更多信息

MIT Kerberos 的官方网站是 https://web.mit.edu/kerberos。因此,找出任何有关 Kerberos(包括 Kerberos 安装、用户和管理指南)的任何其他相关资源的链接。

Brian Tung 编著的 Kerberos — 网络认证系统一书 (ISBN 0-201-37924-4) 提供了深入和全面的信息。