第 11 章管理验证和加密

Directory Server 支持多种提供安全可信的网络通讯的机制。LDAPS 是运行在安全套接字层 (SSL) 基础上的标准 LDAP 协议，用于加密数据并可随意使用证书进行验证。

Directory Server 还支持启动传输层安全性 (Start TLS) 扩展操作，以便在原来未加密的 LDAP 连接上启用 TLS。

此外，Directory Server 还支持简单身份验证和安全层 (SASL) 上的综合安全服务应用程序接口 (GSSAPI)。这样，您就可以在 Solaris 操作系统上使用 Kerberos Version 5 安全协议。然后，标识映射机制会将 Kerberos Principal 与目录中的标识相关联。

Directory Server 中的 SSL 简介

Directory Server 中的 SSL 简介

安全套接字层 (SSL) 提供加密通讯以及 Directory Server 与其客户机之间的可选验证服务。可以为 LDAP 和 DSML-over-HTTP 两种协议启用 SSL，从而为所有的服务器连接提供安全性。另外，可以配置复制机制和链接后缀机制，以使用 SSL 保证服务器之间的安全通讯。

利用简单验证（绑定 DN 和密码）使用 SSL 可以加密所有发送至服务器的数据以及服务器发送的数据，以保证保密性和数据完整性。客户机还可以选择使用证书对 Directory Server 进行验证，或通过简单验证和安全层 (SASL) 对第三方安全机制进行验证。基于证书的验证使用公共密钥加密方法，以防止伪装和假冒客户机或服务器。

Directory Server 可以在不同的端口同时使用 SSL 和非 SSL 通讯。为了安全起见，您也可以将所有通讯都限制在安全端口。客户机验证也是可配置的，它可能是必需的，或者仅使用它来确定要实施的安全级别。

启用 SSL 也会启用支持 Start TLS 扩展操作，Start TLS 扩展操作提供在普通 LDAP 连接上的安全性。客户机可以绑定至非 SSL 端口，然后使用“传输层安全性 (TLS)”协议启动 SSL 连接。Start TLS 操作为客户机提供了更大的灵活性，有助于简化端口分配。

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

要获得额外的安全性，可以根据客户机的 SSL 和证书的使用情况对目录内容的访问控制进行配置。可以定义访问控制指令 (ACI)，它需要特定的验证方法，从而确保数据仅能通过一个安全通道进行传输。有关详细信息，请参见绑定规则。

启用 SSL 的步骤摘要

为您的 Directory Server 获得并安装证书，并将 Directory Server 配置为信任证书颁发机构的证书。此过程包括：

必要时创建证书数据库。

生成并发送证书请求，将其从服务器发送至将提供服务器证书的证书颁发机构。

在服务器中安装新的证书。

信任证书颁发机构及其颁发的所有证书。

在目录中激活并配置 SSL，包括 LDAP 和 DSML 操作的安全端口。还可以配置 Directory Server Console 以使用 SSL 访问服务器。

还可以选择为以下一个或多个客户机验证机制配置服务器：

默认的基于证书的验证。

SASL 上的 DIGEST_MD5 验证机制。

允许使用 Kerberos V5 安全机制的 SASL 上的 GSSAPI 验证。

在完成这些步骤后，对客户机进行配置，以便在与 Directory Server 通讯时使用 SSL，包括要使用的任一可选验证机制。请参见 ldapsearch 和 ldapmodify 等工具。

也可以使用 certutil 工具执行上述某些步骤，以便通过命令行来管理证书。SUNWtlsu 软件包中提供有此工具。

获得并安装服务器证书

本节介绍如何创建证书数据库、获得并安装用于 Directory Server 的证书，以及如何将 Directory Server 配置为信任证书颁发机构 (CA) 的证书。

创建证书数据库

第一次在服务器上配置 SSL 时，必须为安全设备设置密码。如果未使用外部硬件安全设备，则内部安全设备就是存储在下列文件中的证书和密钥数据库：

ServerRoot/alias/slapd-serverID-cert8.db
ServerRoot/alias/slapd-serverID-key3.db

如果 serverID 包含大写字母，则必须使用下面的命令行步骤创建证书数据库。

使用控制台

使用控制台时，在第一次调用证书管理器对话框时，服务器将自动创建证书数据库文件：

在 Directory Server Console 的顶级“任务”选项卡上，单击“管理证书”按钮。或者，显示“任务”选项卡后，在“控制台>安全性”菜单中选择“管理证书”项。

服务器将自动创建证书和密钥数据库，并要求您为安全设备设置密码。此密码将保护服务器中存储的证书的专用密钥。输入两次密码，对其进行确认，然后单击“确定”。

使用命令行

通过命令行创建证书数据库文件时，必须使用下面步骤中显示的路径和文件名前缀，这样服务器就可以找到它们。

在服务器主机上，请使用以下命令创建证书数据库：

certutil -N -d ServerRoot/alias -P slapd-LCserverID-

其中 LCserverID 为全部使用小写字母的服务器名称。

此工具将提示您输入密码来保护证书的密钥。

生成证书请求

使用下列步骤之一可以生成 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-----

使用控制台

显示“管理证书”对话框。

选择“服务器证书”选项卡，并单击“请求”按钮。

出现“证书请求向导”。

如果已经安装了一个允许服务器与 CA 直接进行通讯的插件，则现在可以选择此插件。否则，必须通过电子邮件或 Web 站点传输生成的请求，以手动请求证书。单击“下一步”以继续。

在空白文本字段中输入“请求方信息”：

服务器名称。 输入 Directory Server 的完全限定主机名，该主机名是在 DNS 查找中使用的名称（例如，east.example.com）。

组织。输入您公司或机构的法定名称。大多数 CA 要求您出示法律凭证，如企业许可证的副本，以验证此信息。

组织单位。（可选）。输入您公司内部部门或业务单位的描述性名称。

位置。（可选）。输入您公司所在的城市的名称。

省或自治区。输入您公司所在的省或自治区的全名（非缩写）。

国家/地区。选择您国家/地区的双字符缩写（ISO 格式）。美国的国家/地区代码为 US。Directory Server Administration Reference 包含一份 ISO 国家/地区代码列表。

单击“下一步”以继续。

输入安全设备的密码，然后单击“下一步”。此密码是在创建证书数据库中设置的。

选择“复制到剪贴板”或“保存到文件”以保存须发送到证书颁发机构的证书请求信息。

单击“完成”退出“证书请求向导”。

使用命令行

请使用以下命令创建服务器证书请求：

certutil -R \
-s "cn=serverName,ou=division,o=company,l=city,st=state,c=country" \
-a -d ServerRoot/alias -P slapd-serverID-

-s 选项指定了请求的服务器证书的 DN。通常，证书颁发机构会要求此示例中显示的所有属性，以完整地识别此服务器。请参见上面的步骤 4，以获取每个属性的说明。

certutil 工具将提示您输入服务器的密钥数据库密码。此密码是在创建证书数据库中设置的。然后，此工具将生成 PEM 编码文本格式的 PKCS #10 证书请求。

安装服务器证书

服务器会根据请求的步骤将上节中的请求传输至证书颁发机构。例如，可能会要求您以电子邮件的形式发送证书请求，或者也可以通过 CA 的 Web 站点输入请求。

发送了请求后，必须等待 CA 对您的证书作出响应。请求响应时间会有所不同。例如，如果 CA 在您公司内部，可能只需要一到两天时间就可响应请求。如果选择了公司外部的 CA，则可能需要用几周的时间来响应请求。

