为目录服务器配置 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 票证是否有效。目前已将目录服务器固定编码 (hard coded) 为需要 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 |
服务器端口 |
389 |
后缀 |
dc=example,dc=com |
首先,创建文件 /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" 表明绑定是由正确的用户执行的。