为目录服务器配置 Kerberos 的过程可能非常复杂。应该首先参考 Kerberos 文档。
要获取更多帮助,请通过以下示例过程了解应该执行哪些步骤。但是请注意,此过程仅仅是一个示例。您必须对过程进行相应修改,使其符合您自己的配置和环境。
可以在《System Administration Guide: Security Services》中找到有关在 Solaris 操作系统中配置和使用 Kerberos 的其他信息。本指南是 Solaris 文档集的一部分。您还可以参考手册页。
此示例以及所使用的步骤的相关信息如下所示:
此示例过程介绍如何将一台计算机配置为密钥分发中心 (Key Distribution Center, KDC),并将另一台计算机配置为运行目录服务器。此过程的结果是用户可以通过 GSSAPI 执行 Kerberos 验证。
可以在同一台计算机上同时运行 KDC 和目录服务器。如果选择在同一台计算机上同时运行 KDC 和目录服务器,请使用相同的过程,但可以在目录服务器计算机的步骤中省略已对 KDC 计算机执行的部分。
此过程对于所使用的环境进行了许多假设。使用示例过程时,请根据您的环境适当地修改值。这些假设如下:
此系统已安装全新的 Solaris 9 软件和最新的推荐修补程序簇。如果未安装相应的 Solaris 修补程序,则目录服务器的 Kerberos 验证可能会失败。
请注意,尽管此处介绍的过程与适用于 Solaris 10 的过程大体相同,但仍存在一些差别。配置文件格式存在细微差别,某些命令的输出也可能不同。
运行 Kerberos 守护进程的计算机具有全限定域名 kdc.example.com。必须将计算机配置为使用 DNS 作为命名服务。此配置为 Kerberos 的必需配置。如果使用其他命名服务(如 file),则某些操作可能会失败。
运行目录服务器的计算机具有全限定域名 directory.example.com。必须将此计算机也配置为使用 DNS 作为命名服务。
目录服务器计算机作为通过 Kerberos 进行目录服务器验证的客户端系统。可以从任何能够与目录服务器和 Kerberos 守护进程进行通信的系统中执行此验证。但是,此示例所需的全部组件都是随目录服务器提供的,并从该系统中执行验证。
目录服务器中的用户具有 uid= username,ou=People,dc=example,dc=com 格式的 DN。相应的 Kerberos 主体为 username@EXAMPLE.COM。如果使用其他命名模式,则必须使用不同的 GSSAPI 标识映射。
/etc/krb5/krb5.conf 配置文件提供 Kerberos 客户端与 KDC 通信时所需的信息。
在 KDC 计算机、目录服务器计算机以及将使用 Kerberos 进行目录服务器验证的任何客户机上编辑 /etc/krb5/krb5.conf 配置文件。
将出现的每个 "___default_realm___" 替换为 "EXAMPLE.COM"。
将出现的每个 "___master_kdc___" 替换为 "kdc.example.com"。
删除包含 "___slave_kdcs___" 的行,因为只有一个 Kerberos 服务器。
将 "___domain_mapping___" 替换为 ".example.com = EXAMPLE.COM"(注意 .example.com 开头处的句点)。
已更新的 /etc/krb5/krb5.conf 配置文件应该与以下示例内容类似。
| #pragma ident   "@(#)krb5.conf  1.2     99/07/20 SMI"
# Copyright (c) 1999, by Sun Microsystems, Inc.
# All rights reserved.
#
# krb5.conf template
# In order to complete this configuration file
# you will need to replace the __<name\>__ placeholders
# with appropriate values for your network.
#
[libdefaults]
        default_realm = EXAMPLE.COM
[realms]
        EXAMPLE.COM = {
                kdc = kdc.example.com
                admin_server = kdc.example.com
        }
[domain_realm]
        .example.com = EXAMPLE.COM
[logging]
        default = FILE:/var/krb5/kdc.log
        kdc = FILE:/var/krb5/kdc.log
        kdc_rotate = {
# How often to rotate kdc.log. Logs will get rotated no more
# often than the period, and less often if the KDC is not used
# frequently.
                period = 1d
# how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1, ...)
                versions = 10
        }
[appdefaults]
        kinit = {
                renewable = true
                forwardable= true
        }
        gkadmin = {
                help_url =
 http://docs.sun.com:80/ab2/coll.384.1/SEAM/@AB2PageView/1195
        } | 