当 CA 发送响应时，一定要将信息保存到一个文本文件中。PEM 格式的 PKCS #11 证书将类似于以下示例。

还应将证书数据备份到一个安全的地方。如果系统曾丢失证书数据，则可使用备份文件重新安装证书。

使用控制台

显示“管理证书”窗口。

选择“服务器证书”选项卡，并单击“安装”。

显示“证书安装向导”。

从以下证书位置选项中选择一个选项：

确认显示的证书信息是否正确，然后单击“下一步”。

指定证书的名称，然后单击“下一步”。这就是要在证书表中显示的名称。

提供保护专用密钥的密码以验证证书。此密码与您在创建证书数据库的步骤 2 中提供的密码一致。完成后单击“完成”。

您的新证书将显示在“服务器证书”选项卡上的列表中。现在您的服务器已为激活 SSL 准备完毕。

使用命令行

请使用以下命令在证书数据库中安装新的服务器证书：

certutil -A -n "certificateName" -t "u,," -a -i certFile \
-d ServerRoot/alias -P slapd-serverID-

其中 certificateName 是您提供的用来标识证书的名称，certFile 是包含 PEM 格式的 PKCS #11 证书的文本文件。-t "u,," 选项表示这是一个用于 SSL 通讯的服务器证书。

也可以选择使用以下 certutil 命令来验证已安装的证书：

certutil -L -d ServerRoot/alias -P slapd-serverID-

列出的具有信任属性 u,, 的证书是服务器证书。

信任证书颁发机构

配置 Directory Server 以信任证书颁发机构，配置过程由获得 CA 证书和将其安装到服务器的证书数据库两部分组成。此过程根据您所使用的证书颁发机构的不同而有所区别。某些商业 CA 提供允许您自动下载证书的 Web 站点，而有些 CA 则根据您的请求以电子邮件的形式将证书发送给您。

使用控制台

获得 CA 证书后，可使用“证书安装向导”配置 Directory Server 以信任证书颁发机构。

显示“管理证书”窗口。

选择“CA 证书”选项卡，并单击“安装”。

显示“证书安装向导”。

如果已将 CA 的证书保存到文件，请在提供的字段中输入路径。如果通过电子邮件收到了 CA 的证书，请将包含标头的证书复制并粘贴到提供的文本字段中。单击“下一步”。

确认显示的证书信息与证书颁发机构提供的信息一致，然后单击“下一步”。

指定证书的名称，然后单击“下一步”。

选择信任此 CA 的目的。可以选择二者之一或全选：

接受来自客户机的连接（客户机验证）。如果 LDAP 客户机通过提交此 CA 颁发的证书来执行基于证书的客户机验证，则请选中此复选框。

接受来自其他服务器的连接（服务器验证）。您的服务器通过 SSL 与另一个具有此 CA 所颁发证书的服务器进行通讯的过程中，如果此服务器担当复制提供者或链接多路复用器的角色，请选中此复选框。

单击“完成”退出该向导。

使用命令行

也可以使用以下命令安装受信任的 CA 证书：

certutil -A -n "CAcertificateName" -t "trust,," -a -i certFile \
-d ServerRoot/alias -P slapd-serverID-

其中 CAcertificateName 是提供的用来标识受信任 CA 的名称，certFile 是包含 PEM 编码文本格式的 PKCS #11 颁发机构证书的文本文件，trust 是以下代码之一：

T——表示此 CA 颁发的客户机证书是受信任的。如果 LDAP 客户机通过提交此 CA 颁发的证书来执行基于证书的客户机验证，则请使用此代码。

C——表示此 CA 颁发的服务器证书是受信任的。您的服务器通过 SSL 与另一个具有此 CA 所颁发证书的服务器进行通讯的过程中，如果此服务器担当复制提供者或链接多路复用器的角色，请使用此代码。

CT——表示此 CA 颁发的客户机证书和服务器证书都是受信任的。如果上面两种情况均适用于此 CA，请使用此代码。

也可以选择使用以下 certutil 命令来验证已安装的证书：

certutil -L -d ServerRoot/alias -P slapd-serverID-

列出的具有信任属性 u,, 的证书是服务器证书，那些具有信任属性 CT,, 的证书是受信任的 CA 证书。

激活 SSL

完成服务器证书和受信任 CA 的证书的安装后，即可激活 SSL。大多数时间，您希望服务器在启用 SSL 的情况下运行。如果临时禁用 SSL，请确保在处理要求保密性、验证或数据完整性的操作之前重新启用 SSL。

必须按照获得并安装服务器证书中描述的那样，创建一个证书数据库，获得并安装服务器证书并信任 CA 的证书，才能激活 SSL。

以下步骤将在 Directory Server 中激活 SSL 通讯并启用加密机制：

在 Directory Server Console 的顶级“配置”选项卡上，选择与服务器名称相同的根节点，然后在右面板中选择“加密”选项卡。

此选项卡显示当前服务器的加密设置。

表明您希望通过选中“为此服务器启用 SSL”复选框而启用加密功能。

选中“使用此密码族”复选框。

从下拉菜单中选择您要使用的证书。

单击“密码设置”，并在“密码首选项”对话框中选择要使用的密码。有关特定密码的详细信息，请参见选择加密密码。

设置客户机验证的首选项：

不允许客户机验证。使用此选项，服务器将忽略客户机的证书并将拒绝基于它的验证。

允许客户机验证。这是默认设置。选择此选项，将根据客户机请求执行验证。有关基于证书验证的详细信息，请参见配置客户机验证。



注	如果正在通过复制方式使用基于证书的验证，则必须将消费者服务器配置为允许或要求客户机验证。

要求客户机验证。选择此选项，如果客户机不响应服务器的验证请求，则客户机连接将被拒绝。



注	如果 Server Console 通过 SSL 连接至 Directory Server，选择“要求客户机验证”将禁用通讯，这是因为 Server Console 没有可以用来进行客户机验证的证书。要通过命令行修改此属性，请参见允许客户机验证。

在与 Directory Server 通讯时，如果希望控制台使用 SSL，则还可以在 Server Console 中选择“使用 SSL”。

完成后单击“保存”。

还可以选择设置使用 LDAP 和 DSML-over-HTTP 这两种协议进行 SSL 通讯时服务器要使用的安全端口。有关信息，请参见更改 Directory Server 端口号。

所有至安全端口的连接都必须使用 SSL。不论是否配置了安全端口，激活 SSL 后，客户机都会通过非安全端口使用 Start TLS 操作来执行 SSL 加密。

重新启动 Directory Server。

有关详细信息，请参见在启用 SSL 的情况下启动服务器。

选择加密密码

密码是用于加密和解密数据的算法。通常，加密期间密码使用的位数越多，则密码越难破解或者说更安全。使用的消息验证类型也可以标识 SSL 密码。消息验证是另一种计算校验和（用来保证数据完整性）的算法。有关密码算法及其强度的更完整的讨论，请参见 Administration Server Administration Guide。

当客户机启动与服务器的 SSL 连接时，客户机和服务器必须使用同一密码以用于加密信息。在任何双向加密过程中，双方都必须使用相同密码（通常为双方都支持的保护能力最强的密码）。

