13.5. Kerberos

Contributed by Tillman Hodgson.
Based on a contribution by Mark Murray.

Kerberos 是一种网络身份验证协议,最初由麻省理工学院 ( MIT ) 开发作为在潜在的恶意网络上安全地提供身份验证的一种方式。 Kerberos 协议使用强加密技术, 以便客户端和服务器都可以在不通过网络发送任何未加密的机密的情况下证明其身份。 Kerberos 可以描述为身份验证代理系统和受信任的第三方身份验证系统。在用户使用 Kerberos 进行身份验证后, 可以对其通信进行加密, 以确保隐私和数据完整性。

Kerberos 只提供一种功能 ── 在网络上安全地完成用户的身份验证。 它并不提供授权功能 (也就是说用户能够做什么操作) 或审计功能 (记录用户作了什么操作)。因此, 强烈建议将 Kerberos 同其它提供授权和审计服务的安全手段联用。

该协议的当前版本是第5版,在RFC4120中描述。该协议有几个免费的实现,覆盖了广泛的操作系统。MIT继续开发他们的Kerberos包。在美国,它作为一种密码学产品被普遍使用,并且历史上一直受美国出口法规的约束。在 FreeBSD 中,MIT Kerberos可以通过从 port 或 package 安装 security/krb5 获取。Heimdal Kerberos的实现明确地在US之外开发,以避免出口法规。Heimdal Kerberos 发行版包含在 FreeBSD 的基本安装中, 另一个具有更多可配置选项的发行版则在 Ports Collection 的 security/heimdal

Kerberos中,用户和服务被识别为principals,这些用户和服务包含在一个管理分组中,称为realm。一个典型的用户主体的形式是user@REALM(按照传统,realm是大写的)。

本章介绍如何使用FreeBSD提供的Heimdal distribution配置Kerberos

为了展示 Kerberos 的安装过程, 我们约定:

注意:

在安装 Kerberos 时请使用实际的域名即使您只是想在内部网上用一用。 这可以避免 DNS 问题并保证了同其它 Kerberos 之间的互操作性。

13.5.1. 设定 Heimdal KDC

密钥分发中心 (KDC) 是 Kerberos 提供的集中式验证服务 ── 它是签发 Kerberos tickets 的那台计算机。 KDCKerberos 领域中的其它机器看来是 受信的, 因此必须格外注意其安全性。

需要说明 Kerberos 服务器只需要非常少的计算资源, 尽管如此,出于安全考虑,仍然推荐使用独占的机器来扮演 KDC 的角色。

在开始前,使用以下命令安装 security/heimdal

# pkg install heimdal

接下来需要使用sysrc更新/etc/rc.conf

# sysrc kdc_enable=yes
# sysrc kadmind_enable=yes

接下来需要修改 Kerberos 的配置文件, /etc/krb5.conf

[libdefaults]
    default_realm = EXAMPLE.ORG
[realms]
    EXAMPLE.ORG = {
	kdc = kerberos.example.org
	admin_server = kerberos.example.org
    }
[domain_realm]
    .example.org = EXAMPLE.ORG

在本例中,KDC 将使用完全限定的主机名 kerberos.example.org。KDC 的主机名必须在 DNS 中可解析。

Kerberos也可以使用DNS来定位KDC,而不使用/etc/krb5.conf中的[realms]部分。对于拥有自己的DNS服务器的大型组织,可以将上面的例子修该成:

[libdefaults]
      default_realm = EXAMPLE.ORG
[domain_realm]
    .example.org = EXAMPLE.ORG

将下面的内容加入到 example.org zone 数据文件中:

_kerberos._udp      IN  SRV     01 00 88 kerberos.example.org.
_kerberos._tcp      IN  SRV     01 00 88 kerberos.example.org.
_kpasswd._udp       IN  SRV     01 00 464 kerberos.example.org.
_kerberos-adm._tcp  IN  SRV     01 00 749 kerberos.example.org.
_kerberos           IN  TXT     EXAMPLE.ORG

