test

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

第 5 章 目录服务器安全性

目录服务器支持多种可通过网络提供安全可靠通信的机制。LDAPS 是在安全套接字层 (Secure Sockets Layer, SSL) 之上运行的标准 LDAP 协议。LDAPS 可加密数据，并可选择使用证书进行验证。本章中提及的术语 SSL 表示受支持的协议 SSL2、SSL3 和 TLS 1.0。

目录服务器还支持启动传输层安全 (Start Transport Layer Security, Start TLS) 扩展操作，以便在最初未加密的 LDAP 连接上启用 TLS。

此外，目录服务器还支持通过简单验证和安全层 (Simple Authentication and Security Layer, SASL) 执行通用安全服务 API (Generic Security Service API, GSSAPI)。GSSAPI 允许您在 Solaris 操作系统 (Solaris OS) 上使用 Kerberos V5 安全协议。标识映射机制接着会将 Kerberos 主体与目录中的标识进行关联。

有关其他安全性信息，请参见 NSS Web 站点，网址为 http://www.mozilla.org/projects/security/pki/nss/ 。

本章提供了通过 SSL 配置安全性的过程。有关 ACI 的信息，请参见第 6 章，目录服务器访问控制。有关用户访问权限和密码的信息，请参见第 7 章，目录服务器密码策略。

本章包含以下主题：

在目录服务器中使用 SSL

安全套接字层 (Secure Sockets Layer, SSL) 在目录服务器和客户端之间提供加密通信和可选验证。可以通过 LDAP 使用 SSL，也可以将 SSL 与 DSML-over-HTTP 结合使用。默认情况下通过 LDAP 启用 SSL，但如果使用 DSML-over-HTTP，则可以轻松地启用 SSL。此外，还可以将复制配置为使用 SSL 在服务器之间进行安全通信。

如果在简单验证（绑定 DN 和密码）中使用 SSL，将对服务器所接收和发送的所有数据进行加密。加密可保证保密性和数据完整性。客户端可以选择使用证书，通过简单验证和安全层 (Simple Authentication and Security Layer,SASL) 进行目录服务器验证或第三方安全机制验证。基于证书的验证使用公钥密码学，以防止伪造和模拟客户端或服务器。

目录服务器可以在单独的端口上同时进行 SSL 通信和非 SSL 通信。出于安全考虑，您还可以将所有通信限制为使用 LDAP 安全端口。客户端验证也是可以配置的。可以将客户端验证设置为必需或允许。此设置用于确定您所执行的安全级别。

SSL 可支持 Start TLS 扩展操作，从而为常规 LDAP 连接提供安全性。客户端可以绑定到标准 LDAP 端口，然后使用传输层安全协议保护连接。Start TLS 操作允许客户端具有更大的灵活性，并且有助于简化端口分配。

SSL 提供的加密机制也可用于属性加密。启用 SSL 允许您在后缀上配置属性加密，以便在目录中存储数据时保护数据。有关详细信息，请参见加密属性值。

为了获取额外的安全性，您可以通过访问控制指令 (Access Control Instruction, ACI) 设置对目录内容的访问控制。ACI 需要特定的验证方法，并可确保只能通过安全通道传输数据。通过设置 ACI，可以弥补使用 SSL 和证书的不足之处。有关详细信息，请参见第 6 章，目录服务器访问控制。

默认情况下通过 LDAP 启用 SSL，如果使用 DSML-over-HTTP，则可以轻松地启用 SSL。此外，您可能需要对 SSL 配置的某些方面进行修改，如以下部分所述。

管理证书

本部分介绍如何在目录服务器中管理 SSL 证书。

要在目录服务器上运行 SSL，您必须使用自签名证书或公钥基础结构 (Public Key Infrastructure, PKI) 解决方案。

PKI 解决方案需要使用外部证书颁发机构 (Certificate Authority, CA)。要使用 PKI 解决方案，您需要包含公钥和私钥的 CA 签名服务器证书。此证书特定于一个目录服务器。此外还需要一个包含公钥的可信 CA 证书。可信 CA 证书可确保来自 CA 的所有服务器证书都是可信的。此证书有时称为 CA 根密钥或根证书。

注 –

如果将证书用于测试目的，您可能要使用自签名的证书。但是在生产中，使用自签名证书不太安全。在生产中，应使用可信的证书颁发机构 (Certificate Authority, CA) 证书。

本部分中的过程使用 dsadm 和 dsconf 命令。有关这些命令的信息，请参见 dsadm(1M) 和 dsconf(1M) 手册页。

本部分提供了以下有关在目录服务器上配置证书的信息：

Procedure查看默认的自签名证书

首次创建目录服务器实例时，它将包含默认的自签名证书。自签名证书是一个公钥/私钥对，其中的公钥由私钥进行签名。自签名证书的有效期为三个月。

您可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。

  1. 要查看默认的自签名证书，请使用以下命令：


    $ dsadm show-cert instance-path defaultCert

Procedure管理自签名证书

创建目录服务器实例时，将自动提供默认的自签名证书。