表 11-1 Directory Server 提供的密码
密码名称	说明
None	没有加密，只进行 MD5 消息验证 (rsa_null_md5)。
RC4（128 位）	带 128 位加密的 RC4 密码并进行 MD5 消息验证 (rsa_rc4_128_md5)。
RC4（导出）	带 40 位加密的 RC4 密码并进行 MD5 消息验证 (rsa_rc4_40_md5)。
RC2（导出）	带 40 位加密的 RC2 密码并进行 MD5 消息验证 (rsa_rc2_40_md5)。
DES 或 DES（导出）	带 56 位加密的 DES 并进行 SHA 消息验证 (rsa_des_sha)。
DES (FIPS)	带 56 位加密的 FIPS DES 并进行 SHA 消息验证。此密码满足加密模块实现的 FIPS 140-1 美国政府标准 (rsa_fips_des_sha)。
三元 DES	带 168 位加密的三元 DES 并进行 SHA 消息验证 (rsa_3des_sha)。
三元 DES (FIPS)	带 168 位加密的 FIPS 三元 DES 并进行 SHA 消息验证。此密码满足加密模块实现的 FIPS 140-1 美国政府标准 (rsa_fips_3des_sha)。
Fortezza	带 80 位加密的 Fortezza 密码并进行 SHA 消息验证。
RC4 (Fortezza)	带 128 位加密的 Fortezza RC4 密码并进行 SHA 消息验证。
None (Fortezza)	没有加密，只进行 Fortezza SHA 消息验证。

为了继续使用 Server Console 和 SSL，必须至少选择以下密码中的一种：

具有 40 位加密的 RC4 密码并进行 MD5 消息验证。

没有加密，只进行 MD5 消息验证（不建议）。

带 56 位加密的 DES 并进行 SHA 消息验证。

带 128 位加密的 RC4 密码并进行 MD5 消息验证。

带 168 位加密的三元 DES 并进行 SHA 消息验证。

在 Directory Server Console 的顶级“配置”选项卡上，选择与服务器名称相同的根节点，然后在右面板中选择“加密”选项卡。

此选项卡显示当前服务器的加密设置。如激活 SSL 中所述，确保已为服务器启用 SSL。

单击“密码设置”。

显示“密码首选项”对话框。

在“密码首选项”对话框中，通过选中或取消选中密码名称旁的复选框来指定希望服务器使用的密码。

除非出于某种安全原因而不能使用特定密码，否则应选择 none、MD5 之外的所有密码。



警告	不要选择“没有加密，只进行 MD5 消息验证”密码，因为如果客户机上没有其他密码可用，服务器就会使用此选项。在这种情况下，连接是不安全的，因为没有使用加密。

在“密码首选项”对话框中单击“确定”，然后在“加密”选项卡中单击“保存”。

允许客户机验证

如果已将 Directory Server 配置为要求客户机验证并且使用 SSL 连接至 Server Console，那么就不能再使用 Server Console 管理任何 Sun Java System 服务器。您将只能改为使用相应的命令行实用程序。

然而，如果您希望更改目录配置以便可以使用 Server Console，则必须执行以下步骤以便不再要求而是允许客户机验证：

使用以下命令修改 cn=encryption,cn=config 条目：

ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn:cn=encryption,cn=config
changetype:modify
replace:nsSSLClientAuth
nsSSLClientAuth:allowed
^D

如通过命令行启动和停止服务器中所述，重新启动 Directory Server。

可立即启动 Server Console。

配置客户机验证

客户机验证是一种服务器验证客户机身份的机制。可以使用客户机提供的证书或者通过基于 SASL 的机制（如 DIGEST-MD5）简单执行客户机验证（通过提供 DN 和密码）。在 Solaris 操作系统上，目前 Directory Server 通过 SASL 支持 GSSAPI 机制，该机制允许通过 Kerberos V5 进行客户机验证。

基于证书的验证使用通过 SSL 协议获得的客户机证书，来查找用户条目以进行标识。此机制也称为 EXTERNAL，因为它依赖已在较低层建立的验证机制。（在以后的版本中，可使用 IP 安全协议 (ipsec) 进行外部验证。）

通过 DIGEST-MD5 进行的 SASL 验证


注	标识映射不支持链接的后缀。

DIGEST-MD5 机制通过比较具有无序用户密码的客户机发送的无序值对客户机进行验证。然而，因为此机制必须读取用户密码，所以希望通过 DIGEST-MD5 进行验证的所有用户都必须在目录中有一个 {CLEAR} 密码。将 {CLEAR} 密码存储到目录中时，必须确保通过 ACI 正确限制对密码值的访问，如第 6 章“管理访问控制”中所述。您可能希望如为属性值加密中所述通过在该后缀中配置属性加密来进一步保护 {CLEAR} 密码。

配置 DIGEST-MD5 机制

以下过程说明了配置 Directory Server 以使用 DIGEST-MD5 的必要步骤：

使用控制台或 ldapsearch 命令，验证 DIGEST-MD5 是根条目中 supportedSASLMechanisms 属性的值。例如，以下命令将显示启用的 SASL 机制：

ldapsearch -h host -p port -D "cn=Directory Manager" -w password \
-s base -b "" "(objectclass=*)" supportedSASLMechanisms

dn:
supportedSASLMechanisms:EXTERNAL
supportedSASLMechanisms:DIGEST-MD5
supportedSASLMechanisms:GSSAPI
^D

如果未启用 DIGEST-MD5，请使用下面的 ldapmodify 命令来启用它：

ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn:cn=SASL, cn=security, cn=config
changetype:modify
add:dsSaslPluginsEnable
dsSaslPluginsEnable:DIGEST-MD5
-
replace:dsSaslPluginsPath
dsSaslPluginsPath:ServerRoot/lib/sasl
^D

使用 DIGEST-MD5 的默认标识映射，或者按照DIGEST-MD5 标识映射中的说明创建新的标识映射。

确保将使用 DIGEST-MD5 通过 SSL 访问服务器的所有用户的密码都存储在 {CLEAR} 中。有关如何配置密码存储模式的说明，请参见第 7 章“管理用户帐户和密码”。

如果修改了 SASL 配置条目或者 DIGEST-MD5 标识映射条目之一，请重新启动 Directory Server。

DIGEST-MD5 标识映射

SASL 机制的标识映射尝试将 SASL 标识凭证与目录中的用户条目进行匹配。有关该机制的完整说明，请参见标识映射。如果映射未能找到与 SASL 标识相对应的 DN，则验证失败。

SASL 标识是名为 Principal 的字符串，它以每个机制的特定格式来表示用户。在 DIGEST-MD5 中，建议客户机创建一个包含 dn:前缀和 LDAP DN 或 u:前缀（后面是客户机确定的任意文本）的 Principal。映射期间，客户机发送的 Principal 在 ${Principal} 占位符中可用。

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

此标识映射假设 Principal 的 dn 字段包含目录中现有用户的确切 DN。

在 cn=DIGEST-MD5,cn=identity mapping,cn=config 下编辑默认映射条目或创建新的映射条目。有关标识映射条目中属性的定义，请参见标识映射。DIGEST-MD5 的映射示例位于下面的文件中：

ServerRoot/slapd-serverID/ldif/identityMapping_Examples.ldif

此示例假设 Principal 的不符合要求的文本字段包含具有期望身份的用户名。下面的命令显示了将要如何定义此映射：

ldapmodify -a -h host -p port -D "cn=Directory Manager" -w 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)

重新启动 Directory Server 以使新映射生效。

通过 GSSAPI 进行 SASL 验证（仅限 Solaris）