注意:

要让客户机能够找到 Kerberos 服务, 就 必须 首先配置完整或最小配置的 /etc/krb5.conf 并且 正确地配置 DNS 服务器。

接下来需要创建 Kerberos 数据库。 这个数据库包括了使用主密码加密的所有实体的密钥。 您并不需要记住这个密码, 它会保存在一个文件 (/var/heimdal/m-key) 中。 要创建主密钥, 需要执行 kstash 并输入密码:

# kstash
Master key: xxxxxxxxxxxxxxxxxxxxxxx
Verifying password - Master key: xxxxxxxxxxxxxxxxxxxxxxx

Once the master key has been created, the database should be initialized. The Kerberos administrative tool kadmin(8) can be used on the KDC in a mode that operates directly on the database, without using the kadmind(8) network service, as kadmin -l. This resolves the chicken-and-egg problem of trying to connect to the database before it is created. At the kadmin prompt, use init to create the realm's initial database:

# kadmin -l
kadmin> init EXAMPLE.ORG
Realm max ticket life [unlimited]:

Lastly, while still in kadmin, create the first principal using add. Stick to the default options for the principal for now, as these can be changed later with modify. Type ? at the prompt to see the available options.

kadmin> add tillman
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes []:
Password: xxxxxxxx
Verifying password - Password: xxxxxxxx

接下来启动 KDC 服务:

# service kdc start
# service kadmind start

管此时还没有任何正在运行的 Kerberos 服务, 但您仍然可以通过获取并列出您刚刚创建的那个 principal (用户) 的 ticket 来查看 KDC 是否正常工作:

% kinit tillman
tillman@EXAMPLE.ORG's Password:

确认使用klist成功获取票证:

% klist
Credentials cache: FILE:/tmp/krb5cc_1001
	Principal: tillman@EXAMPLE.ORG

  Issued                Expires               Principal
Aug 27 15:37:58 2013  Aug 28 01:37:58 2013  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG

测试完成后,临时票证可以销毁:

% kdestroy

13.5.2. 设定服务器使用Kerberos

首先我们需要一份 Kerberos 配置文件 /etc/krb5.conf 的副本。 只需简单地用安全的方式 (使用类似 scp(1) 的网络工具, 或通过软盘) 复制 KDC 上的版本, 并覆盖掉客户机上的对应文件就可以了。

接下来需要一个 /etc/krb5.keytab 文件。 这是提供 Kerberos 服务的服务器和工作站的一个主要区别 ── 服务器必须有 keytab 文件。 这个文件包括了服务器的主机密钥, 这使得 KDC 得以验证它们的身份。 此文件必须以安全的方式传到服务器上, 因为如果密钥被公之于众, 则安全也就毁于一旦。 也就是说, 通过明文的通道, 例如 FTP 是非常糟糕的想法。一般来说, 您会希望使用 kadmin 程序来把 keytab 传到服务器上。 由于也需要使用 kadmin 来为主机建立 principal (KDC 一端的 krb5.keytab), 因此这并不复杂。

注意您必须已经获得了一个 ticket 而且这个 ticket 必须许可使用 /var/heimdal/kadmind.acl 中的 kadmin 接口。 请参考 Heimdal info 中的 Remote administration(远程管理) 一节 (info heimdal) 以了解如何设计访问控制表。 如果不希望启用远程的 kadmin 操作, 则可以简单地采用安全的方式连接 KDC (通过本机控制台, ssh(1)Kerberos telnet(1)) 并使用 kadmin -l 在本地执行管理操作。

安装了 /etc/krb5.conf 文件之后, 您就可以使用 Kerberos 上的 kadmin 了。 add --random-key 命令可以用于添加主机 principal, 而 ext 命令则允许导出服务器的主机 principal 到它的 keytab 中。 例如:

# kadmin
kadmin> add --random-key host/myserver.example.org
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes []:
kadmin> ext_keytab host/myserver.example.org
kadmin> exit

