test

Sun Java System Directory Server Enterprise Edition 6.1 管理指南

在客户端中使用 Kerberos SASL GSSAPI

在客户端中使用 GSSAPI 机制时，您不必安装用户证书，但必须配置 Kerberos V5 安全系统。此外，如果要使用加密的 SSL 连接，则必须信任服务器证书，如管理证书中所述。

Procedure在主机上配置 Configure Kerberos V5

必须在将要运行 LDAP 客户端的主机上配置 Kerberos V5。

无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。

  1. 按照安装说明安装 Kerberos V5。

    Sun 建议安装 Sun Enterprise Authentication Mechanism 1.0.1 客户端软件。

  2. 配置 Kerberos 软件。

    使用 Sun Enterprise Authentication Mechanism 软件对 /etc/krb5 下的文件进行配置。此配置将设置 kdc 服务器，并定义默认领域和 Kerberos 系统所需的任何其他配置。

  3. 修改文件 /etc/gss/mech，使列出的第一个值为 kerberos_v5（如有必要）。

Procedure指定用于 Kerberos 验证的 SASL 选项

无法使用 DSCC 执行此任务。请使用命令行，如以下过程所述。

  1. 使用通过 GSSAPI 机制启用的客户端应用程序之前，先使用用户主体初始化 Kerberos 安全系统。


    $ kinit user-principal

    其中 user-principal 是您的 SASL 标识，例如 bjensen@example.com。

  2. 指定使用 Kerberos 时所需的 SASL 选项。

    请注意，在 UNIX 环境中，必须将 SASL_PATH 环境变量设置为 SASL 库的正确路径。例如，在 Korn shell 中：


    $ export SASL_PATH=SASL-library

    此路径假定目录服务器安装在调用 LDAP 工具的相同主机上。

    ldapsearch 工具的以下示例说明如何使用 -o（小写字母 o）选项指定使用 Kerberos 时所需的 SASL 选项：


    $ ldapsearch -h www.host1.com -p 1389 -o mech=GSSAPI -o authid="bjensen@EXAMPLE.COM" \
 -o authzid="bjensen@EXAMPLE.COM" -b "dc=example,dc=com" "(givenname=Richard)"

    可以省略 authid，因为它会出现在由 kinit 命令初始化的 Kerberos 缓存中。如果 authid 存在，则 authid 和 authzid 必须相同，但不会使用适用于代理操作的 authzid。authid 的值是标识映射中使用的主体。此主体必须是包括领域的完整主体。请参见GSSAPI 标识映射。

使用 GSSAPI 和 SASL 进行 Kerberos 验证的示例配置

为目录服务器配置 Kerberos 的过程可能非常复杂。应该首先参考 Kerberos 文档。

要获取更多帮助，请通过以下示例过程了解应该执行哪些步骤。但是请注意，此过程仅仅是一个示例。您必须对过程进行相应修改，使其符合您自己的配置和环境。

可以在《System Administration Guide: Security Services》中找到有关在 Solaris 操作系统中配置和使用 Kerberos 的其他信息。本指南是 Solaris 文档集的一部分。您还可以参考手册页。

    此示例以及所使用的步骤的相关信息如下所示：

  1. 此示例的假设

  2. 所有计算机：编辑 Kerberos 客户端配置文件

  3. 所有计算机：编辑管理服务器 ACL 配置文件

  4. KDC 计算机：编辑 KDC 服务器配置文件

  5. KDC 计算机：创建 KDC 数据库

  6. KDC 计算机：创建管理主体和密钥表

  7. KDC 计算机：启动 Kerberos 守护进程

  8. KDC 计算机：为 KDC 和目录服务器计算机添加主机主体

  9. KDC 计算机：为目录服务器添加 LDAP 主体

  10. KDC 计算机：向 KDC 添加测试用户

  11. 目录服务器 计算机：安装目录服务器

  12. 目录服务器计算机：将目录服务器配置为启用 GSSAPI

  13. 目录服务器计算机：创建目录服务器密钥表

  14. 目录服务器计算机：向目录服务器添加测试用户

  15. 目录服务器计算机：以测试用户的身份获取 Kerberos 票证

  16. 客户机：通过 GSSAPI 进行目录服务器验证

此示例的假设

此示例过程介绍如何将一台计算机配置为密钥分发中心 (Key Distribution Center, KDC)，并将另一台计算机配置为运行目录服务器。此过程的结果是用户可以通过 GSSAPI 执行 Kerberos 验证。

可以在同一台计算机上同时运行 KDC 和目录服务器。如果选择在同一台计算机上同时运行 KDC 和目录服务器，请使用相同的过程，但可以在目录服务器计算机的步骤中省略已对 KDC 计算机执行的部分。

此过程对于所使用的环境进行了许多假设。使用示例过程时，请根据您的环境适当地修改值。这些假设如下：

所有计算机：编辑 Kerberos 客户端配置文件

/etc/krb5/krb5.conf 配置文件提供 Kerberos 客户端与 KDC 通信时所需的信息。

在 KDC 计算机、目录服务器计算机以及将使用 Kerberos 进行目录服务器验证的任何客户机上编辑 /etc/krb5/krb5.conf 配置文件。

已更新的 /etc/krb5/krb5.conf 配置文件应该与以下示例内容类似。

示例 5–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"。已更新的文件应该与以下示例类似。

示例 5–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"。已更新的文件应该与以下示例类似。

示例 5–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 用户。请创建与以下示例内容相同的文件内容。

示例 5–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。

示例 5–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" 表明绑定是由正确的用户执行的。