SASL 上的综合安全服务应用程序接口 (GSSAPI) 允许您使用第三方安全系统（如 Kerberos V5）来验证客户机。GSSAPI 库仅在基于 Solaris SPARC 的平台上可用。Sun 建议您在 Sun Enterprise Authentication Mechanism (SEAM) 1.0.1 服务器中安装 Kerberos V5 实现。

服务器使用此 API 来验证用户的身份。然后，SASL 机制应用 GSSAPI 映射规则，以获得连接期间所有操作的绑定 DN。

配置 Kerberos 系统

按照制造商的说明配置 Kerberos 软件。如果使用的是 SEAM 1.0.1 服务器，则配置过程包括以下步骤：

配置 /etc/krb5 中的文件。

创建 Kerberos 数据库以存储用户和服务，并在其中创建 LDAP 服务的 principal。LDAP 服务的 principal 为：

ldap/serverFQDN@REALM

其中 serverFQDN 是 Directory Server 的全限定域名。

启动 Kerberos 守护进程。

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

配置 GSSAPI 机制

以下过程说明了配置 Directory Server 以在 Solaris 平台上使用 GSSAPI 的必要步骤：

按照 GSSAPI 标识映射中的说明创建 GSSAPI 的默认标识映射和任何自定义映射。

创建 keytab 以存储服务密钥，其中包括用于 LDAP 服务的一个密钥。

确保只有 Directory Server 用户能够读取 keytab。

指定与默认 /etc/krb5/krb5.keytab 不同的文件名。

在 start-slapd 脚本中设置环境变量 KRB5_KTNAME，以确保使用新的 keytab，而非默认 keytab。

如果修改了 SASL 配置条目或者 GSSAPI 标识映射条目之一，请重新启动 Directory Server。

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

GSSAPI 标识映射

SASL 机制的标识映射尝试将 SASL 标识凭证与目录中的用户条目进行匹配。有关此机制的完整说明，请参见标识映射。如果映射未能找到与 SASL 标识相对应的 DN，则验证失败。

SASL 标识是名为 Principal 的字符串，它以每个机制的特定格式来表示用户。在 Kerberos 中使用 GSSAPI 时，Principal 是具有 uid[/instance][@realm] 格式的标识，其中 uid 可能包含一个可选的 instance 标识符（其后跟着的通常为域名的可选 realm）。例如，以下全部为有效的用户 Principal：

最初，未在目录中定义 GSSAPI 映射。根据客户机定义其使用的 Principal 的方式，您应该定义默认映射和需要的任何自定义映射。

在 cn=GSSAPI,cn=identity mapping, cn=config 下创建新的映射条目。有关标识映射条目中属性的定义，请参见标识映射。

GSSAPI 映射示例位于下面的文件中：

ServerRoot/slapd-serverID/ldif/identityMapping_Examples.ldif

此文件中建议的默认 GSSAPI 映射假设 Principal 仅包含一个用户 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

此文件中的另一个示例显示了在包括已知 Realm 的 Principal 中包含一个用户 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

重新启动 Directory Server 以使新映射生效。

标识映射

Directory Server 中的若干验证机制需要一个从其他协议的凭证至目录中 DN 的映射。目前，DSML-over-HTTP 协议和 DIGEST-MD5 以及 GSSAPI SASL 机制之间就是这种情况。每个验证机制都将使用标识映射来确定由客户机提供的基于协议特定凭证的绑定 DN。

标识映射使用 cn=identity mapping, cn=config 配置分支中的条目。此分支为每个必须执行标识映射的协议包括一个容器：

cn=HTTP-BASIC, cn=identity mapping, cn=config——包含 DSML-over-HTTP 连接的映射。

cn=DIGEST-MD5, cn=identity mapping, cn=config——包含使用 DIGEST-MD5 SASL 机制进行客户机验证的映射。

cn=GSSAPI, cn=identity mapping, cn=config——必须创建该容器，以包含使用 GSSAPI SASL 机制进行客户机验证的映射。

映射条目定义了提取协议特定凭证的元素以在搜索目录时使用这些元素的方式。如果该搜索仅返回一个用户条目，则映射已经成功，且连接将使用此条目作为所有操作的绑定 DN。如果搜索没有返回条目或返回多个条目，则映射失败，将应用其他映射。

每个分支应该包含该协议的一个默认映射以及任意数量的自定义映射。默认映射具有 RDN cn=default，自定义映射可能具有使用 cn 作为命名属性的任何其他 RDN。将首先以不确定的顺序评估所有自定义映射，直至其中一个映射成功。如果所有自定义映射均失败了，则最后将应用默认映射。如果默认映射也失败了，那么客户机验证失败。

映射条目必须包含 top、Container 和 dsIdentityMapping 对象类。然后，条目还可能包含以下属性：

dsMappedDN:DN——在目录中定义 DN 的文字串。如果执行映射时此 DN 存在，则它将用于绑定。您还可以定义以下属性，以便在此 DN 不存在的情况下执行搜索。

dsSearchBaseDN:DN——用于搜索的基 DN。如果忽略此属性，映射将在整个目录树中搜索所有根后缀（包括所有命名上下文，但 cn=config、cn=monitor 和 cn=schema 除外）。

dsSearchScope:base|one|sub——搜索的范围，它可能是搜索基准本身、基准下的一个子级别，或基准下的整个子树。忽略此属性时，映射搜索的默认范围为整个子树。

