使用 GSSAPI 和 SASL 进行 Kerberos 验证的示例配置
为目录服务器配置 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 标识映射。
所有计算机：编辑 Kerberos 客户端配置文件
/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 配置文件应该与以下示例内容类似。
示例 6–1 已编辑的 Kerberos 客户端配置文件 /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
}
|
所有计算机：编辑管理服务器 ACL 配置文件
在 /etc/krb5/kadm5.acl 配置文件中将 "___default_realm___" 替换为 "EXAMPLE.COM"。已更新的文件应该与以下示例类似。
示例 6–2 已编辑的管理服务器 ACL 配置文件
# # Copyright (c) 1998-2000 by Sun Microsystems, Inc. # All rights reserved. # # pragma ident "@(#)kadm5.acl 1.1 01/03/19 SMI" */admin@EXAMPLE.COM * |
KDC 计算机：编辑 KDC 服务器配置文件
编辑 /etc/krb5/kdc.conf 文件，将 "___default_realm___" 替换为 "EXAMPLE.COM"。已更新的文件应该与以下示例类似。
示例 6–3 已编辑的 KDC 服务器配置文件 /etc/krb5/kdc.conf
# 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
}
|
KDC 计算机：创建 KDC 数据库
$ /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 $ |
KDC 计算机：创建管理主体和密钥表
使用以下命令创建管理用户，此用户具有 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 计算机：启动 Kerberos 守护进程
运行以下命令来启动 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 计算机：为 KDC 和目录服务器计算机添加主机主体
使用以下一系列命令将主机主体添加到 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 $ |
KDC 计算机：为目录服务器添加 LDAP 主体
目录服务器必须有自身的主体，才能检验正在进行验证的用户所持有的 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 $ |
KDC 计算机：向 KDC 添加测试用户
要执行 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 |
目录服务器计算机：将目录服务器配置为启用 GSSAPI
首先，创建文件 /data/ds/shared/bin/gssapi.ldif 以定义目录服务器应使用的映射，并基于主体标识要进行验证的 Kerberos 用户。请创建与以下示例内容相同的文件内容。
示例 6–4 gssapi.ldif 文件内容
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。
示例 6–5 新的 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 票证
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 进行目录服务器验证
最后一步是使用 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" 表明绑定是由正确的用户执行的。
- © 2010, Oracle Corporation and/or its affiliates