在 /etc/krb5/kadm5.acl 配置文件中将 "___default_realm___" 替换为 "EXAMPLE.COM"。已更新的文件应该与以下示例类似。
| # # Copyright (c) 1998-2000 by Sun Microsystems, Inc. # All rights reserved. # # pragma ident "@(#)kadm5.acl 1.1 01/03/19 SMI" */admin@EXAMPLE.COM * | 
编辑 /etc/krb5/kdc.conf 文件,将 "___default_realm___" 替换为 "EXAMPLE.COM"。已更新的文件应该与以下示例类似。
| # Copyright 1998-2002 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
#ident  "@(#)kdc.conf   1.2     02/02/14 SMI"
[kdcdefaults]
        kdc_ports = 88,750
[realms]
        EXAMPLE.COM = {
                profile = /etc/krb5/krb5.conf
                database_name = /var/krb5/principal
                admin_keytab = /etc/krb5/kadm5.keytab
                acl_file = /etc/krb5/kadm5.acl
                kadmind_port = 749
                max_life = 8h 0m 0s
                max_renewable_life = 7d 0h 0m 0s
                default_principal_flags = +preauth
        } | 
| $ /usr/sbin/kdb5_util create -r EXAMPLE.COM -s Initializing database ’/var/krb5/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: password Re-enter KDC database master key to verify: password $ | 
使用以下命令创建管理用户,此用户具有 kws/admin@EXAMPLE.COM 主体以及管理守护进程将要使用的服务密钥。
| $ /usr/sbin/kadmin.local kadmin.local: add_principal kws/admin Enter password for principal "kws/admin@EXAMPLE.COM": secret Re-enter password for principal "kws/admin@EXAMPLE.COM": secret Principal "kws/admin@EXAMPLE.COM" created. kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc.example.com Entry for principal kadmin/kdc.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local: ktadd -k /etc/krb5/kadm5.keytab changepw/kdc.example.com Entry for principal changepw/kdc.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/changepw Entry for principal kadmin/changepw with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local: quit$ | 
运行以下命令来启动 KDC 和管理守护进程:
| $ /etc/init.d/kdc start $ /etc/init.d/kdc.master start $ | 
KDC 进程在进程列表中将显示为 /usr/lib/krb5/krb5kdc。管理守护进程将显示为 /usr/lib/krb5/kadmind。
请注意,在 Solaris 10 操作系统中,守护进程由服务管理工具 (Service Management Facility, SMF) 框架进行管理。在 Solaris 10 操作系统上启动守护进程:
| $ svcadm disable network/security/krb5kdc $ svcadm enable network/security/krb5kdc $ svcadm disable network/security/kadmin $ svcadm enable network/security/kadmin $ | 
使用以下一系列命令将主机主体添加到 KDC 和目录服务器计算机的 Kerberos 数据库。某些 Kerberos 实用程序(如 klist)将使用主机主体。
| $ /usr/sbin/kadmin -p kws/admin Enter Password: secret kadmin: add_principal -randkey host/kdc.example.com Principal "host/kdc.example.com@EXAMPLE.COM" created. kadmin: ktadd host/kdc.example.com Entry for principal host/kdc.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin: add_principal -randkey host/directory.example.com Principal "host/directory.example.com@EXAMPLE.COM" created. kadmin: ktadd host/directory.example.com Entry for principal host/directory.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin: quit $ | 
目录服务器必须有自身的主体,才能检验正在进行验证的用户所持有的 Kerberos 票证是否有效。目前已将目录服务器硬编码为需要 ldap/fqdn@realm 格式的主体,其中 fqdn 是目录服务器的全限定域名,而 realm 是 Kerberos 领域。fqdn 必须与安装目录服务器时提供的全限定名称相匹配。在此案例中,目录服务器的主体应该为 ldap/directory.example.com@EXAMPLE.COM。
使用以下一系列命令为目录服务器创建 LDAP 主体:
| $ /usr/sbin/kadmin -p kws/admin Enter Password: secret kadmin: add_principal -randkey ldap/directory.example.com Principal "ldap/directory.example.com@EXAMPLE.COM" created. kadmin: quit $ | 
要执行 Kerberos 验证,Kerberos 数据库中必须存在要进行验证的用户。在此示例中,用户具有用户名 kerberos-test,这意味着 Kerberos 主体为 kerberos-test@EXAMPLE.COM。
使用此示例中的一系列命令创建用户:
| $ /usr/sbin/kadmin -p kws/admin Enter Password: secret kadmin: add_principal kerberos-test Enter password for principal "kerberos-test@EXAMPLE.COM": secret Re-enter password for principal "kerberos-test@EXAMPLE.COM": secret Principal "kerberos-test@EXAMPLE.COM" created. kadmin: quit $ | 
安装 Directory Server 6.0 和最新的修补程序。以下为示例设置。
| 变量类型 | 示例值 | 
|---|---|
| 全限定计算机名 | directory.example.com | 
| 安装目录 | /opt/SUNWdsee | 
| 实例路径 | /local/ds | 
| 服务器用户 | unixuser | 
| 服务器组 | unixgroup | 
| 服务器标识符 | directory | 
| 服务器端口 | 389 | 
| 后缀 | dc=example,dc=com | 
| 管理员 ID | admin | 
| 管理域 | example.com | 
| 目录管理者 DN | cn=admin,cn=Administrators,cn=config | 
| 管理端口 | 390 | 
首先,创建文件 /data/ds/shared/bin/gssapi.ldif 以定义目录服务器应使用的映射,并基于主体标识要进行验证的 Kerberos 用户。请创建与以下示例内容相同的文件内容。
| dn: cn=GSSAPI,cn=identity mapping,cn=config
changetype: add
objectClass: top
objectClass: nsContainer
cn: GSSAPI
dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config
changetype: add
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
objectClass: dsPatternMatching
cn: default
dsMatching-pattern: \${Principal}
dsMatching-regexp: (.*)@EXAMPLE.COM
dsMappedDN: uid=\$1,ou=People,dc=example,dc=com
dn: cn=SASL,cn=security,cn=config
changetype: modify
replace: dsSaslPluginsPath
dsSaslPluginsPath: /usr/lib/mps/sasl2/libsasl.so | 
然后,使用 ldapmodify 命令更新目录服务器,以启用具有相应映射的 GSSAPI,如以下示例所示:
| $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -a -f /data/ds/shared/bin/gssapi.ldif adding new entry cn=GSSAPI,cn=identity mapping,cn=config adding new entry cn=default,cn=GSSAPI,cn=identity mapping,cn=config modifying entry cn=SASL,cn=security,cn=config $ | 
如前面所述,要通过 GSSAPI 验证 Kerberos 用户,目录服务器在 KDC 中必须具有自身的主体。要使验证正常工作,主体信息必须包含在目录服务器计算机上的 Kerberos 密钥表中。用于运行目录服务器的用户帐户必须能够读取包含此信息的文件。
使用以下一系列命令通过正确的属性创建密钥表文件:
| $ /usr/sbin/kadmin -p kws/admin Enter Password: secret kadmin: ktadd -k //local/ds/config/ldap.keytab ldap/directory.example.com Entry for principal ldap/directory.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/local/ds/config/ldap.keytab. kadmin: quit $ | 
在此自定义密钥表上更改权限和所有权。使得用于运行目录服务器的用户帐户成为此密钥表的所有者,并且只有该用户可以读取此密钥表:
| $ chown unixuser:unixgroup /local/ds/config /ldap.keytab $ chmod 600 /local/ds/config/ldap.keytab $ | 
默认情况下,目录服务器会尝试使用文件 /etc/kerb5/krb5.keytab 中的标准 Kerberos 密钥表。但是,允许目录服务器用户读取此文件可能会构成安全威胁,因此为目录服务器创建了自定义密钥表。
将目录服务器配置为使用新的自定义密钥表。可以通过设置 KRB5_KTNAME 环境变量完成此操作。
最后,重新启动目录服务器以使更改生效:
| $ KRB5_KTNAME=/etc/krb5/ldap.keytab dsadm restart /local/ds | 
要使 Kerberos 用户通过目录服务器的验证,该用户必须具有与其 Kerberos 主体相对应的目录条目。
在前面的步骤中,已使用主体 kerberos-test@EXAMPLE.COM 将测试用户添加到 Kerberos 数据库。由于向目录中添加了标识映射配置,因此该用户的相应目录条目必须具有 DN uid=kerberos-test,ou=People,dc=example,dc=com。
向目录添加用户之前,必须先创建包含以下内容的文件 testuser.ldif。
| dn: uid=kerberos-test,ou=People,dc=example,dc=com changetype: add objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson uid: kerberos-test givenName: Kerberos sn: Test cn: Kerberos Test description: An account for testing Kerberos authentication through GSSAPI | 
然后,使用 ldapmodify 将此条目添加到服务器:
| $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - -f testuser.ldif adding new entry uid=kerberos-test,ou=People,dc=example,dc=com $ | 
Kerberos 数据库、目录服务器和 KDC 中都存在测试用户。因此,现在能够以测试用户身份通过目录服务器的验证(使用 GSSAPI 和 Kerberos)。
首先,使用 kinit 命令为用户获取 Kerberos 票证,如以下示例所示:
| $ kinit kerberos-test Password for kerberos-test@EXAMPLE.COM: secret $ | 
然后,使用 klist 命令查看与此票证有关的信息:
| $ klist
Ticket cache: /tmp/krb5cc_0
Default principal: kerberos-test@EXAMPLE.COM
Valid starting            Expires                   Service principal
Sat Jul 24 00:24:15 2004  Sat Jul 24 08:24:15 2004  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until Sat Jul 31 00:24:15 2004
$ | 
最后一步是使用 GSSAPI 进行目录服务器验证。随目录服务器提供的 ldapsearch 实用程序支持 SASL 验证,包括 GSSAPI、DIGEST-MD5 和 EXTERNAL 机制。但是,要使用 GSSAPI 进行绑定,您必须向客户端提供 SASL 库所在的路径。通过将 SASL_PATH 环境变量设置为 lib/sasl 目录可以提供此路径:
| $ SASL_PATH=SASL-library $ export SASL_PATH $ | 
要实际使用 ldapsearch 在目录服务器上执行基于 Kerberos 的验证,必须包含 -o mech=GSSAPI 和 -o authzid=principal 参数。
此外,还必须指定全限定主机名(此处显示为 -h directory.example.com),该主机名必须与服务器 cn=config 上的 nsslapd-localhost 属性值相匹配。此处必须使用 -h 选项,因为 GSSAPI 验证过程需要客户端提供的主机名,以便与服务器提供的主机名进行匹配。
以下示例将在 dc=example,dc=com 条目被验证为之前创建的 Kerberos 测试用户帐户时检索此条目:
| $ ldapsearch -h directory.example.com -p 389 -o mech=GSSAPI \ -o authzid="kerberos-test@EXAMPLE.COM" -b "dc=example,dc=com" -s base "(objectClass=*)" version: 1 dn: dc=example,dc=com dc: example objectClass: top objectClass: domain $ | 
检查目录服务器访问日志,以确认是否按预期方式处理验证:
| $ tail -12 /local/ds/logs/access
[24/Jul/2004:00:30:47 -0500] conn=0 op=-1 msgId=-1 - fd=23 slot=23 LDAP 
		connection from 1.1.1.8 to 1.1.1.8
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - BIND dn="" method=sasl 
     version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=0 msgId=1 - RESULT err=14 tag=97 
     nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - BIND dn="" method=sasl 
     version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=1 msgId=2 - RESULT err=14 tag=97 
     nentries=0 etime=0, SASL bind in progress
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - BIND dn="" method=sasl 
     version=3 mech=GSSAPI
[24/Jul/2004:00:30:47 -0500] conn=0 op=2 msgId=3 - RESULT err=0 tag=97 
     nentries=0 etime=0 dn="uid=kerberos-test,ou=people,dc=example,dc=com"
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - SRCH base="dc=example,dc=com"
     scope=0 filter="(objectClass=*)" attrs=ALL
[24/Jul/2004:00:30:47 -0500] conn=0 op=3 msgId=4 - RESULT err=0 tag=101 nentries=1 
     etime=0
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=5 - UNBIND
[24/Jul/2004:00:30:47 -0500] conn=0 op=4 msgId=-1 - closing - U1
[24/Jul/2004:00:30:48 -0500] conn=0 op=-1 msgId=-1 - closed.
$ | 
此示例表明绑定过程分为三个步骤。前两步返回 LDAP 结果 14(正在进行 SASL 绑定),第三步显示绑定已成功完成。method=sasl 和 mech=GSSAPI 标记表明绑定使用了 GSSAPI SASL 机制。成功绑定响应末尾的 dn="uid=kerberos-test,ou=people,dc=example,dc=com" 表明绑定是由正确的用户执行的。