请注意,默认情况下,ext_keytab 将提取的密钥存储在 /etc/krb5.keytab。如果您希望将 keytab 存储在其他位置,应使用 --keytab path/to/file 参数:

# kadmin
kadmin> ext_keytab --keytab=/tmp/example.keytab host/myserver.example.org
kadmin> exit

keytab 可以使用scp(1)或 U 盘复制到服务器上。一定要指定一个不同于默认的 keytab 名字以免覆盖 KDC 上的 keytab。

到现在您的服务器已经可以同 KDC 通讯了 (因为已经配置了 krb5.conf 文件), 而且它还能够证明自己的身份(由于配置了 krb5.keytab 文件)。现在可以启用一些 Kerberos 服务。这里以sshd(8)为例,它通过GSS-API支持Kerberos,若需启用此功能,将以下行添加到/etc/ssh/sshd_config

GSSAPIAuthentication yes

做完了这个变更之后,必须重新启动sshd(8)来使新的设定值生效:service sshd restart

13.5.3. 设定客户端使用Kerberos

设置客户机是非常简单的。 在正确配置了 Kerberos 的网络中, 只需要将位于 /etc/krb5.conf 的配置文件进行一下设置就可以了。 这一步骤可以简单地通过安全的方式将文件从 KDC 复制到客户机上来完成。

尝试在客户机上执行 kinitklist, 以及 kdestroy 来测试获取、 显示并删除 刚刚为 principal 建立的 ticket 是否能够正常进行, 如果能, 则用其它的 Kerberos 应用程序来连接启用了 Kerberos 的服务。 如果应用程序不能正常工作而获取 ticket 正常, 则通常是服务本身, 而非客户机或 KDC 有问题。ssh(1)默认不启用GSS-API,使用ssh -o GSSAPIAuthentication=yes hostname进行测试。

测试 Kerberized 应用程序时,请尝试使用抓包软件(如 tcpdump),来确定没有以明文形式发送敏感信息。

各种Kerberos客户端应用程序都可以使用。随着桥的出现,使用SASL进行认证的应用程序也可以使用GSS-API机制,从Jabber客户端到IMAP客户端,多种客户端应用程序都可以使用Kerberos进行认证。

一个域内的用户通常会将他们的Kerberos主体映射到本地用户账户上。有时,我们需要将本地用户账户的访问权授予没有匹配的Kerberos主体的人。例如,tillman@EXAMPLE.ORG可能需要访问本地用户账户webdevelopers。其他负责人可能也需要访问该本地账户。

.k5login.k5users文件,放置在用户的主目录中,可以用来解决这个问题。例如,如果将下面的.k5login放置在用户的主目录中,那么列出的两个负责人都可以访问该账户,而不需要共享密码:

tillman@example.org
jdoe@example.org

更多关于.k5users的信息,请参阅ksu(1)

13.5.4. 与MIT的差异

MIT和 Heimdal 实现之间的主要区别是kadmin具有不同但等效的命令集,并且使用不同的协议。如果KDCMIT,则不能使用 Heimdal 版本的 Kadmin 远程管理KDC,反之亦然。

客户端应用程序也可以使用稍有不同的命令行选项来完成相同的任务。建议遵循http://web.mit.edu/Kerberos/www/中的说明。小心路径问题: MIT port 默认安装到 /usr/local/, 如果 PATH 先列出系统目录, FreeBSD 系统应用程序将代替 MIT 版本运行。

将 MIT Kerberos 用作 KDC 时,请将以下行添加到rc.conf

kdc_program="/usr/local/sbin/kdc"
kadmind_program="/usr/local/sbin/kadmind"
kdc_flags=""
kdc_enable="YES"
kadmind_enable="YES"

13.5.5. Kerberos提示、技巧与疑难排解