dsSearchFilter:filterString——执行映射搜索的过滤器字符串。LDAP 搜索过滤器是在 RFC 2254 (http://www.ietf.org/rfc/rfc2254.txt) 中定义的。

另外，映射条目还可能包含允许其使用下列属性的 dsPatternMatching 对象类：

dsMatching-pattern:patternString——指定要在其上执行模式匹配的字符串。

dsMatching-regexp:regularExpression——指定应用于模式字符串的正则表达式。

上面所有的属性值（dsSearchScope 除外）可能包含格式为 ${keyword} 的占位符，其中 keyword 是协议特定凭证中元素的名称。映射期间，占位符将被替换为客户机提供的元素的实际值。

所有占位符均被替换后，将执行定义的所有模式匹配。将会对模式匹配与正则表达式进行比较。如果正则表达式与模式字符串不匹配，则此映射失败。如果匹配，则括号中正则表达式条件的匹配值将作为可用的已编号占位符，以在其他属性值中使用。例如，可以为 SASL 定义以下映射：

dsMatching-pattern:${Principal}
dsMatching-regexp: (.*)@(.*)\.(.*)
dsMappedDN:uid=$1,ou=people,dc=$2,dc=$3

如果使用 bjensen@example.com 的 Principal 进行客户机验证，则此映射将定义绑定 DN uid=bjensen,ou=people,dc=example,dc=com。如果目录中存在此 DN，则映射将成功，并对客户机进行验证，此连接期间执行的所有操作都将使用此绑定 DN。

将使用 Posix regexec(3C) 和 regcomp(3C) 函数调用对 dsMatching-pattern 和 dsMatching-regexp 进行比较。Directory Server 使用扩展的正则表达式，所有的比较项都不区分大小写。有关详细信息，请参见 Directory Server Man Page Reference 中这些函数的 man 页面。

可能包含占位符的属性值必须对不属于占位符组成部分的任意 $、{ 和 } 字符进行编码（即使没有使用占位符）。必须使用以下值对这些字符进行编码：$ 替换为 \24、{ 替换为 \7B，} 替换为 \7D。

使用占位符和替换值将允许您创建映射（映射将从协议特定凭证中提取用户名或其他任意值），并使用映射值来定义已映射的 DN，或者在目录的任意位置搜索相应的 DN。应该定义提取由目录客户机提供的预期凭证的映射，并将其映射到特定的目录结构。


警告	创建定义不完善的映射将会成为安全漏洞。例如，无模式匹配的到硬编码 DN 的映射总是能成功，因此将验证可能不是目录用户的客户机。定义若干映射来处理不同的客户机凭证格式，而不是创建一个单一的、过于普通和随意的映射，这样会更安全。应该根据客户机凭证始终尝试将客户机连接映射至特定用户。

配置 LDAP 客户机以使用安全性

以下几节介绍如何在希望与 Directory Server 建立安全连接的 LDAP 客户机中配置和使用 SSL。在 SSL 连接中，服务器会将其证书发送给客户机。客户机首先必须信任其证书以验证服务器。然后，客户机可以通过发送自己的证书或两个 SASL 机制之一（DIGEST-MD5 或使用 Kerberos V5 的 GSSAPI）的信息来启动某一客户机验证机制。

以下几节使用 ldapsearch 工具作为启用 SSL 的 LDAP 客户机的示例。Directory Server 中提供的 ldapmodify、ldapdelete 和 ldapcompare 工具的配置方式相同。这些目录访问工具均基于 Directory SDK for C，Directory Server Resource Kit Tools Reference 中对其进行了进一步说明。

要在其他 LDAP 客户机上配置 SSL 连接，请参见应用程序附带的文档。

在客户机中配置服务器验证

当客户机建立与服务器的 SSL 连接时，它必须信任服务器提交的证书。为完成此操作，客户机必须：


注	某些客户机应用程序实施 SSL，但并不验证服务器是否具有受信任的证书。它们使用 SSL 协议以提供数据加密，但既不能保证保密性，也不能防止客户机的假冒。

具有一个证书数据库。

信任颁发服务器证书的证书颁发机构 (CA)。

指定 LDAP 客户机的 SSL 选项。

Mozilla 是使用 SSL 通过 HTTP 协议与 Web 服务器进行通讯的客户机应用程序。可以使用 Mozilla 管理 LDAP 客户机也将使用的证书。或者，可以使用 certutil 工具管理证书数据库。

通过 Mozilla 管理客户机证书

启动时，Mozilla 将确保证书数据库存在，否则它将在需要时创建一个证书数据库。证书数据库将与其他 Mozilla 首选项一起存储在一个文件中（例如，.mozilla/username/string.slt/cert8.db）

如果使用此过程，请找到由 Mozilla 创建的证书数据库，并记住客户机应用程序使用的路径。

使用 Mozilla 浏览证书颁发机构（为要访问的 Directory Server 颁发证书）的 Web 站点。Mozilla 将自动检索证书颁发机构的证书，并询问您是否信任此证书。

例如，如果正在使用内部部署的 Sun Java System 证书服务器，请转到具有 https://hostname:444 形式的 URL。

Mozilla 提示您信任证书颁发机构的证书时，请遵照执行。应该信任 CA 证书以进行服务器验证。

根据 CA 的 Web 站点规定，此步骤可能无法执行。如果 Mozilla 未自动提示您信任 CA 证书，请使用以下步骤手动执行。

通过命令行管理客户机证书

使用 certutil 工具通过命令行管理证书。SUNWtlsu 软件包中提供有此工具。

在客户机主机上，请使用以下命令创建证书数据库：

certutil -N -d path -P prefix

该工具将提示用户输入密码以保护证书。然后，该工具将创建以下文件：path/prefixcert8.db and path/prefixkey3.db.

应该由 LDAP 客户机应用程序的用户在只能由其访问的位置单独创建证书数据库（例如，其主目录受保护的子目录）。

请与证书颁发机构（为要访问的 Directory Server 颁发证书）联系，并请求 CA 证书。可以通过发送电子邮件或访问他们的 Web 站点，以获得 PKCS #11 证书的 PEM 编码的文本版本。将此证书保存到文件中。

例如，如果正在使用内部部署的 Sun Java System 证书服务器，请转到具有 https://hostname:444 形式的 URL。在顶级“检索”选项卡中，选择“导入 CA 证书链接”并复制那里的已编码证书。

或者，如果从同一 CA 中获得客户机证书和服务器证书，则可以重复使用通过信任证书颁发机构中的过程获得的 CA 证书。

将 CA 证书作为受信任的 CA（用于颁发在 SSL 连接中使用的服务器证书）导入。使用以下命令：

certutil -A -n "certificateName" -t "C,," -a -i certFile -d path -P prefix

其中，certificateName 是给定的用来标识此证书的名称，certFile 是包含 PEM 编码文本格式的 PKCS #11 颁发机构证书的文本文件，path 和 prefix 与步骤 1 中的相同。

LDAP 客户机应用程序的每个用户都必须将 CA 证书导入至其证书数据库中。所有用户可以导入位于 certFile 中的相同证书。

指定 SSL 选项以进行服务器验证

要使用 ldapsearch 工具在 SSL 中执行服务器验证，用户仅需指定其证书数据库的路径即可。通过安全端口建立 SSL 连接时，服务器将发送其证书。然后，ldapsearch 工具将在用户的证书数据库中查找颁发服务器证书的 CA 受信任的 CA 证书。

以下命令显示了用户如何指定其证书数据库（如果此数据库是由 Mozilla 创建的）：

ldapsearch -h host -p securePort \
           -D "uid=bjensen,dc=example,dc=com" -w bindPassword \
           -Z -P .mozilla/bjensen/string.slt/cert8.db \
           -b "dc=example,dc=com" "(givenname=Richard)"

在客户机中配置基于证书的验证

客户机验证的默认机制将使用证书来安全地识别 Directory Server 的用户。要执行基于证书的客户机验证，您必须：

为每个目录用户获取一个证书，并将其安装在客户机应用程序可以访问到的地方。

使用同一证书的二进制副本配置用户的目录条目。验证期间，服务器将客户机应用程序提交的证书与此副本相匹配，以明确地标识该用户。

按照 Administration Server Administration Guide 中的说明，配置服务器以基于证书进行验证。

为基于证书的验证指定 LDAP 客户机的 SSL 选项。

这些步骤需要 certutil 工具通过命令行管理证书。SUNWtlsu 软件包中提供有此工具。

获得并安装用户证书

必须由希望利用基于证书的验证来访问目录的每位用户请求并安装客户机证书。此过程假设用户已经按照在客户机中配置服务器验证中的说明配置了证书数据库。

请使用以下命令创建用户证书请求：

certutil -R \
-s "cn=Babs Jensen,ou=Sales,o=example.com,l=city,st=state,c=country"\
-a -d path -P prefix

-s 选项指定所请求证书的 DN。通常，证书颁发机构会要求此示例中显示的所有属性，以完整地标识证书的拥有者。通过步骤 9 中的证书映射机制，证书 DN 将被映射至用户的目录 DN。

path and prefix 将查找用户的证书和密钥数据库。certutil 工具将提示用户输入其密钥数据库的密码。然后，此工具将生成 PEM 编码文本格式的 PKCS #10 证书请求。

然后按照规定步骤将编码的证书请求保存到一个文件中，并将其传输至您的证书颁发机构。例如，可能会要求您以电子邮件的形式发送证书请求，或者也可以通过 CA 的 Web 站点输入请求。

CA 发送响应后，请将新证书的 PEM 编码文本下载或复制到一个文本文件。

请使用以下命令在证书数据库中安装新的用户证书：

certutil -A -n "certificateName" -t "u,," -a -i certFile -d path -P prefix

其中，certificateName 是用来标识证书的名称，certFile 是包含 PEM 格式的 PKCS #11 证书的文本文件，path 和 prefix 与步骤 1 中的相同。

或者，如果通过 Mozilla 管理证书数据库，则在 CA 的 Web 站点中可能有一个可以直接安装证书的链接。单击此链接，并按照 Mozilla 显示的对话框逐步执行操作。

请使用以下命令创建证书的二进制副本：

certutil -L -n "certificateName" -d path -r > userCert.bin

其中 certificateName 是安装证书时给定的证书名称，path 是证书数据库的位置，userCert.bin 是将包含二进制格式证书的输出文件的名称。

在 Directory Server 上，将 userCertificate 属性添加至拥有客户机证书的用户的目录条目中。

要通过控制台添加证书，请执行以下操作：

在 Directory Server Console 的顶级“目录”选项卡中，在目录树中找到用户条目，右键单击此条目并在弹出菜单中选择“用通用编辑器进行编辑”。

在“通用编辑器”中，单击“添加属性”。

从弹出的对话框中选择 userCertificate 属性，并从“子类型”下拉列表中选择 binary。必须指定 binary 子类型，否则证书映射将失败。

在“通用编辑器”中找到新的 userCertificate 字段。单击对应的“设置值”按钮为此属性设置二进制值。

在“设置值”对话框中，输入在步骤 6 中创建的 userCert.bin 文件的名称，或者单击“浏览”查找该文件。

在“设置值”对话框中单击“确定”，然后在“通用编辑器”中单击“保存”。

要通过命令行添加证书，请使用下面示例中显示的 ldapmodify 命令。此命令使用 SSL 通过安全连接发送证书：

ldapmodify -h host -p securePort \
-D "uid=bjensen,dc=example,dc=com" -w bindPassword \
-Z -P .mozilla/bjensen/string.slt/cert8.db
version: 1
dn:uid=bjensen,dc=example,dc=com
changetype:modify
add:userCertificate
userCertificate;binary:< file:///path/userCert.bin

必须包括 binary 子类型，否则证书映射将失败。< 前后的空格非常重要，必须完全按照显示的形式保留空格。要使用 < 语法来指定文件名，必须以行 version:1 作为 LDIF 语句的开头。ldapmodify 处理此语句时，它将该属性设置为可以从给定文件的全部内容中读取的值。

在 Directory Server 上，必要时安装并信任颁发用户证书的 CA 的证书。必须信任此 CA 以接受来自客户机的连接。请参见信任证书颁发机构。

按照 Administration Server Administration Guide 中的说明，将 Directory Server 配置为基于证书进行验证。在此过程中，可以编辑 certmap.conf 文件，这样服务器会将通过 LDAP 客户机提交的用户证书映射至对应的用户 DN。

确保在 certmap.conf 文件中，verifyCert 参数已设置为 on。然后，服务器将验证包含相同证书的用户条目，从而明确地标识用户。

为基于证书的客户机验证指定 SSL 选项

要使用 ldapsearch 工具在 SSL 中执行基于证书的客户机验证，用户需要指定若干命令行选项以使用其证书。通过安全端口建立 SSL 连接时，此工具将验证服务器的证书，然后将用户证书发送至服务器。

以下命令显示了用户如何指定用来访问其证书数据库（如果此数据库是由 Mozilla 创建的）的选项：

ldapsearch -h host -p securePort \
           -Z -P .mozilla/bjensen/string.slt/cert8.db \
           -N "certificateName" \
           -K .mozilla/bjensen/string.slt/key3.db -W keyPassword \
           -b "dc=example,dc=com" "(givenname=Richard)"

-Z 选项表示基于证书的验证，certificateName 指定要发送的证书，-K 和 -W 选项允许客户机应用程序访问证书，从而可以发送证书。如果未指定 -D 和 -w 选项，将从证书映射来确定绑定 DN。

在客户机中使用 SASL DIGEST-MD5

在客户机中使用 DIGEST-MD5 机制时，不需要安装用户证书。不过，如果希望使用加密的 SSL 连接，则仍然必须信任服务器证书，如在客户机中配置服务器验证中所述。

指定领域

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

Directory Server 使用全限定主机名作为 DIGEST-MD5 的默认领域。服务器将使用在 nsslapd-localhost 配置属性中找到的主机名的小写字母值。

指定环境变量

在 UNIX 环境中，必须设置 SASL_PATH 环境变量，这样 LDAP 工具将会找到 DIGEST-MD5 库。DIGEST-MD5 库是 SASL 插件动态加载的共享库，因此应按如下所示设置 SASL_PATH 变量（以在 Korn shell 中为例）：

此路径假设 Directory Server 安装在将调用 LDAP 工具的同一主机上。

ldapsearch 命令的示例

无需使用 SSL，即可执行 DIGEST-MD5 客户机验证。下面的示例将使用默认的 DIGEST-MD5 标识映射来确定绑定 DN：

ldapsearch -h host -p nonSecurePort -D "" -w bindPassword \
           -o mech=DIGEST-MD5 [-o realm="hostFQDN"] \
           -o authid="dn:uid=bjensen,dc=example,dc=com" \
           -o authzid="dn:uid=bjensen,dc=example,dc=com" \
           -b "dc=example,dc=com" "(givenname=Richard)"

上面的示例说明了如何使用 -o（o 为小写字母）选项来指定 SASL 选项。Realm 是可选的，但是如果指定了 Realm，则该 Realm 必须为服务器主机的全限定域名。虽然未使用面向代理操作的 authzid，但是 authid 和 authzid 必须同时出现且相同。

authid 的值是标识映射中使用的 Principal。建议 authid 应包含 dn:前缀（后面跟目录中的有效用户 DN）或 u:前缀（后面跟客户机确定的任意字符串）。这样，您就可以使用 DIGEST-MD5 标识映射中所示的映射。

通常，您可能希望有一个 SSL 连接以提供通过安全端口的加密，还希望有 DIGEST-MD5 以便提供客户机验证。下面的示例将通过 SSL 执行相同操作：

ldapsearch -h host -p securePort \
           -Z -P .mozilla/bjensen/string.slt/cert8.db \
           -N "certificateName" -W keyPassword \
           -o mech=DIGEST-MD5 [-o realm="hostFQDN"] \
           -o authid="dn:uid=bjensen,dc=example,dc=com" \
           -o authzid="dn:uid=bjensen,dc=example,dc=com" \
           -b "dc=example,dc=com" "(givenname=Richard)"

在此示例中，-N 和 -W 选项是 ldapsearch 命令必需的，但它们并不用于客户机验证。相反，服务器将再次执行具有 authid 值的 Principal 的 DIGEST-MD5 标识映射。

在客户机中使用 Kerberos SASL GSSAPI

在客户机中使用 GSSAPI 机制时，不需要安装用户证书，但必须配置 Kerberos V5 安全系统。而且，如果希望使用加密的 SSL 连接，则必须信任服务器证书，如在客户机中配置服务器验证中所述。

在客户机主机上配置 Kerberos V5

请按照其安装说明来安装 Kerberos V5。Sun 建议安装 Sun Enterprise Authentication Mechanism (SEAM) 1.0.1 客户机软件。

配置 Kerberos 软件。使用 SEAM，配置 /etc/krb5 下的文件，以便设置 kdc 服务器、定义默认领域以及 Kerberos 系统要求的其他所有配置。

必要时，修改文件 /etc/gss/mech，这样列出的第一个值为 kerberos_v5。

指定 SASL 选项以进行 Kerberos 验证

使用启用了 GSSAPI 的客户机应用程序前，必须使用下面的命令初始化具有用户 Principal 的 Kerberos 安全系统：

kinit userPrincipal

userPrincipal 是 SASL 标识，例如 bjensen@EXAMPLE.COM。

指定 SASL 选项以使用 Kerberos。

请注意，在 UNIX 环境中，必须将 SASL_PATH 环境变量设置为 ServerRoot/lib/sasl 以找到正确的库。例如，在 Korn shell 中：

export SASL_PATH=ServerRoot/lib/sasl

此路径假设 Directory Server 安装在将调用 LDAP 工具的同一主机上。

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

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

可以忽略 authid，因为它们存在于由 kinit 命令初始化的 Kerberos 缓存中。如果 authid 存在，虽然未使用用于代理操作的 authzid，但 authid 和 authzid 必须相同。authid 的值是标识映射中使用的 Principal。 Principal 必须是完全 Principal（包括领域）。有关详细信息，请参见 GSSAPI 标识映射。

配置使用 GSSAPI 和 SASL 的 Kerberos 验证：示例过程

为 Directory Server 配置 Kerberos 可能非常复杂。首先应参考的资料是 Kerberos 文档。

要获得更多的帮助，请使用下面的示例过程以了解要执行的步骤。但要注意，此过程是一个示例，您必须根据自己的配置和环境对其进行修改。

可以在 Security Services System Administration Guide 中找到有关在 Solaris 中配置和使用 Kerberos 的其他信息，该指南是 Solaris 文档集的一部分。也可以参见手册页。

假设

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

所有计算机——编辑 Administration Server ACL 配置文件

KDC 计算机——编辑 KDC 服务器配置文件

KDC 计算机——创建 KDC 数据库

KDC 计算机——创建 Admin Principal 和 keytab

KDC 计算机——启动 Kerberos 守护进程

KDC 计算机——为 KDC 和 Directory Server 计算机添加主机 Principal

KDC 计算机——为 Directory Server 添加 LDAP Principal

KDC 计算机——将测试用户添加到 KDC

Directory Server 计算机——安装 Directory Server

Directory Server 计算机——配置 Directory Server 以启用 GSSAPI

Directory Server 计算机 -- 创建 Directory Server keytab

Directory Server 计算机——将测试用户添加到 Directory Server

Directory Server 计算机——作为测试用户获取 Kerberos 票证

客户机——通过 GSSAPI 对 Directory Server 进行验证

假设

此示例过程介绍以下过程：将一台计算机配置为用作 KDC，并将第二台计算机配置为运行 Directory Server，以使用户能够通过 GSSAPI 来执行 Kerberos 验证。

也可以在同一台计算机上运行 KDC 和 Directory Server。如果选择执行此操作，请使用相同的过程，但忽略为 Directory Server 计算机列出的步骤中已对 KDC 计算机完成的步骤。

此过程对将要使用的环境做了一些假设。下面列出了这些过程。在使用示例过程时，请根据您的环境相应地修改这些值。

此系统将安装全新的 Solaris 9 操作环境，并安装了建议的最新修补程序群集。安装建议的最新修补程序群集是至关重要的，因为在某些情况下，Directory Server 的 Kerberos 验证会由于未安装适当的 Solaris 修补程序而失败。还要注意，虽然介绍的过程与 Solaris 10 的过程大体相同，但配置文件格式略有不同，某些命令的输出也可能会不同。

运行 Kerberos 守护进程的计算机将具有全限定域名 kdc.example.com。必须将该计算机配置为使用 DNS 作为命名服务（这是 Kerberos 的要求，如果使用 file 等其他命名服务，某些操作可能会失败）。

运行 Directory Server 的计算机将具有全限定域名 directory.example.com。还必须将此计算机配置为使用 DNS 作为命名服务。

Directory Server 计算机将用作通过 Kerberos 进行 Directory Server 验证的客户机系统。虽然可以在能与 Directory Server 和 Kerberos 守护进程通讯的任何系统中执行这种验证，但 Directory Server 提供了此示例所需的所有组件，并且将在该系统上执行验证。

Directory Server 中的用户具有以下形式的 DN：uid=username,ou=People, dc=example,dc=com，相应 Kerberos Principal 为 username@EXAMPLE.COM。如果使用不同的命名模式，则应该使用其他 GSSAPI 标识映射。

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

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

在 KDC 计算机、Directory Server 计算机以及任何使用 Kerberos 对 Directory Server 进行验证的客户机中，编辑 /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 配置文件应该类似于代码示例 11-1 的内容：

代码示例 11-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
}

