分类： 系统运维
2005-12-15 17:06:24
Directory Server 支持多种提供安全可信的网络通讯的机制。LDAPS 是运行在安全套接字层 (SSL) 基础上的标准 LDAP 协议，用于加密数据并可随意使用证书进行验证。
Directory Server 还支持启动传输层安全性 (Start TLS) 扩展操作，以便在原来未加密的 LDAP 连接上启用 TLS。
此外，Directory Server 还支持简单身份验证和安全层 (SASL) 上的综合安全服务应用程序接口 (GSSAPI)。这样，您就可以在 Solaris 操作系统上使用 Kerberos Version 5 安全协议。然后，标识映射机制会将 Kerberos Principal 与目录中的标识相关联。
有关其他安全性信息，请访问 NSS Web 站点，地址为：
http://www.mozilla.org/projects/security/pki/nss/
本章包含以下小节：
安全套接字层 (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、Internet 安全性和证书的完整说明，包括如何在 Administration Server 中配置 SSL，请参见 。
本章的后续小节均包括以下步骤：
在完成这些步骤后，对客户机进行配置，以便在与 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 包含大写字母，则必须使用下面的命令行步骤创建证书数据库。
使用控制台时，在第一次调用证书管理器对话框时，服务器将自动创建证书数据库文件：
通过命令行创建证书数据库文件时，必须使用下面步骤中显示的路径和文件名前缀，这样服务器就可以找到它们。
certutil -N -d ServerRoot/alias -P slapd-LCserverID-
其中 LCserverID 为全部使用小写字母的服务器名称。
此工具将提示您输入密码来保护证书的密钥。
使用下列步骤之一可以生成 PEM 格式的 PKCS #10 证书请求。PEM 是 RFC 1421 至 1424 () 指定的“保密增强邮件”格式，用于表示以 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-----
显示“管理证书”对话框。
出现“证书请求向导”。
服务器名称。 输入 Directory Server 的完全限定主机名，该主机名是在 DNS 查找中使用的名称（例如，east.example.com）。
组织。输入您公司或机构的法定名称。大多数 CA 要求您出示法律凭证，如企业许可证的副本，以验证此信息。
组织单位。（可选）。输入您公司内部部门或业务单位的描述性名称。
位置。（可选）。输入您公司所在的城市的名称。
省或自治区。输入您公司所在的省或自治区的全名（非缩写）。
国家/地区。选择您国家/地区的双字符缩写（ISO 格式）。美国的国家/地区代码为 US。 包含一份 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。通常，证书颁发机构会要求此示例中显示的所有属性，以完整地识别此服务器。请参见上面的，以获取每个属性的说明。
服务器会根据请求的步骤将上节中的请求传输至证书颁发机构。例如，可能会要求您以电子邮件的形式发送证书请求，或者也可以通过 CA 的 Web 站点输入请求。
发送了请求后，必须等待 CA 对您的证书作出响应。请求响应时间会有所不同。例如，如果 CA 在您公司内部，可能只需要一到两天时间就可响应请求。如果选择了公司外部的 CA，则可能需要用几周的时间来响应请求。
当 CA 发送响应时，一定要将信息保存到一个文本文件中。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-----
还应将证书数据备份到一个安全的地方。如果系统曾丢失证书数据，则可使用备份文件重新安装证书。
获得服务器证书后即可将其安装到服务器的证书数据库中。
显示“管理证书”窗口。
显示“证书安装向导”。
在此文件中，在此字段中输入证书的绝对路径。
在以下编码文本块中。将来自证书颁发机构的文本或您创建的文本文件中的文本复制并粘贴到此字段。例如：
单击“下一步”以继续。
您的新证书将显示在“服务器证书”选项卡上的列表中。现在您的服务器已为激活 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 -L -d ServerRoot/alias -P slapd-serverID-
列出的具有信任属性 u,, 的证书是服务器证书。
配置 Directory Server 以信任证书颁发机构，配置过程由获得 CA 证书和将其安装到服务器的证书数据库两部分组成。此过程根据您所使用的证书颁发机构的不同而有所区别。某些商业 CA 提供允许您自动下载证书的 Web 站点，而有些 CA 则根据您的请求以电子邮件的形式将证书发送给您。
获得 CA 证书后，可使用“证书安装向导”配置 Directory Server 以信任证书颁发机构。
显示“管理证书”窗口。
显示“证书安装向导”。
接受来自客户机的连接（客户机验证）。如果 LDAP 客户机通过提交此 CA 颁发的证书来执行基于证书的客户机验证，则请选中此复选框。
接受来自其他服务器的连接（服务器验证）。您的服务器通过 SSL 与另一个具有此 CA 所颁发证书的服务器进行通讯的过程中，如果此服务器担当复制提供者或链接多路复用器的角色，请选中此复选框。
certutil -A -n "CAcertificateName" -t "trust,," -a -i certFile
-d ServerRoot/alias -P slapd-serverID-
其中 CAcertificateName 是提供的用来标识受信任 CA 的名称，certFile 是包含 PEM 编码文本格式的 PKCS #11 颁发机构证书的文本文件，trust 是以下代码之一：
certutil -L -d ServerRoot/alias -P slapd-serverID-
列出的具有信任属性 u,, 的证书是服务器证书，那些具有信任属性 CT,, 的证书是受信任的 CA 证书。
完成服务器证书和受信任 CA 的证书的安装后，即可激活 SSL。大多数时间，您希望服务器在启用 SSL 的情况下运行。如果临时禁用 SSL，请确保在处理要求保密性、验证或数据完整性的操作之前重新启用 SSL。
必须按照中描述的那样，创建一个证书数据库，获得并安装服务器证书并信任 CA 的证书，才能激活 SSL。
以下步骤将在 Directory Server 中激活 SSL 通讯并启用加密机制：
此选项卡显示当前服务器的加密设置。
不允许客户机验证。使用此选项，服务器将忽略客户机的证书并将拒绝基于它的验证。
允许客户机验证。这是默认设置。选择此选项，将根据客户机请求执行验证。有关基于证书验证的详细信息，请参见。
|
| |
注 |
如果正在通过复制方式使用基于证书的验证，则必须将消费者服务器配置为允许或要求客户机验证。 |
|
| |
要求客户机验证。选择此选项，如果客户机不响应服务器的验证请求，则客户机连接将被拒绝。
|
| |
注 |
如果 Server Console 通过 SSL 连接至 Directory Server，选择“要求客户机验证”将禁用通讯，这是因为 Server Console 没有可以用来进行客户机验证的证书。要通过命令行修改此属性，请参见。 |
|
| |
所有至安全端口的连接都必须使用 SSL。不论是否配置了安全端口，激活 SSL 后，客户机都会通过非安全端口使用 Start TLS 操作来执行 SSL 加密。
有关详细信息，请参见。
密码是用于加密和解密数据的算法。通常，加密期间密码使用的位数越多，则密码越难破解或者说更安全。使用的消息验证类型也可以标识 SSL 密码。消息验证是另一种计算校验和（用来保证数据完整性）的算法。有关密码算法及其强度的更完整的讨论，请参见 。
当客户机启动与服务器的 SSL 连接时，客户机和服务器必须使用同一密码以用于加密信息。在任何双向加密过程中，双方都必须使用相同密码（通常为双方都支持的保护能力最强的密码）。
Directory Server 提供以下 SSL 3.0 和 TLS 密码：
密码名称 |
说明 |
|---|---|
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，必须至少选择以下密码中的一种：
使用以下步骤来选择希望服务器使用的密码：
此选项卡显示当前服务器的加密设置。如 中所述，确保已为服务器启用 SSL。
显示“密码首选项”对话框。
除非出于某种安全原因而不能使用特定密码，否则应选择 none、MD5 之外的所有密码。
|
| |
警告 |
不要选择“没有加密，只进行 MD5 消息验证”密码，因为如果客户机上没有其他密码可用，服务器就会使用此选项。在这种情况下，连接是不安全的，因为没有使用加密。 |
|
| |
如果已将 Directory Server 配置为要求客户机验证并且使用 SSL 连接至 Server Console，那么就不能再使用 Server Console 管理任何 Sun Java System 服务器。您将只能改为使用相应的命令行实用程序。
然而，如果您希望更改目录配置以便可以使用 Server Console，则必须执行以下步骤以便不再要求而是允许客户机验证：
ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn:cn=encryption,cn=config
changetype:modify
replace:nsSSLClientAuth
nsSSLClientAuth:allowed
^D
可立即启动 Server Console。
客户机验证是一种服务器验证客户机身份的机制。可以使用 客户机提供的证书或者通过基于 SASL 的机制（如 DIGEST-MD5）简单执行客户机验证（通过提供 DN 和密码）。在 Solaris 操作系统上，目前 Directory Server 通过 SASL 支持 GSSAPI 机制，该机制允许通过 Kerberos V5 进行客户机验证。
基于证书的验证使用通过 SSL 协议获得的客户机证书，来查找用户条目以进行标识。此机制也称为 EXTERNAL，因为它依赖已在较低层建立的验证机制。（在以后的版本中，可使用 IP 安全协议 (ipsec) 进行外部验证。）
对基于证书的验证进行了完整说明。
以下小节介绍如何在 Directory Server 上配置两个 SASL 机制。另请参见。
|
| |
注 |
标识映射不支持链接的后缀。 |
|
| |
DIGEST-MD5 机制通过比较具有无序用户密码的客户机发送的无序值对客户机进行验证。然而，因为此机制必须读取用户密码，所以希望通过 DIGEST-MD5 进行验证的所有用户都必须在目录中有一个 {CLEAR} 密码。将 {CLEAR} 密码存储到目录中时，必须确保通过 ACI 正确限制对密码值的访问，如中所述。您可能希望如中所述通过在该后缀中配置属性加密来进一步保护 {CLEAR} 密码。
以下过程说明了配置 Directory Server 以使用 DIGEST-MD5 的必要步骤：
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
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
SASL 机制的标识映射尝试将 SASL 标识凭证与目录中的用户条目进行匹配。有关该机制的完整说明，请参见。如果映射未能找到与 SASL 标识相对应的 DN，则验证失败。
SASL 标识是名为 Principal 的字符串，它以每个机制的特定格式来表示用户。在 DIGEST-MD5 中，建议客户机创建一个包含 dn:前缀和 LDAP DN 或 u:前缀（后面是客户机确定的任意文本）的 Principal。映射期间，客户机发送的 Principal 在 ${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
此标识映射假设 Principal 的 dn 字段包含目录中现有用户的确切 DN。
要定义您自己的 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)
SASL 上的综合安全服务应用程序接口 (GSSAPI) 允许您使用第三方安全系统（如 Kerberos V5）来验证客户机。GSSAPI 库仅在基于 Solaris SPARC 的平台上可用。Sun 建议您在 Sun Enterprise Authentication Mechanism (SEAM) 1.0.1 服务器中安装 Kerberos V5 实现。
服务器使用此 API 来验证用户的身份。然后，SASL 机制应用 GSSAPI 映射规则，以获得连接期间所有操作的绑定 DN。
按照制造商的说明配置 Kerberos 软件。如果使用的是 SEAM 1.0.1 服务器，则配置过程包括以下步骤：
ldap/serverFQDN@REALM
其中 serverFQDN 是 Directory Server 的全限定域名。
请注意，必须在主机上配置 DNS。
有关每一步操作的详细说明，请参见软件文档。另请参见示例。
以下过程说明了配置 Directory Server 以在 Solaris 平台上使用 GSSAPI 的必要步骤：
在 start-slapd 脚本中设置环境变量 KRB5_KTNAME，以确保使用新的 keytab，而非默认 keytab。
请注意，必须在主机上配置 DNS。
SASL 机制的标识映射尝试将 SASL 标识凭证与目录中的用户条目进行匹配。有关此机制的完整说明，请参见。如果映射未能找到与 SASL 标识相对应的 DN，则验证失败。
SASL 标识是名为 Principal 的字符串，它以每个机制的特定格式来表示用户。在 Kerberos 中使用 GSSAPI 时，Principal 是具有 uid[/instance][@realm] 格式的标识，其中 uid 可能包含一个可选的 instance 标识符（其后跟着的通常为域名的可选 realm）。例如，以下全部为有效的用户 Principal：
bjensen
bjensen/Sales
bjensen@EXAMPLE.COM
bjensen/Sales@EXAMPLE.COM
最初，未在目录中定义 GSSAPI 映射。根据客户机定义其使用的 Principal 的方式，您应该定义默认映射和需要的任何自定义映射。
要定义 GSSAPI 的标识映射，请执行以下操作：
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 中的若干验证机制需要一个从其他协议的凭证至目录中 DN 的映射。目前，DSML-over-HTTP 协议和 DIGEST-MD5 以及 GSSAPI SASL 机制之间就是这种情况。每个验证机制都将使用标识映射来确定由客户机提供的基于协议特定凭证的绑定 DN。
标识映射使用 cn=identity mapping, cn=config 配置分支中的条目。此分支为每个必须执行标识映射的协议包括一个容器：
映射条目定义了提取协议特定凭证的元素以在搜索目录时使用这些元素的方式。如果该搜索仅返回一个用户条目，则映射已经成功，且连接将使用此条目作为所有操作的绑定 DN。如果搜索没有返回条目或返回多个条目，则映射失败，将应用其他映射。
每个分支应该包含该协议的一个默认映射以及任意数量的自定义映射。默认映射具有 RDN cn=default，自定义映射可能具有使用 cn 作为命名属性的任何其他 RDN。将首先以不确定的顺序评估所有自定义映射，直至其中一个映射成功。如果所有自定义映射均失败了，则最后将应用默认映射。如果默认映射也失败了，那么客户机验证失败。
映射条目必须包含 top、Container 和 dsIdentityMapping 对象类。然后，条目还可能包含以下属性：
另外，映射条目还可能包含允许其使用下列属性的 dsPatternMatching 对象类：
上面所有的属性值（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 使用扩展的正则表达式，所有的比较项都不区分大小写。有关详细信息，请参见 中这些函数的 man 页面。
可能包含占位符的属性值必须对不属于占位符组成部分的任意 $、{ 和 } 字符进行编码（即使没有使用占位符）。必须使用以下值对这些字符进行编码：$ 替换为 24、{ 替换为 7B，} 替换为 7D。
使用占位符和替换值将允许您创建映射（映射将从协议特定凭证中提取用户名或其他任意值），并使用映射值来定义已映射的 DN，或者在目录的任意位置搜索相应的 DN。应该定义提取由目录客户机提供的预期凭证的映射，并将其映射到特定的目录结构。
|
| |
警告 |
创建定义不完善的映射将会成为安全漏洞。例如，无模式匹配的到硬编码 DN 的映射总是能成功，因此将验证可能不是目录用户的客户机。 定义若干映射来处理不同的客户机凭证格式，而不是创建一个单一的、过于普通和随意的映射，这样会更安全。应该根据客户机凭证始终尝试将客户机连接映射至特定用户。 |
|
| |
以下几节介绍如何在希望与 Directory Server 建立安全连接的 LDAP 客户机中配置和使用 SSL。在 SSL 连接中，服务器会将其证书发送给客户机。客户机首先必须信任其证书以验证服务器。然后，客户机可以通过发送自己的证书或两个 SASL 机制之一（DIGEST-MD5 或使用 Kerberos V5 的 GSSAPI）的信息来启动某一客户机验证机制。
以下几节使用 ldapsearch 工具作为启用 SSL 的 LDAP 客户机的示例。Directory Server 中提供的 ldapmodify、ldapdelete 和 ldapcompare 工具的配置方式相同。这些目录访问工具均基于 Directory SDK for C， 中对其进行了进一步说明。
要在其他 LDAP 客户机上配置 SSL 连接，请参见应用程序附带的文档。
|
| |
注 |
某些客户机应用程序实施 SSL，但并不验证服务器是否具有受信任的证书。它们使用 SSL 协议以提供数据加密，但既不能保证保密性，也不能防止客户机的假冒。 |
|
| |
当客户机建立与服务器的 SSL 连接时，它必须信任服务器提交的证书。为完成此操作，客户机必须：
Mozilla 是使用 SSL 通过 HTTP 协议与 Web 服务器进行通讯的客户机应用程序。可以使用 Mozilla 管理 LDAP 客户机也将使用的证书。或者，可以使用 certutil 工具管理证书数据库。
以下过程介绍如何使用 Mozilla 在客户机中管理证书数据库。
如果使用此过程，请找到由 Mozilla 创建的证书数据库，并记住客户机应用程序使用的路径。
例如，如果正在使用内部部署的 Sun Java System 证书服务器，请转到具有 https://hostname:444 形式的 URL。
根据 CA 的 Web 站点规定，此步骤可能无法执行。如果 Mozilla 未自动提示您信任 CA 证书，请使用以下步骤手动执行。
使用 certutil 工具通过命令行管理证书。SUNWtlsu 软件包中提供有此工具。
certutil -N -d path -P prefix
该工具将提示用户输入密码以保护证书。然后，该工具将创建以下文件：path/prefixcert8.db and path/prefixkey3.db.
应该由 LDAP 客户机应用程序的用户在只能由其访问的位置单独创建证书数据库（例如，其主目录受保护的子目录）。
例如，如果正在使用内部部署的 Sun Java System 证书服务器，请转到具有 https://hostname:444 形式的 URL。在顶级“检索”选项卡中，选择“导入 CA 证书链接”并复制那里的已编码证书。
或者，如果从同一 CA 中获得客户机证书和服务器证书，则可以重复使用通过中的过程获得的 CA 证书。
certutil -A -n "certificateName" -t "C,," -a -i certFile -d path -P prefix
其中，certificateName 是给定的用来标识此证书的名称，certFile 是包含 PEM 编码文本格式的 PKCS #11 颁发机构证书的文本文件，path 和 prefix 与 中的相同。
LDAP 客户机应用程序的每个用户都必须将 CA 证书导入至其证书数据库中。所有用户可以导入位于 certFile 中的相同证书。
要使用 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)"