当您需要配置Kerberos或者在使用中遇到问题时,请牢记以下几点:

  • 使用来自来自 ports 的 Heimdal or MIT Kerberos 时, 请确保 PATH 中输出的版本是 port 中的版本,而非系统自带版本。

  • 如果域中的所有计算机没有同步时间设置,认证可能会失败。第 29.11 节 “NTP时间校对”介绍了如何使用NTP同步时钟。

  • 如果主机名被更改,则必须更改host/主项并更新keytab。这也适用于特殊的keytab条目,比如Apache的www/mod_auth_kerb中使用的HTTP/ principal。

  • 域中的所有主机必须在DNS中正向和反向解析,或者至少在/etc/hosts中存在。CNAME 也可以使用,但 A 和 PTR 记录必须正确和到位。无法解析主机的错误提示信息并不直观:Kerberos5 refuses authentication because Read req failed: Key table entry not found

  • 一些客户端操作系统没有为KDC设置ksu权限。这意味着ksu不能工作。这是权限问题,而不是KDC错误。

  • MIT Kerberos,允许委托人的票据寿命长于默认的十小时寿命。在kadmin(8)提示下使用modify_principal来更改相关委托人和krbtgt委托人的maxlife。然后,委托人可以使用kinit -l来请求一个寿命更长的票据。

  • 当从工作站运行kinit,在KDC上运行数据包嗅探器以帮助排除故障时,即使在输入密码之前,也会立即发送票据授予票据(TGT)。这是因为Kerberos服务器会对任何未经授权的请求自由地发送TGT。然而,每一个TGT都使用由用户密码衍生的密钥进行加密。当用户键入他们的密码时,密码不会被发送到KDC,而是用来解密kinit已经获得的TGT。如果解密过程的结果是一个具有有效时间戳的有效票据,则用户拥有有效的Kerberos凭证。这些凭证包括用于将来与Kerberos服务器建立安全通信的会话密钥,以及用Kerberos服务器自己的密钥加密的实际TGT。这第二层加密允许Kerberos服务器验证每个TGT的真实性。

  • 主机本体的票据的有效期可以更长。如果用户委托人的有效期是一周,但被连接的主机的有效期是9个小时,那么用户缓存中的主机委托人就会过期,票据缓存将无法正常工作。

  • 当设置krb5.dict以防止使用kadmind(8)中所述的特定坏密码时,请记住,它只适用于已为其分配密码策略的委托人。krb5.dict中使用的格式是每行一个字符串。创建一个到/usr/share/dict/words的符号链接可能会有用。

13.5.6. 减轻Kerberos的限制

由于Kerberos是一种全有或全无的方法(all or nothing approach),因此,网络上启用的每一项服务都必须经过修改,以便与Kerberos一起工作,或者以其他方式防止网络攻击。这是为了防止用户凭证被窃取和重复使用。一个例子是,当所有远程shell上的Kerberos已被启用,但非Kerber化的POP3邮件服务器以纯文本形式发送密码。

KDC是单点故障。根据设计, KDC必须和其主密码数据库一样安全。 KDC绝对不应在其上运行任何其他服务,并且在物理上应是安全的。危险很高,因为Kerberos 的存储使用同一主密钥加密的所有密码,该主密钥作为文件存储在KDC 上。

主密钥泄露并不像人们所担心的那样糟糕。主密钥仅用于加密Kerberos数据库,并作为随机数发生器的种子。只要对KDC的访问是安全的,攻击者就无法利用主密钥发起攻击。

如果KDC不可用,网络服务将无法使用,因为无法认证。这可以通过一个主KDC和一个或多个从 kDC ,并通过使用PAM仔细执行二级或后备验证来缓解。

Kerberos允许用户、主机和服务之间进行认证。它没有机制来验证KDC与用户、主机或服务之间的关系。这意味着被黑的kinit可以记录所有用户名和密码。文件系统完整性检查工具(如security/tripwire)可以缓解这种情况。

13.5.7. 相关资源和信息

本文档和其它文档可从这里下载: ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

如果对于FreeBSD有问题,请先阅读 文档,如不能解决再联系 <questions@FreeBSD.org>.

关于本文档的问题请发信联系 <doc@FreeBSD.org>.