所有计算机——编辑 Administration Server ACL 配置文件

在 /etc/krb5/kadm5.acl 配置文件中，将 "___default_realm___" 替换为 "EXAMPLE.COM"。更新后的 /etc/krb5/kadm5.acl 文件应该类似于代码示例 11-3：

KDC 计算机——编辑 KDC 服务器配置文件

编辑 /etc/krb5/kdc.conf 文件，将 "___default_realm___" 替换为 "EXAMPLE.COM"。

[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 数据库

bash-2.05# /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:master-password
Re-enter KDC database master key to verify:master-password
bash-2.05#

KDC 计算机——创建 Admin Principal 和 keytab

使用以下命令来创建管理用户，该用户的 Principal 是 kws/admin@EXAMPLE.COM 且具有管理员守护进程所使用的服务密钥。

bash-2.05# /usr/sbin/kadmin.local
kadmin.local:add_principal kws/admin
Enter password for principal "kws/admin@EXAMPLE.COM":kws-password
Re-enter password for principal "kws/admin@EXAMPLE.COM":kws-password
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
bash-2.05#

KDC 计算机——启动 Kerberos 守护进程

运行以下命令以启动 KDC 和管理员守护进程。KDC 进程在进程列表中显示为 /usr/lib/krb5/krb5kdc，而管理员守护进程显示为 /usr/lib/krb5/kadmind。

bash-2.05# /etc/init.d/kdc start
bash-2.05# /etc/init.d/kdc.master start
bash-2.05#

请注意，在 Solaris 10 上，守护进程是由 SMF 框架管理的。按如下方式在 Solaris 10 上启动守护进程。

bash-2.05# svcadm disable network/security/krb5kdc
bash-2.05# svcadm enable network/security/krb5kdc
bash-2.05# svcadm disable network/security/kadmin
bash-2.05# svcadm enable network/security/kadmin
bash-2.05#

KDC 计算机——为 KDC 和 Directory Server 计算机添加主机 Principal

使用以下命令序列，将主机 Principal 添加到 KDC 和 Directory Server 计算机的 Kerberos 数据库中。某些 Kerberos 实用程序（如 klist）将使用主机 Principal。

bash-2.05# /usr/sbin/kadmin -p kws/admin
Enter Password: kws-password
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
bash-2.05#

KDC 计算机——为 Directory Server 添加 LDAP Principal

为使 Directory Server 能够验证进行验证的用户所持有的 Kerberos 票证，Directory Server 必须拥有其自身的 Principal。目前，将 Directory Server 硬编码为需要 Principal ldap/fqdn@realm，其中 fqdn 是 Directory Server 完全限定域名（必须与安装 Directory Server 时提供的完全限定域名匹配），而 realm 是 Kerberos 领域。此处，Directory Server 的 Principal 为 ldap/directory.example.com@EXAMPLE.COM。

bash-2.05# /usr/sbin/kadmin -p kws/admin
Enter Password:kws-password
kadmin:add_principal -randkey ldap/directory.example.com
Principal "ldap/directory.example.com@EXAMPLE.COM" created.
kadmin:quit
bash-2.05#

KDC 计算机——将测试用户添加到 KDC

为了能够执行 Kerberos 验证，进行验证的用户在 Kerberos 数据库中必须存在。在此示例中，用户的用户名为 kerberos-test，这意味着 Kerberos Principal 为 kerberos-test@EXAMPLE.COM。

bash-2.05# /usr/sbin/kadmin -p kws/admin
Enter Password:kws-password
kadmin:add_principal kerberos-test
Enter password for principal "kerberos-test@EXAMPLE.COM":test-password
Re-enter password for principal "kerberos-test@EXAMPLE.COM":test-password
Principal "kerberos-test@EXAMPLE.COM" created.
kadmin:quit
bash-2.05#

Directory Server 计算机——安装 Directory Server


全限定计算机名	directory.example.com
安装根目录	/data/ds52p2
服务器用户	unixuser
服务器组	unixgroup
服务器标识符	directory
服务器端口	389
后缀	dc=example,dc=com
管理员 ID	admin
管理员密码	dsadmin-password
管理域	example.com
目录管理员 DN	cn=Directory Manager
目录管理员密码	dm-password
管理端口	390

Directory Server 计算机——配置 Directory Server 以启用 GSSAPI

首先，创建 /data/ds52p2/shared/bin/gssapi.ldif 文件，以定义 Directory Server 标识基于 Principal 进行验证的 Kerberos 用户应使用的映射。创建的文件内容与代码示例 11-11 所示的内容相同：

n: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:/data/ds52p2/lib/sasl

然后，使用 ldapmodify 命令更新 Directory Server 以启用具有适当映射的 GSSAPI，如代码示例 11-12 所示。

bash-2.05# ./ldapmodify -D ’cn=Directory Manager’ -w dm-password -a -f
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
bash-2.05#

Directory Server 计算机 -- 创建 Directory Server keytab

正如前面所述，要通过 GSSAPI 验证 Kerberos 用户，Directory Server 在 KDC 中必须拥有其自身的 Principal。为使此操作正常工作，此 Principal 信息必须保存在 Directory Server 计算机上某个文件的 Kerberos keytab 中，用来运行 Directory Server 的用户帐户可以读取该文件。

bash-2.05# /usr/sbin/kadmin -p kws/admin
Enter Password:kws-password
kadmin:ktadd -k /data/ds52p2/slapd-directory/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:/data/ds52p2/slapd-directory/config/ldap.keytab.
kadmin:quit
bash-2.05#

更改此自定义 keytab 的权限和所有权，使其由用来运行 Directory Server 的用户帐户拥有，并且只能由该用户来读取：

bash-2.05# chown unixuser:unixgroup /data/ds52p2/slapd-directory/config/ldap.keytab
bash-2.05# chmod 600 /data/ds52p2/slapd-directory/config/ldap.keytab
bash-2.05#

默认情况下，Directory Server 将尝试使用文件 /etc/kerb5/krb5.keytab 中的标准 Kerberos keytab。然而，使 Directory Server 用户能够读取该文件可能会产生安全风险，这就是为 Directory Server 创建自定义 keytab的原因。

配置 Directory Server 以使用新的自定义 keytab。要执行此操作，请编辑 start-slapd 脚本以使用 KRB5_KTNAME 环境变量（如代码示例 11-15 所示）。

代码示例 11-15 为使用自定义 Kerberos keytab 而更新的 start-slapd 脚本

#!/bin/sh

# Configure the server to use a custom Kerberos keytab.
KRB5_KTNAME=/data/ds52p2/slapd-directory/config/ldap.keytab
export KRB5_KTNAME

unset LD_LIBRARY_PATH

# Script that starts the ns-slapd server.
# Exit status can be:
# 0: Server started successfully
# 1: Server could not be started
# 2: Server was already started

NETSITE_ROOT=/data/ds52p2
export NETSITE_ROOT

{The remainder of this file has been omitted to conserve space}

bash-2.05# cd /data/ds52p2/slapd-directory
bash-2.05# ./stop-slapd
bash-2.05# ./start-slapd
bash-2.05#

Directory Server 计算机——将测试用户添加到 Directory Server

为了对 Directory Server 的 Kerberos 用户进行验证，该用户必须拥有一个与该用户 Kerberos Principal 相对应的目录条目。

在上一步中，将一个测试用户添加到 Kerberos 数据库中，该用户的 Principal 为 kerberos-test@EXAMPLE.COM。由于将标识映射配置添加到目录中，该用户的相应目录条目必须具有 DN uid=kerberos-test,ou=People,dc=example,dc=com。

将该用户添加到目录中，方法是先创建包含以下内容的文件 /data/ds52p2/shared/bin/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

bash-2.05# ./ldapmodify -D ’cn=Directory Manager’ -w dm-password -f
testuser.ldif
adding new entry uid=kerberos-test,ou=People,dc=example,dc=com
bash-2.05#

Directory Server 计算机——作为测试用户获取 Kerberos 票证

既然测试用户同时存在于 Kerberos 数据库和 Directory Server 及 KDC 中，那么可以作为该用户的身份使用 GSSAPI 通过 Kerberos 对 Directory Server 进行验证。

首先，使用 kinit 命令为用户获取 Kerberos 票证，如代码示例 11-19 中所示。

bash-2.05# kinit kerberos-test
Password for kerberos-test@EXAMPLE.COM:test-password
bash-2.05#

bash-2.05# 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
bash-2.05#

客户机——通过 GSSAPI 对 Directory Server 进行验证

最后一步是使用 GSSAPI 对 Directory Server 进行验证。Directory Server 提供的 ldapsearch 实用程序可以为 SASL 验证提供支持，包括 GSSAPI、DIGEST-MD5 和 EXTERNAL 机制。然而，要执行此操作，必须为客户机提供它应使用的 SASL 库的路径。可使用以下方法来完成此操作：将 SASL_PATH 环境变量设置为 Directory Server 安装根目录下面的 lib/sasl 目录：

bash-2.05# SASL_PATH=/data/ds52p2/lib/sasl
bash-2.05# export SASL_PATH
bash-2.05#

要在 Directory Server 中使用 ldapsearch 实际执行基于 Kerberos 的验证，必须包含 -o mech=GSSAPI 和 -o authzid=principal 参数。在作为先前创建的 Kerberos 测试用户帐户进行验证后，以下示例检索 dc=example,dc=com 条目：

代码示例 11-22 在通过 GSSAPI 进行验证后检索 dc=example,dc=com 条目

bash-2.05# ./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
bash-2.05#

检查 Directory Server 访问日志以确认是否按预期的方式进行验证：

bash-2.05# tail -12 /data/ds52p2/slapd-directory/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.
bash-2.05#

我们可以从中看出，绑定过程分为三步，前两步返回 LDAP 结果 14 (绑定 SASL)，第三步显示绑定成功。method=sasl 和 mech=GSSAPI 标记显示绑定使用 GSSAPI SASL 机制，成功绑定响应结尾的 dn="uid=kerberos-test,ou=people,dc=example,dc=com" 显示绑定是以适当的用户身份执行的。

上一页目录索引下一页
Sun Java(TM) System Directory Server 5.2 2005Q1 管理指南