您可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。

  1. 要使用非默认设置创建自签名证书，请使用以下命令：


    $ dsadm add-selfsign-cert instance-path cert-alias

    其中 cert-alias 是您提供的用于标识证书的名称。

    要查看此命令的所有选项，请参见 dsadm(1M) 手册页或命令行帮助： 


    $ dsadm add-selfsign-cert --help

  2. 当自签名证书过期时，请停止服务器实例并续订证书。


    dsadm stop instance-path
$ dsadm renew-selfsign-cert instance-path cert-alias

  3. 重新启动服务器实例。


    $ dsadm start instance-path

Procedure请求 CA 签名的服务器证书

此过程介绍如何请求和安装用于目录服务器的 CA 签名服务器证书。

您可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。

  1. 生成 CA 签名的服务器证书请求。


    $ dsadm request-cert [-W cert-pwd-file] {-S DN | --name name [--org org] [--org-unit org-unit \
  [--city city] [--state state] [--country country]} [-o output-file] [-F format] instance-path

    例如，要为 Example 公司请求 CA 签名的服务器证书，请使用以下命令：


    $ dsadm request-cert --name host1 --org Example --org-unit Marketing \
 -o my_cert_request_file /local/ds

    为了完整地标识服务器，证书颁发机构可能需要此示例中显示的所有属性。有关每个属性的描述，请参见 dsadm(1M) 手册页。

    使用 dsadm request-cert 请求证书时，所生成的证书请求为二进制证书请求，除非将 ASCII 指定为输出格式。如果指定 ASCII，则生成的证书请求为 PEM 格式的 PKCS #10 证书请求。PEM 是由 RFC 1421 至 1424 (http://www.ietf.org/rfc/rfc1421.txt ) 指定的保密性增强的电子邮件格式，用于以 US-ASCII 字符表示 base64 编码的证书请求。请求的内容与以下示例类似：


    -----BEGIN NEW CERTIFICATE REQUEST-----
MIIBrjCCARcCAQAwbjELMAkGA1UBhMCVXMxEzARBgNVBAgTCkNBElGT1JOSUExLD
AqBgVBAoTI25ldHNjYXBlIGNvb11bmljYXRpb25zIGNvcnBvcmF0aWuMRwwGgYDV
QQDExNtZWxsb24umV0c2NhcGUuY29tMIGfMA0GCSqGSIb3DQEBAUAA4GNADCBiQK
BgCwAbskGh6SKYOgHy+UCSLnm3ok3X3u83Us7u0EfgSLR0f+K41eNqqWRftGR83e
mqPLDOf0ZLTLjVGJaHJn4l1gG+JDf/n/zMyahxtV7+T8GOFFigFfuxJaxMjr2j7I
vELlxQ4IfZgwqCm4qQecv3G+N9YdbjveMVXW0v4XwIDAQABAAwDQYJKoZIhvcNAQ
EEBQADgYEAZyZAm8UmP9PQYwNy4Pmypk79t2nvzKbwKVb97G+MT/gw1pLRsuBoKi
nMfLgKp1Q38K5Py2VGW1E47/rhm3yVQrIiwV+Z8Lcc=
-----END NEW CERTIFICATE REQUEST-----

  2. 按照程序将证书请求传送给证书颁发机构。

    获取证书颁发机构证书的过程取决于所使用的证书颁发机构。某些商业 CA 提供了允许您自动下载证书的 Web 站点。其他 CA 将在您请求证书后以电子邮件形式向您发送证书。

    发送请求之后，您必须等待 CA 对请求做出响应，即提供您的证书。请求的响应时间会有所不同。例如，如果您的 CA 在公司内部，则 CA 可能只需一两天即可响应您的请求。如果您选择的 CA 在公司外部，则 CA 可能需要几个星期才能响应您的请求。

  3. 保存从证书颁发机构收到的证书。

    请将证书备份到安全位置。如果丢失证书，您可以使用备份文件重新安装。可以在文本文件中保存证书。PEM 格式的 PKCS #11 证书与以下示例类似：


    -----BEGIN CERTIFICATE-----
MIICjCCAZugAwIBAgICCEEwDQYJKoZIhKqvcNAQFBQAwfDELMAkGA1UEBhMCVVMx
IzAhBgNVBAoGlBhbG9a2FWaWxsZGwSBXaWRnZXRzLCBJbmMuMR0wGwYDVQQLExRX
aWRnZXQgTW3FrZXJzICdSJyBVczEpMCcGAx1UEAxgVGVzdCBUXN0IFRlc3QgVGVz
dCBUZXN0IFlc3QgQ0EswHhcNOTgwMzEyMDIzMzUWhcNOTgwMzI2MDIzMpzU3WjBP
MQswCYDDVQQGEwJVUzEoMCYGA1UEChMfTmV0c2NhcGUgRGlyZN0b3J5VIFB1Ymxp
Y2F0aW9uczEWMB4QGA1UEAxMNZHVgh49dq2tLNvbjTBaMA0GCSqGSIb3DQEBAQUA
A0kAMEYkCQCksMR/aLGdfp4m0OiGgijG5KgOsyRNvwGYW7kfW+8mmijDtZaRjYNj
jcgpF3VnlbxbclX9LVjjNLC5737XZdAgEDozYwpNDARBglghkgBhvhCEAQEEBAMC
APAwHkwYDVR0jBBgwFAU67URjwCaGqZHUpSpdLxlzwJKiMwDQYJKoZIhQvcNAQEF
BQADgYEAJ+BfVem3vBOPBveNdLGfjlb9hucgmaMcQa9FA/db8qimKT/ue9UGOJqL
bwbMKBBopsDn56p2yV3PLIsBgrcuSoBCuFFnxBnqSiTS7YiYgCWqWaUA0ExJFmD6
6hBLseqkSWulk+hXHN7L/NrViO+7zNtKcaZLlFPf7d7j2MgX4Bo=
-----END CERTIFICATE-----

Procedure添加 CA 签名的服务器证书和可信的 CA 证书

此过程介绍如何安装用于目录服务器的 CA 签名服务器证书和可信 CA 证书。

您可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。

  1. 添加 CA 签名的服务器证书。


    $ dsadm add-cert --ca instance-path cert-alias cert-file

    其中 cert-alias 是您提供的用于标识证书的名称，cert-file 是包含 PEM 格式 PKCS #11 证书的文本文件。

    例如，要安装 CA 签名的服务器证书，可以使用与以下形式类似的命令：


    $ dsadm add-cert --ca /local/ds server-cert /local/safeplace/serv-cert-file

    证书现在已完成安装，但还不是可信证书。要信任 CA 签名的服务器证书，必须安装证书颁发机构证书。

  2. 添加可信的证书颁发机构证书。


    $ dsadm add-cert --ca -C instance-path cert-alias cert-file

    -C 选项表示该证书为可信的证书颁发机构证书。

    例如，要安装来自证书颁发机构的可信证书，可以使用以下命令：


    $ dsadm add-cert --ca -C /local/ds CA-cert /local/safeplace/ca-cert-file

  3. （可选的）验证已安装的证书。

    • 要列出所有服务器证书并显示其有效日期和别名，请键入：


      $ dsadm list-certs instance-path

      例如：


      $ dsadm list-certs /local/ds1
Enter the certificate database password:
Alias       Valid from Expires on Self-   Issued by          Issued to
                                  signed?                                     
----------- ---------- ---------- ------- -----------------  -----------------
serverCert  2000/11/10 2011/02/10 n       CN=CA-Signed Cert, CN=Test Cert,
            18:13      18:13              OU=CA,O=com        dc=example,dc=com
defaultCert 2006/05/18 2006/08/18 y       CN=host1,CN=DS,    Same as issuer
            16:28      16:28              dc=example,dc=com
2 certificates found

      默认情况下，目录代理服务器实例包含一个名为 defaultCert 的默认服务器证书。文本 Same as issuer 表明默认证书是自签名的服务器证书。

    • 要列出可信的 CA 证书，请键入：


      $ dsadm list-certs -C instance-path

      例如：


      $ dsadm list-certs -C /local/ds1
Enter the certificate database password:
Alias   Valid from Expires on Self-   Issued by           Issued to
                              signed?                                   
------- ---------- ---------- ------- -----------------   --------------
CA-cert 2000/11/10 2011/02/10 y       CN=Trusted CA Cert, Same as issuer
        18:12      18:12              OU=CA,O=com
1 certificate found

    • 要查看证书的详细信息（包括证书的过期日期），请键入：


      $ dsadm show-cert instance-path cert-alias

      例如，要查看服务器证书，请键入：


      $ dsadm show-cert /local/ds1 "Server-Cert"
Enter the certificate database password:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
        Signature Algorithm: PKCS #1 MD5 With RSA Encryption
        Issuer:
            "CN=Server-Cert,O=Sun,C=US"
        Validity:
            Not Before: Fri Nov 10 18:12:20 2000
            Not After : Thu Feb 10 18:12:20 2011
        Subject:
            "CN=CA Server Cert,OU=ICNC,O=Sun,C=FR"
        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    bd:76:fc:29:ca:06:45:df:cd:1b:f1:ce:bb:cc:3a:f7:
                    77:63:5a:82:69:56:5f:3d:3a:1c:02:98:72:44:36:e4:
                    68:8c:22:2b:f0:a2:cb:15:7a:c4:c6:44:0d:97:2d:13:
                    b7:e3:bf:4e:be:b5:6a:df:ce:c4:c3:a4:8a:1d:fa:cf:
                    99:dc:4a:17:61:e0:37:2b:7f:90:cb:31:02:97:e4:30:
                    93:5d:91:f7:ef:b0:5a:c7:d4:de:d8:0e:b8:06:06:23:
                    ed:5f:33:f3:f8:7e:09:c5:de:a5:32:2a:1b:6a:75:c5:
                    0b:e3:a5:f2:7a:df:3e:3d:93:bf:ca:1f:d9:8d:24:ed
                Exponent: 65537 (0x10001)
    Signature Algorithm: PKCS #1 MD5 With RSA Encryption
    Signature:
        85:92:42:1e:e3:04:4d:e5:a8:79:12:7d:72:c0:bf:45:
        ea:c8:f8:af:f5:95:f0:f5:83:23:15:0b:02:73:82:24:
        3d:de:1e:95:04:fb:b5:08:17:04:1c:9d:9c:9b:bd:c7:
        e6:57:6c:64:38:8b:df:a2:67:f0:39:f9:70:e9:07:1f:
        33:48:ea:2c:18:1d:f0:30:d8:ca:e1:29:ec:be:a3:43:
        6f:df:03:d5:43:94:8f:ec:ea:9a:02:82:99:5a:54:c9:
        e4:1f:8c:ae:e2:e8:3d:50:20:46:e2:c8:44:a6:32:4e:
        51:48:15:d6:44:8c:e6:d2:0d:5f:77:9b:62:80:1e:30
    Fingerprint (MD5):
        D9:FB:74:9F:C3:EC:5A:89:8F:2C:37:47:2F:1B:D8:8F
    Fingerprint (SHA1):
        2E:CA:B8:BE:B6:A0:8C:84:0D:62:57:85:C6:73:14:DE:67:4E:09:56

    Certificate Trust Flags:
        SSL Flags:
            Valid CA
            Trusted CA
            User
            Trusted Client CA
        Email Flags:
            User
        Object Signing Flags:
            User

Procedure续订过期的 CA 签名服务器证书

CA 签名服务器证书（公钥和私钥）过期时，可以使用此过程续订证书。

您可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。

  1. 从证书颁发机构获取已更新的 CA 签名服务器证书。

  2. 在收到更新的证书时，请停止服务器实例并安装证书。


    $ dsadm stop instance-path
$ dsadm renew-cert instance-path cert-alias cert-file

  3. 重新启动服务器实例。


    $ dsadm start instance-path

Procedure导出和导入 CA 签名的服务器证书

在某些情况下，您可能需要导出证书的公钥和私钥，以便日后可以导入该证书。例如，您可能希望其他服务器使用该证书。

此过程中的命令可用于包含通配符的证书（如 "cn=*,o=example"）。

您可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。

  1. 导出证书。


    $ dsadm export-cert [-o output-file] instance-path cert-alias

    例如：


    $ dsadm export-cert -o /tmp/first-certificate /local/ds1 "First Certificate"
$ dsadm export-cert -o /tmp/first-ca-server-certificate /local/ds1/ defaultCert
Choose the PKCS#12 file password:
Confirm the PKCS#12 file password:
$ ls /tmp
first-ca-server-certificate

  2. 导入证书。


    $ dsadm import-cert instance-path cert-file

    例如，将证书导入 host1 上的服务器实例：


    $ dsadm import-cert -h host1 /local/ds2 /tmp/first-ca-server-certificate
Enter the PKCS#12 file password:

  3. （可选的）如果已将证书导入服务器，请将该服务器配置为使用导入的证书。


    $ dsconf set-server-prop -e -h host -p port -w - ssl-rsa-cert-name:server-cert

配置证书数据库密码

默认情况下，目录服务器通过存储的密码在内部管理 SSL 证书数据库密码。在管理证书时，用户无需键入证书密码或指定密码文件。此选项不太安全，因为只是隐藏了密码，而不会对密码进行加密。

但是，如果要对证书使用进行更多控制，则可以配置服务器，以提示用户在命令行中输入密码。在这种情况下，对于除 autostart、 backup、 disable-service、enable-service、info、 reindex、 restore 和 stop 之外的所有 dsadm 子命令，用户都必须键入证书数据库密码。证书数据库位于目录 instance-path/alias 中。

Procedure将服务器配置为提示用户输入证书密码

您可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。

  1. 停止服务器。


    $ dsadm stop instance-path

  2. 将密码提示标志设置为 on。


    $ dsadm set-flags instance-path cert-pwd-prompt=on

    系统将要求您选择新的证书密码。

  3. 启动服务器。


    $ dsadm start instance-path

备份和恢复目录服务器的证书数据库

备份目录服务器实例时，将会备份目录服务器配置和证书。备份的证书存储在 archive-path/alias 目录中。

有关如何备份和恢复目录服务器的信息，请参见创建备份以用于灾难恢复。

配置 SSL 通信

本部分包含与禁用和启用 SSL 有关的过程。

禁用非安全通信

创建服务器实例时，默认情况下将创建 LDAP 端口和安全 LDAP 端口 (LDAPS)。但是，在某些情况下可能需要禁用非 SSL 通信，以便服务器只通过 SSL 进行通信。

SSL 连接是使用默认自签名证书启用的。如果需要，您可以安装自己的证书。有关在启动服务器后管理证书和禁用 SSL 的说明，请参见第 5 章，目录服务器安全性。有关证书、证书数据库以及获取 CA 签名服务器证书的概述，请参见《Sun Java System Directory Server Enterprise Edition 6.1 Reference》。

Procedure禁用 LDAP 端口

您可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。

  1. 禁用 LDAP 端口。

    要禁用非安全点，您必须绑定到 LDAP 安全端口。此示例显示了与主机服务器 host1 上的默认 LDAP 安全端口 1636 的绑定。


    $ dsconf set-server-prop -h host1 -P 1636 ldap-port:disabled

  2. 重新启动服务器以使更改生效。


    $ dsadm restart /local/ds

    现在，您已不再绑定到非安全端口 1389。

选择加密密码

密码是用于加密和解密数据的算法。一般而言，密码在加密期间所使用的位数越多，加密就越严密或越安全。SSL 的密码也由所使用的消息验证类型进行标识。消息验证是计算校验和（用于保证数据完整性）的另一种算法。

当客户端初始化与服务器的 SSL 连接时，客户端和服务器必须就用于加密信息的密码达成一致。在任何双向加密过程中，双方都必须使用相同的密码。所使用的密码取决于服务器所保存的密码列表的当前顺序。服务器将选择客户端所提供的与列表中的密码相匹配的第一个密码。目录服务器的默认密码值为 all，表示基础 SSL 库支持的所有已知的安全密码。但是，您可以修改此值以便只接受特定密码。

有关可用于目录服务器的密码的详细信息，请参见《Sun Java System Directory Server Enterprise Edition 6.1 Reference》。

Procedure选择加密密码

您可以使用 DSCC 执行此任务。有关信息，请参见目录服务控制中心界面和 DSCC 联机帮助。

  1. 确保已为服务器启用 SSL。

    请参见配置 SSL 通信。

  2. 查看可用的 SSL 密码。


    $ dsconf get-server-prop -h host -p port ssl-supported-ciphers
ssl-supported-ciphers  :  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
ssl-supported-ciphers  :  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
ssl-supported-ciphers  :  TLS_DHE_RSA_WITH_AES_256_CBC_SHA
ssl-supported-ciphers  :  TLS_DHE_DSS_WITH_AES_256_CBC_SHA 
...

  3. （可选的）如果要保留非加密数据的副本，请在设置 SSL 密码之前导出该数据。

    请参见导出到 LDIF。

  4. 设置 SSL 密码。


    $ dsconf set-server-prop -h host -p port ssl-cipher-family:cipher

    例如，要将密码系列设置为 SSL_RSA_WITH_RC4_128_MD5 和 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA，请键入：


    $ dsconf set-server-prop -h host1 -p 1636 ssl-cipher-family:SSL_RSA_WITH_RC4_128_MD5 \
 ssl-cipher-family:SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
Enter "cn=Directory Manager" password:  
Before setting SSL configuration, export Directory Server data. 
Do you want to continue [y/n] ? y
Directory Server must be restarted for changes to take effect.

  5. （可选的）在现有列表中添加 SSL 密码。

    如果已指定了密码列表，并且要添加密码，请使用以下命令：


    $ dsconf set-server-prop -h host -p port ssl-cipher-family+:cipher

    例如，要添加 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA 密码，请键入：


    $ dsconf set-server-prop -h host1 -P 1636 \
 ssl-cipher-family+:SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

  6. 重新启动服务器以使更改生效。


    $ dsadm restart /local/ds

配置证书级别和验证方法

应用于客户端的安全模型是通过证书级别和验证方法组合定义的。

目录服务器支持以下证书级别：

客户端验证是服务器用于验证客户端标识的一种机制。

可使用以下任一方式执行客户端验证：

本部分提供了以下有关在目录服务器上配置两种 SASL 机制的信息。

有关配置安全性的详细信息，请参见将 LDAP 客户端配置为使用安全性。

在目录服务器中设置 SASL 加密级别

在配置 SASL 机制之前，必须指定是否需要加密。SASL 加密的要求由强度安全系数 (Strength Security Factor, SSF) 的最大值和最小值进行设置。

属性 dsSaslMinSSF(5dsat) 和 dsSaslMaxSSF(5dsat) 表示加密密钥的长度，这些属性存储在 cn=SASL, cn=security, cn=config 中。

服务器允许任何级别的加密，包括不加密。这意味着目录服务器接受大于 256 的 dsSaslMinSSF 和 dsSaslMaxSSF 值。但目前没有任何 SASL 机制支持大于 128 的 SSF。目录服务器会对这些值进行调整，使其不高于 SSF 可用的最大值 (128)。因此，实际的最大 SSF 可能低于配置的最大值，这取决于可用的基础机制。

SASL 安全系数验证依赖于以下两个主要因素：服务器和客户端应用程序所请求的最小系数和最大系数，以及基础安全组件提供的可用加密机制。概括来说，服务器和客户端将尝试使用最大的可用安全系数，该系数小于或等于两者设置的最大系数，但大于或等于两者设置的最小系数。

目录服务器的默认最小 SASL 安全系数 dsSaslMinSSF 为 0，表示没有任何保护。实际的最小值取决于客户端设置，除非您更改目录服务器的最小值。实际上，应该将最小值设置为实际希望服务器和客户端使用的最低级别。如果服务器和客户端无法协商出符合最低要求的机制，则不会建立连接。

Procedure要求 SASL 加密

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

  1. 如果要求 SASL 加密，请将 dsSaslMinSSF 值设置为所需的最小加密。


    $ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: cn=SASL, cn=security, cn=config
changetype: modify
replace: dsSaslMinSSF
dsSaslMinSSF: 128
^D

Procedure不允许 SASL 加密

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

  1. 如果不允许 SASL 加密，请将 dsSaslMinSSF 和 dsSaslMaxSSF 的值都设置为零。


    $ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: cn=SASL, cn=security, cn=config
changetype: modify
replace: dsSaslMinSSF
dsSaslMinSSF: 0

replace: dsSaslMaxSSF
dsSaslMaxSSF: 0
^D

通过 DIGEST-MD5 进行 SASL 验证

DIGEST-MD5 机制通过比较客户端发送的散列值与用户密码的散列值来验证客户端。但是，由于此机制必须读取用户密码，因此要通过 DIGEST-MD5 进行验证的所有用户在目录中都必须具有 {CLEAR} 密码。在目录中存储 {CLEAR} 密码时，必须确保通过 ACI 正确限制对密码值的访问权限，如第 6 章，目录服务器访问控制中所述。此外，还需要在后缀中配置属性加密，如加密属性值中所述。

Procedure配置 DIGEST-MD5 机制

以下过程介绍如何将目录服务器配置为使用 DIGEST-MD5。

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

  1. 使用 ldapsearch 命令验证 DIGEST-MD5 是否为根条目上的 supportedSASLMechanisms 属性值。

    例如，以下命令显示启用了哪些 SASL 机制：


    $ ldapsearch -h host -p port -D cn=admin,cn=Administrators,cn=config -w - \
 -s base -b "" "(objectclass=*)" supportedSASLMechanisms
Enter bind password:
dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: GSSAPI
^D

  2. 如果未启用 DIGEST-MD5，请将其启用。


    $ ldapmodify -h host -p port -D cn=admin,cn=Administrators,cn=config -w - 
Enter bind password:
dn: cn=SASL, cn=security, cn=config
changetype: modify
add: dsSaslPluginsEnable
dsSaslPluginsEnable: DIGEST-MD5
-
replace: dsSaslPluginsPath
dsSaslPluginsPath: SASL-library
^D

    其中 SASL-library 为以下任一选项：

    JES 安装

    /usr/lib/mps/sasl2

    Zip 安装

    install-path/dsee6/private/lib

  3. 为 DIGEST-MD5 使用默认标识映射，或创建新的映射。

    有关信息，请参见DIGEST-MD5 标识映射。

  4. 对于将使用 DIGEST-MD5 通过 SSL 访问服务器的所有用户，确保以 {CLEAR} 形式存储密码。

    有关密码存储模式的信息，请参见第 7 章，目录服务器密码策略。

  5. 如果修改了 SASL 配置条目或某个 DIGEST-MD5 标识映射条目，请重新启动目录服务器。

DIGEST-MD5 标识映射

SASL 机制的标识映射尝试将 SASL 标识的凭证与目录中的用户条目进行匹配。如果映射找不到与 SASL 标识相对应的 DN，则验证将会失败。有关此机制的完整描述，请参见《Sun Java System Directory Server Enterprise Edition 6.1 Reference》。

SASL 标识是称为主体的字符串，以特定于每种机制的格式表示用户。在 DIGEST-MD5 中，客户端应创建包含 dn: 前缀和 LDAP DN 的主体，或者创建包含 u: 前缀（后跟由客户端确定的任何文本）的主体。在映射期间，客户端发送的主体可用于 ${Principal} 占位符中。

服务器配置中的以下条目是 DIGEST-MD5 的默认标识映射：


dn: cn=default,cn=DIGEST-MD5,cn=identity mapping,cn=config
objectClass: top
objectClass: nsContainer
objectClass: dsIdentityMapping
objectClass: dsPatternMatching
cn: default
dsMatching-pattern: \${Principal}
dsMatching-regexp: dn:(.*)
dsMappedDN: \$1

此标识映射假定主体的 dn 字段包含目录中现有用户的精确 DN。

Procedure定义您自己的 DIGEST-MD5 标识映射

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

  1. 编辑默认的映射条目，或者在 cn=DIGEST-MD5,cn=identity mapping,cn=config 下创建新的映射条目。

    以下命令显示应如何定义此映射：


    $ ldapmodify -a -h host1 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind password:
dn: cn=unqualified-username,cn=DIGEST-MD5,cn=identity mapping
cn=config
objectclass: dsIdentityMapping
objectclass: dsPatternMatching
objectclass: nsContainer
objectclass: top
cn: unqualified-username
dsMatching-pattern: \${Principal}
dsMatching-regexp: u:(.*)@(.*)\\.com
dsSearchBaseDN: dc=\$2
dsSearchFilter: (uid=\$1)

  2. 重新启动目录服务器以使新映射生效。

通过 GSSAPI 进行 SASL 验证（仅适用于 Solaris 操作系统）

通过 SASL 执行的通用安全服务 API (Generic Security Service API , GSSAPI) 允许您使用第三方安全系统（如 Kerberos V5）对客户端进行验证。GSSAPI 库仅适用于 Solaris 操作系统 SPARC® 平台。Sun 建议您在 Sun Enterprise Authentication MechanismTM 1.0.1 服务器上安装 Kerberos V5 实现。

服务器使用 GSSAPI 验证用户的标识。然后，SASL 机制将应用 GSSAPI 映射规则获取 DN，该 DN 为此连接期间所有操作的绑定 DN。

Procedure配置 Kerberos 系统

可以按照制造商的说明来配置 Kerberos 软件。如果您使用的是 Sun Enterprise Authentication Mechanism 1.0.1 服务器，请使用此过程。

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

  1. 对 /etc/krb5 中的文件进行配置。

  2. 创建 Kerberos 数据库以存储用户和服务。

  3. 在该数据库中，创建 LDAP 服务的主体。


    $ ldap/server-FQDN@realm

    其中 server-FQDN 是目录服务器的全限定域名。

  4. 启动 Kerberos 守护进程。

    注 –

    必须在主机上配置 DNS。

    有关上述每个步骤的详细说明，请参见软件文档。此外，请参见使用 GSSAPI 和 SASL 进行 Kerberos 验证的示例配置。

Procedure配置 GSSAPI 机制

以下过程介绍如何在 Solaris 操作系统上将目录服务器配置为使用 GSSAPI：

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

  1. 创建 GSSAPI 的默认标识映射，以及任何自定义映射，如GSSAPI 标识映射中所述。

  2. 创建用于存储服务密钥的密钥表。

    您的 LDAP 服务密钥存储在密钥表中。

    1. 确保只有目录服务器用户可以读取此密钥表。

    2. 更改文件名，使其不同于默认的 /etc/krb5/krb5.keytab。

    3. 设置环境变量 KRB5_KTNAME 以确保使用新的密钥表，而不使用默认密钥表。

  3. 如果修改了 SASL 配置条目或某个 GSSAPI 标识映射条目，请重新启动目录服务器。

    请注意，必须在主机上配置 DNS。

GSSAPI 标识映射

SASL 机制的标识映射尝试将 SASL 标识的凭证与目录中的用户条目进行匹配。如果映射找不到与 SASL 标识相对应的 DN，则验证将会失败。

SASL 标识是称为主体的字符串，以特定于每种机制的格式表示用户。在使用 GSSAPI 的 Kerberos 中，主体为 uid [/instance][@ realm] 格式的标识。uid 可以包含后跟领域（通常为域名）的实例标识符，实例标识符和领域都是可选的。例如，以下字符串都是有效的用户主体：


bjensen
bjensen/Sales
bjensen@EXAMPLE.COM
bjensen/Sales@EXAMPLE.COM

最初，在目录中未定义任何 GSSAPI 映射。可以根据客户端定义所用主体的方式，定义默认映射以及所需的任何自定义映射。

Procedure定义 GSSAPI 的标识映射

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

  1. 在 cn=GSSAPI,cn=identity mapping, cn=config 下创建新的映射条目。

    有关标识映射条目中的属性定义，请参见《Sun Java System Directory Server Enterprise Edition 6.1 Reference》。GSSAPI 映射的示例位于 instance-path/ldif/identityMapping_Examples.ldif 中。

    此文件中的默认 GSSAPI 映射假定主体只包含一个用户 ID。此映射可确定目录固定分支中的某个用户：


    dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config
objectclass: dsIdentityMapping
objectclass: nsContainer
objectclass: top
cn: default
dsMappedDN: uid=\${Principal},ou=people,dc=example,dc=com

    此文件中的另一个示例说明当用户 ID 包含在具有已知领域的主体中时如何确定用户 ID。


    dn: cn=same_realm,cn=GSSAPI,cn=identity mapping,cn=config
objectclass: dsIdentityMapping
objectclass: dsPatternMatching
objectclass: nsContainer
objectclass: top
cn: same_realm
dsMatching-pattern: \${Principal}
dsMatching-regexp: (.*)@EXAMPLE.COM
dsMappedDN: uid=\$1,ou=people,dc=EXAMPLE,dc=COM

  2. 重新启动目录服务器以使新映射生效。

将 LDAP 客户端配置为使用安全性

以下部分将介绍如何在要与目录服务器建立安全连接的 LDAP 客户端中配置和使用 SSL。在 SSL 连接中，服务器会将其证书发送到客户端。客户端必须先通过信任服务器证书来验证该服务器。然后，客户端可以选择初始化一种客户端验证机制，方法是为两种 SASL 机制中的某种机制发送自身的证书或信息。SASL 机制包括 DIGEST-MD5 和使用 Kerberos V5 的 GSSAPI。

以下部分使用 ldapsearch 工具作为启用了 SSL 的 LDAP 客户端示例。

要在其他 LDAP 客户端上配置 SSL 连接，请参见随应用程序提供的文档。

注 –

某些客户端应用程序实现 SSL，但不验证服务器是否具有可信证书。这些客户端应用程序使用 SSL 协议提供数据加密，但无法保证保密性，也不能防止身份模拟。

以下部分介绍如何配置 LDAP 客户端以使用安全性：

在客户端中使用 SASL DIGEST-MD5

在客户端中使用 DIGEST-MD5 机制时，您不必安装用户证书。但是，如果要使用加密的 SSL 连接，则仍须信任服务器证书，如管理证书中所述。

指定领域

领域定义用于从中选择验证标识的名称空间。在 DIGEST-MD5 验证中，您必须通过特定领域的验证。

目录服务器使用计算机的全限定主机名作为 DIGEST-MD5 的默认领域。服务器使用 nsslapd-localhost 配置属性中包含的主机名的小写值。

如果未指定领域，将使用服务器提供的默认领域。

指定环境变量

在 UNIX 环境中，必须设置 SASL-PATH 环境变量，以便 LDAP 工具可以找到 DIGEST-MD5 库。DIGEST-MD5 库是由 SASL 插件动态装入的共享库。请按如下方式设置 SASL_PATH 环境变量：


export SASL_PATH=SASL-library

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

ldapsearch 命令的示例

可以在不使用 SSL 的情况下执行 DIGEST-MD5 客户端验证。以下示例使用默认的 DIGEST-MD5 标识映射来确定绑定 DN：


$ ldapsearch -h host1 -p 1389 \
 -o mech=DIGEST-MD5 [ \
 -o realm="example.com"] \
 -o authid="dn:uid=bjensen,dc=example,dc=com" \
 -w - \
 -o authzid="dn:uid=bjensen,dc=example,dc=com" \
 -o secProp="minssf=56,maxssf=256,noplain" \
 -b "dc=example,dc=com" "(givenname=Richard)"

上述示例说明如何使用 -o（小写字母 o）选项指定 SASL 选项。领域是可选的，但如果指定，则必须是服务器主机的全限定域名。authid 和 authzid 必须同时存在且完全相同，但不会使用适用于代理操作的 authzid。 -w 选项适用于 authid。

authid 的值是标识映射中使用的主体。authid 应包含 dn: 前缀后跟目录中的有效用户 DN，或者包含 u: 前缀后跟由客户端确定的任何字符串。authid 的这种用法允许您使用DIGEST-MD5 标识映射中显示的映射。

最常用的配置是使用 SSL 连接通过 LDAPS 安全端口提供加密，以及使用 DIGEST-MD5 提供客户端验证。以下示例将通过 SSL 执行相同的操作：


$ ldapsearch -h host1 -p 1636 \
 -Z -P .mozilla/bjensen/BJE6001.slt/cert8.db \
 -N "cert-example" -w - \
 -o mech=DIGEST-MD5 [-o realm="example.com"] \
 -o authid="dn:uid=bjensen,dc=example,dc=com" \
 -o authzid="dn:uid=bjensen,dc=example,dc=com" \
 -o secProp="minssf=0,maxssf=0,noplain" \
 -b "dc=example,dc=com" "(givenname=Richard)"

在此示例中，由于操作是通过 SSL 执行的，因此 ldapsearch 命令需要使用 -N 和 -w 选项。但是，这些选项不会用于客户端验证。服务器将执行 authid 值中主体的其他 DIGEST-MD5 标识映射。

在客户端中使用 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" 表明绑定是由正确的用户执行的。

让渡验证

让渡验证 (Pass-through authentication, PTA) 是一种机制，此机制将按照绑定 DN 过滤绑定请求。一个目录服务器（委托方）收到绑定请求后，可以基于过滤器查询另一个目录服务器（被委托方）以验证绑定请求。作为此功能的一部分，对于未必存储在本地数据库中的条目，PTA 插件允许委托方目录服务器接受基于密码的简单绑定操作。

DSCC 也可使用 PTA 插件与服务器进行专用通信。在 DSCC 中注册服务器实例时，将启用 PTA 插件，并将 DSCC URL 作为参数进行添加。


$ dsconf get-plugin-prop -h host -p port "Pass Through Authentication" enabled argument
argument  :  ldap://DSCC_URL:DSCC_PORT/cn=dscc
enabled   :  on
注 –

请尽量避免针对个人使用而修改 PTA 插件。修改 PTA 插件可能会导致 DSCC 出现访问问题。

如果无法避免修改 PTA 插件，则必须执行以下操作：

如果 PTA 插件已被禁用，或者已从参数中删除 DSCC URL，则服务器实例在 DSCC 中将显示为 inaccessible。如果发生这种情况，DSCC 将自动为您提供用于重置 PTA 插件的选项。