|
| |
| Sun Java(TM) System Directory Server 5 2004Q2 管理指南 | |
第 11 章
管理驗證和加密Directory Server 支援數種機制以提供安全和受信任的網路通訊。LDAPS 是標準的 LDAP 通訊協定，此通訊協定在安全通訊端階層 (SSL) 上執行，用以加密資料並選用憑證。
Directory Server 也支援啟動傳輸層安全性 (Start TLS) 延伸作業，以便在原本未加密的 LDAP 連線上啟用 TLS。
Directory Server 現在也支援在簡單驗證及安全階層 (SASL) 上的 Generic Security Services API (GSSAPI)。這可讓您在 Solaris 作業系統中使用 Kerberos Version 5 安全通訊協定。再透過一個識別對映機制，使 Kerberos 策略與目錄中的識別產生關聯。
如需其他安全資訊，請參閱 NSS 網站：
http://www.mozilla.org/projects/security/pki/nss/
本章包含下列章節：
Directory Server 中的 SSL 簡介安全通訊端階層 (SSL) 在 Directory Server 與其用戶端之間提供加密通訊與選用的驗證。不論是 LDAP 或 DSML-over-HTTP 通訊協定都可以啟用 SSL，為伺服器的任何連線提供安全性。此外，複製及鏈接尾碼機制也可以配置成使用 SSL，使伺服器之間能夠進行安全的通訊。
將 SSL 與簡單驗證 (連結 DN 與密碼) 一起使用時，所有進出伺服器的資料都會加密，以保證資料的機密性與完整性。用戶端可以選擇使用憑證通過 Directory Server 的驗證，或透過簡單驗證及安全階層 (SASL) 使用協力廠商的安全性機制通過驗證。以憑證為基礎的驗證使用公開金鑰加密，以防有人偽造及冒充用戶端或伺服器的身份。
Directory Server 能夠在不同連接埠上同時處理 SSL 與非 SSL 通訊；您也可以限制所有通訊都必須通過安全連接埠，以維護系統安全性。用戶端驗證也是可設定的，您可以依據強制實施的安全層級，指定用戶端必須通過驗證，或是直接允許存取。
啟用 SSL 也會啟用 Start TLS 延伸作業，以提供一般 LDAP 連線上的安全性。用戶端可以連結到非 SSL 連接埠，再使用傳輸層安全性通訊協定啟動 SSL 連線。Start TLS 作業讓用戶端更有彈性，而且可能有助於簡化連接埠配置。
SSL 所提供的加密機制也用於屬性加密。啟用 SSL 將允許您在尾碼上配置屬性加密，使資料儲存在目錄期間能夠受到保護。如需詳細資訊，請參閱「加密屬性值」。
為提供更多一層保護，您可以根據用戶端使用 SSL 或憑證，來配置目錄內容的存取控制。您可以定義要求特定驗證方法的存取控制指令 (ACI)，從而確保資料只能透過安全的通道傳送。如需詳細資訊，請參閱「連結規則」。
如需 SSL、網際網路安全性和憑證的完整描述，也包括如何在管理伺服器中配置 SSL，請參閱《Administration Server Administration Guide》中的 Chapter 9 "Using SSL and TLS with Sun Java System Servers"。
啟用 SSL 的步驟摘要以下每個步驟都將於本章隨後各節中說明：
上述步驟中，有些可以用 certutil 工具執行，以透過指令行管理憑證。此工具於 SUNWtlsu 封裝中提供。
取得和安裝伺服器憑證本節描述建立憑證資料庫、取得和安裝與 Directory Server 一起使用的憑證、以及將 Directory Server 配置成信任憑證授權單位 (CA) 憑證的程序。
建立憑證資料庫
初次在伺服器上配置 SSL 時，您必須為安全裝置設定密碼。如果不使用外部的硬體安全裝置，則內部安全裝置是儲存在下列檔案中的憑證與金鑰資料庫：
ServerRoot/alias/slapd-serverID-cert8.db
ServerRoot/alias/slapd-serverID-key3.db如果您的 serverID 包含大寫字母，您必須用以下指令行程序建立憑證資料庫。
使用主控台
使用主控台時，伺服器將在您第一次啟動 [憑證管理員] 對話方塊時自動建立憑證資料庫檔案：
使用指令行
從指令行建立憑證資料庫檔案時，您必須使用以下程序中所示的路徑與檔案名稱字首，讓伺服器可以找得到它們。
產生憑證要求
使用下列程序之一產生 PEM 格式的 PKCS #10 憑證要求。PEM 是 RFC 1421 到 1424 (http://www.ietf.org/rfc/rfc1421.txt) 所指定的 Privacy Enhanced Mail 格式，並用來代表 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 Console 最上層的 [工作] 標籤上，按一下 [管理憑證] 按鈕；或者，在已顯示 [工作] 標籤時，從 [主控台] > [安全性] 功能表中選擇 [管理憑證] 項目。
顯示 [管理憑證] 對話方塊。
- 選擇 [伺服器憑證] 標籤，並按一下 [要求] 按鈕。
顯示 [憑證要求精靈]。
- 如果您已安裝可讓伺服器直接與 CA 通訊的 Plug-in，現在可以選取該 Plug-in ；否則，您必須經由電子郵件或網站傳送產生的要求，以手動要求憑證。按一下 [下一步] 繼續。
- 在空白文字欄位中輸入「要求者資訊」：
伺服器名稱。輸入 Directory Server 的完全合格主機名稱，例如 east.example.com，此名稱與 DNS 查詢中所使用的名稱相同。
組織。輸入您公司或機構的正式名稱。大部分的 CA 會要求您提供正式文件以驗證這項資訊，例如公司執照的複本。
組織單位。(選用)。輸入您的部門或業務單位在公司內的描述性名稱。
位置。(選用)。輸入您公司所在的城市名稱。
州或省。輸入您公司所在州或省的完整名稱，不可用縮寫。
國家。選擇代表您國家名稱的兩個字元縮寫 (採用 ISO 格式)。美國的國碼為 US。《Directory Server Administration Reference》中的 Chapter 5 "Directory Internationalization Reference"中包含 ISO 國碼清單。
按一下 [下一步] 繼續。
- 輸入安全裝置的密碼，再按一下 [下一步]。此密碼於「建立憑證資料庫」中設定。
- 選擇 [複製至剪貼簿] 或 [儲存至檔案]，以儲存您必須傳送到憑證授權單位的憑證要求資訊。
- 按一下 [完成] 退出 [憑證要求精靈]。
使用指令行
安裝伺服器憑證
依憑證授權單位指定的程序，將上一節產生的要求傳給憑證授權單位。例如，您可能須以電子郵件傳送憑證要求，或者您可以透過 CA 的網站輸入要求。
一旦傳送要求後，您必須等待 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-----您也應該將憑證資料備份到安全的位置。萬一您的系統遺失了憑證資料，您便可以使用備份檔案重新安裝憑證。
一旦取得伺服器憑證後，您便可以準備將它安裝到伺服器的憑證資料庫中。
使用主控台
使用指令行
- 用下列指令在您的憑證資料庫中安裝新的伺服器憑證：
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 憑證後，您便可以使用 [憑證安裝精靈] 配置 Directory Server，使其信任憑證授權單位。
- 在 Directory Server Console 最上層的 [工作] 標籤上，按一下 [管理憑證] 按鈕；或者，在已顯示 [工作] 標籤時，從 [主控台] > [安全性] 功能表中選擇 [管理憑證] 項目。
顯示 [管理憑證] 視窗。
- 選取 [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 編碼文字格式的 CA PKCS #11 憑證，而 trust 是下列代碼之一：
- 或者，您也可以用下列 certutil 指令確認您安裝的憑證：
certutil -L -d ServerRoot/alias -P slapd-serverID
列出的憑證中，包含 u,, 者為伺服器憑證，而包含 CT,, 者為受信任的 CA 憑證。
啟用 SSL一旦安裝好伺服器憑證並信任 CA 的憑證後，便可以準備啟用 SSL。大部分的時候，您希望在啟用 SSL 的情形下執行伺服器。如果您暫時停用了 SSL，在處理需要機密性、驗證或資料完整性的作業之前，請先確定已重新啟用 SSL。
必須先建立憑證資料庫、取得和安裝伺服器憑證，並信任 CA 的憑證之後，才能啟用 SSL，如「取得和安裝伺服器憑證」中所述。
接著，下列程序將啟動 SSL 通訊，並啟用目錄伺服器的加密機制：
- 在 Directory Server Console 最上層的 [組態] 標籤上，選擇有伺服器名稱的根節點，然後選擇右面板中的 [加密] 標籤。
標籤中會顯示目前伺服器的加密設定值。
- 選擇 [啟用這台伺服器的 SSL] 核取方塊表示要啟用加密。
- 核取 [使用此加密家族] 核取方塊
- 從下拉式功能表中選擇您要使用的憑證。
- 按一下 [加密設定值]，並在 [加密喜好設定] 對話方塊中選擇要使用的加密。如需關於特定加密的詳細資訊，請參閱「選擇 Encryption Cipher」。
- 設定用戶端驗證的喜好設定：
不允許用戶端驗證。使用這個選項時，伺服器將忽略用戶端憑證，而且將拒絕依此為基礎的驗證。
允許用戶端驗證。這是預設值。使用這個選項時，驗證是在用戶端要求時才執行。如需關於以憑證為基礎之驗證的詳細資訊，請參閱「配置用戶端驗證」。
要求用戶端驗證。使用這個選項時，如果用戶端不回應伺服器的驗證要求，用戶端連線將被拒絕。
備註
如果 Server Console 透過 SSL 連線到 Directory Server，則選擇 [要求用戶端驗證] 將停用通訊，因為 Server Console沒有用戶端驗證所需的憑證。若要從指令行修改此屬性，請參閱「允許用戶端驗證」。
- 或者，如果希望主控台與 Directory Server 通訊時使用 SSL，請選擇 [在 Server Console中使用 SSL]。
- 完成時按一下 [儲存]。
- 或者，設定伺服器在 LDAP 與 DSML-over-HTTP 通訊協定中進行 SSL 通訊時所要用的安全連接埠。如需資訊，請參閱「變更目錄伺服器連接埠號碼」。
所有與安全連接埠的連線都必須使用 SSL。不論是否配置安全連接埠，一旦啟動 SSL，用戶端就可以使用 Start TLS 作業透過非安全連接埠執行 SSL 加密。
- 重新啟動 Directory Server。
如需更多資訊，請參閱「啟動啟用 SSL 的伺服器」。
選擇 Encryption Cipher
加密 (cipher) 是用來加密與解密資料的演算法。一般而言，加密過程中使用的位元越多，表示該加密更強大或更安全。SSL 的加密也由使用的訊息驗證類型識別。訊息驗證是另一個演算法，它會計算保證資料完整性的總和檢查碼。如需更多關於演算法及其強度的完整討論，請參閱《Administration Server Administration Guide》Appendix B 中的"Ciphers Used With SSL"。
當用戶端啟動與伺服器的 SSL 連線時，用戶端與伺服器雙方必須同意用於加密資訊的加密方式。在任何雙向加密處理中，雙方必須使用相同的加密，通常是用雙方同時支援的最強加密方式。
Directory Server 為 SSL 3.0 與 TLS 提供下列加密：
為了繼續使用具有 SSL 的 Server Console，您必須至少選擇下列其中一個加密：
使用以下程序可選擇伺服器要用的加密方式：
- 在 Directory Server Console 最上層的 [組態] 標籤上，選擇有伺服器名稱的根節點，然後選擇右面板中的 [加密] 標籤。
標籤中會顯示目前伺服器的加密設定值。務必確認伺服器的 SSL 已啟用，如「啟用 SSL」所述。
- 按一下 [加密設定值]。
顯示 [加密喜好設定] 對話方塊。
- 在 [加密喜好設定] 對話方塊中，選擇或取消選取加密旁的核取方塊，以指定您希望伺服器使用的加密。
除非您因安全性的理由而不使用特定加密，否則您應該選擇所有加密，除 none,MD5 之外。
- 在 [加密喜好設定] 對話方塊中按一下 [確定]，然後在 [加密] 標籤中按一下 [儲存]。
允許用戶端驗證
如果 Directory Server 已設為需要用戶端驗證和 Server Console才能使用 SSL 進行連線，您將不再能夠使用 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) 使用。)。
以憑證為基礎的驗證詳細說明於《Administration Server Administration Guide》Chapter 9 的 "Using Client Authentication" 中。
下列各節描述在 Directory Server 上配置兩種 SASL 機制的方式。請參閱「將 LDAP 用戶端配置為使用安全性」。
透過 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=*)" supportedSASLMechanismsdn:
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 識別對映」所述建立新的識別對映。
- 確定已為即將透過 SSL 使用 DIGEST-MD5 存取伺服器的所有使用者在 {CLEAR} 中儲存密碼。如需配置密碼儲存結構的說明，請參閱第 7 章「管理使用者帳戶和密碼」。
- 如果修改了 SASL 組態項目或 DIGEST-MD5 識別對映項目之一，請重新啟動目錄伺服器。
DIGEST-MD5 識別對映
SASL 機制的識別對映會嘗試將 SASL 識別的憑證對映目錄中的使用者項目。如需此機制的完整描述，請參閱「識別對映」。如果對映找不到與 SASL 識別相對的 DN，驗證將會失敗。
SASL 識別是稱為 Principal 的字串，以每種機制特定的格式代表某使用者。在 DIGEST-MD5 中，用戶端所建立的 Principal 應該包含一個 dn:字首及一個 LDAP DN，或是一個 u:字首其後跟著由用戶端決定的任何文字。在對映期間，由用戶端傳送的 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 識別對映：
- 編輯預設識別對映，或在 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 的 Generic Security Services API (GSSAPI) 可讓您使用如 Kerberos V5 一類協力廠商的安全性系統對用戶端進行驗證。只有 Solaris 平台提供 GSSAPI 程式庫。Sun 建議您在 Sun Enterprise Authentication Mechanism (SEAM) 1.0.1 伺服器上安裝 Kerberos V5 執行。
伺服器使用此 API 驗證使用者的身份。然後，SASL 機制會套用 GSSAPI 對映規則以取得 DN，做為連線期間所有作業的連結 DN。
配置 Kerberos 系統
根據製造廠商的指示設定 Kerberos 軟體。如果使用 SEAM 1.0.1 伺服器，這包括下列步驟：
如需以上每一步驟的詳細指示，請參閱軟體說明文件。
設定 GSSAPI 機制
下列程序描述在 Solaris 平台上設定 Directory Server 以使用 GSSAPI 的所需步驟：
- 使用主控台或 ldapsearch 指令，確認 GSSAPI 是根項目上 supportedSASLMechanisms 屬性的值。例如，下列指令將顯示已啟用的 SASL 機制：
ldapsearch -h host -p port -D "cn=Directory Manager" -w password \
-s base -b "" "(objectclass=*)" supportedSASLMechanismsdn:
supportedSASLMechanisms:EXTERNAL
supportedSASLMechanisms:DIGEST-MD5- 預設狀況下不啟用 GSSAPI，您可以用下列 ldapmodify 指令將它啟用：
ldapmodify -h host -p port -D "cn=Directory Manager" -w password
dn:cn=SASL, cn=security, cn=config
changetype:modify
add:dsSaslPluginsEnable
dsSaslPluginsEnable:GSSAPI
-
replace:dsSaslPluginsPath
dsSaslPluginsPath:ServerRoot/lib/sasl- 依「GSSAPI 識別對映」所述建立 GSSAPI 的預設識別對映，以及任何自訂對映。
- 在伺服器主機電腦上為伺服器設定 Kerberos：
- 如果修改了 SASL 組態項目或 GSSAPI 識別對映項目之一，請重新啟動目錄伺服器。
GSSAPI 識別對映
SASL 機制的識別對映會嘗試將 SASL 識別的憑證對應目錄中的使用者項目。如需此機制的完整描述，請參閱「識別對映」。如果對映找不到與 SASL 識別相對的 DN，驗證將會失敗。
SASL 識別是稱為 Principal 的字串，以每種機制特定的格式代表某使用者。在使用 GSSAPI 的 Kerberos 中，Principal 識別的格式為 uid[/instance][@realm]，其中 uid 可包含選用的 instance 識別碼，其後跟著選用的 realm，這通常是網域名稱。例如，以下為有效的使用者 Principal：
bjensen
bjensen/Sales
bjensen@EXAMPLE.COM
bjensen/Sales@EXAMPLE.COM一開始，目錄中不會定義任何 GSSAPI 對映。請依據您的用戶端定義所用 Principal 的方式，定義預設對映與任何需要的自訂對映。
若要定義 GSSAPI 的識別對映：
- 在 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這個檔案中的另一個範例顯示當使用者 ID 包含於內含已知範圍的 Principal 內時，要如何決定使用者 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 組態分支中的項目。所有必須執行識別對映的通訊協定在此分支內各有一個容器：
對映項目定義從通訊協定特定的憑證中擷取元素的方法，以便用這些元素在目錄中搜尋。如果該搜尋傳回一個使用者項目，表示對映成功，連線將使用此項目做為所有作業的連結 DN。如果搜尋傳回零個或多個項目，則對映失敗，將套用其他任何對映。
每個分支應包含該通訊協定的預設對映，以及任何數目的自訂對映。預設對映的 RDN 為 cn=default，而自訂對映可擁有任何其他 RDN，只要使用 cn 做為命名屬性。所有自訂對映都會依非決定性順序優先評估，直到成功為止。如果所有自訂對映都失敗，最後才套用預設對映。如果預設對映也失敗，則用戶端的驗證失敗。
對映項目必須包含 top、Container 與 dsIdentityMapping 物件類別。然後項目可包含下列屬性：
- dsMappedDN:DN ─ 為文字字串，定義目錄中的 DN。執行對映時，如果此 DN 存在，則會用於連結。萬一此 DN 不存在時，您也可以定義下列屬性執行搜尋。
- dsSearchBaseDN:DN ─ 搜尋的 Base DN。如果忽略了，則對映會在整個樹狀目錄中搜尋所有的根尾碼。
- dsSearchScope:base|one|sub ─ 搜尋範圍，也許是搜尋基礎本身、基礎下一層的子項、或基礎下的整個樹狀子目錄。忽略此屬性時，對映搜尋的預設範圍為整個樹狀子目錄。
- dsSearchFilter:filterString ─ 篩選字串，用來執行對映搜尋。LDAP 搜尋篩選器定義於 RFC 2254 (http://www.ietf.org/rfc/rfc2254.txt) 中。
此外，對映項目也可包含 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。
dsMatching-pattern 與 dsMatching-regexp 的比較是使用 Posix regexec(3C) 與 regcomp(3C) 函數呼叫。Directory Server 使用延伸規則運算式，而且所有比較會區分大小寫。如需詳細資訊，請參閱這些函數的 man 說明頁。
可包含保留位置的屬性值必須將不在保留位置內的任何 $、{ 與 } 字元編碼，即使不使用保留位置。您必須以下列值編碼這些字元：$ 為 \24、{ 為 \7B 及 } 為 \7D。
使用保留位置與替代的方式可讓您建立從通訊協定特定的憑證中擷取使用者名稱或任何其他值的對映，將此值用來定義對映的 DN 或在目錄中的任何位置搜尋對應 DN。您應該定義對映，擷取目錄用戶端提供的預期憑證，再將它們對映到您特定的目錄結構。
小心
建立定義不正確的對映將成為安全上的漏洞。例如，對映中若不使用模式對映，而是對映到固定的 DN，則該對映一定會成功，因此即使非目錄使用者的用戶端一樣會通過驗證。
比較安全的作法是定義數個對映，分別處理不同的用戶端憑證格式，而不要單單建立一個過度通用而且寬鬆的對映。您永遠都要嘗試將用戶端連線根據用戶端的憑證對映到特定使用者。
將 LDAP 用戶端配置為使用安全性下列各節說明如何在希望與目錄伺服器建立安全連線的 LDAP 用戶端中設定及使用 SSL。在 SSL 連線中，伺服器傳送其憑證到用戶端。用戶端必須先信任伺服器的憑證，使伺服器通過驗證。然後用戶端可以選擇傳送它自己的憑證或兩種 SASL 機制 (DIGEST-MD5 或使用 Kerberos V5 的 GSSAPI) 之一的資訊，以啟動一種用戶端驗證機制。
下列各節使用 ldapsearch 工具做為啟用 SSL 的 LDAP 用戶端的範例。目錄伺服器所提供的 ldapmodify、ldapdelete 與 ldapcompare 工具都以相同的方式設定。這些目錄存取工具是以 Directory SDK for C 為基礎，詳細文件記錄在《Directory Server Resource Kit Tools Reference》中。
若要在非 LDAP 用戶端上設定 SSL 連線，請參閱應用程式所提供的說明文件。
在用戶端中配置伺服器驗證
當用戶端建立與伺服器的 SSL 連線時，它必須信任伺服器提出的憑證。為執行此動作，用戶端必須：
Mozilla 就是使用 SSL 透過 HTTP 通訊協定與 Web 伺服器進行通訊的用戶端應用程式。您可以用 Mozilla 管理您的 LDAP 用戶端也將會使用的憑證。或者，您可以用 certutil 工具管理憑證資料庫。
透過 Mozilla 管理用戶端憑證
下列程序描述如何使用 Mozilla 管理用戶端電腦上的憑證資料庫。
- Mozilla 一啟動就會確保憑證資料庫已存在，否則它將視需要建立憑證資料庫。憑證資料庫將與其他 Mozilla 喜好設定一起儲存在檔案中，例如 .mozilla/username/string.slt/cert8.db。
如果您使用此程序，請找出 Mozilla 所建立的憑證資料庫並記住其路徑，以供您的用戶端應用程式使用。
- 使用 Mozilla 瀏覽找出為您要存取的目錄伺服器發行憑證的憑證授權單位網站。Mozilla 將自動擷取憑證授權單位的憑證，並詢問您是否應該信任該憑證。
例如，如果使用內部部署的 Sun Java System 憑證伺服器，您將移到類似 https://hostname:444 格式的 URL。
- 當 Mozilla 提示時，信任憑證授權單位的憑證。您應該信任伺服器驗證的 CA 憑證。
依 CA 網站的不同，可能會無法執行此步驟。如果 Mozilla 不自動提示您信任 CA 憑證，請使用下列程序手動執行。
透過指令行管理用戶端憑證
使用 certutil 工具透過指令行管理憑證。此工具於 SUNWtlsu 封裝中提供。
- 在用戶端主機電腦上，用下列指令建立憑證資料庫：
certutil -N -d path -P prefix
工具將提示使用者輸入密碼，以保護憑證。然後工具將建立下列檔案：path/prefixcert8.db and path/prefixkey3.db.
憑證資料庫應由 LDAP 用戶端應用程式的使用者個別建立在只能由該使用者存取的位置，例如使用者主目錄的受保護子目錄。
- 聯絡為您要存取的 Directory Server 發行憑證的憑證授權單位，並要求其 CA 憑證。您可以傳送電子郵件或存取網站，以取得 PKCS #11 憑證的 PEM 編碼文字版本。將此憑證儲存在檔案內。
例如，如果使用內部部署的 Sun Java System 憑證伺服器，您將移到類似 https://hostname:444 格式的 URL。從最上層的 [擷取] 標籤，選擇 [匯入 CA 憑證鏈接]，並複製那堛瑤s碼憑證。
或者，如果您從同一個 CA 取得您的用戶端與伺服器憑證，您可以重複使用透過「信任憑證授權單位」程序所取得的 CA 憑證。
- 將 CA 憑證匯入為受信任的 CA，可以發行 SSL 連線中所用的伺服器憑證。請使用下列指令：
certutil -A -n "certificateName" -t "C,," -a -i certFile -d path -P prefix
其中 certificateName 是您為此憑證指定的識別名稱，certFile 是文字檔，內含 PEM 編碼文字格式的 CA 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)"在用戶端中配置以憑證為基礎的驗證
用戶端驗證的預設機制使用憑證以安全地識別目錄伺服器的使用者。為了執行以憑證為基礎的用戶端驗證，您必須：
- 為每個目錄使用者取得憑證，並安裝在用戶端應用程式可存取的位置。
- 用同一憑證的二進位複本配置使用者的目錄項目。驗證過程中，伺服器會將用戶端應用程式提出的憑證，對映此複本，以明確識別使用者。
- 依《Administration Server Administration Guide》Chapter 9 的 "Using Client Authentication" 所述，為伺服器配置以憑證為基礎的驗證。
- 為以憑證為基礎的驗證指定 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 與 prefix 指出使用者憑證與金鑰資料庫的位置。certutil 工具將提示使用者輸入金鑰資料庫的密碼。然後工具會以 PEM 編碼文字格式產生 PKCS #10 憑證要求。
- 將編碼的憑證要求儲存在檔案內，再依憑證授權單位指定的程序傳送到您的憑證授權單位。例如，您可能須以電子郵件傳送憑證要求，或者您可以透過 CA 的網站輸入要求。
- 一旦傳送要求後，您必須等待 CA 回應憑證，等待回應的時間長短不同。例如，如果您的 CA 在您公司內部，則回應您的要求只需一或兩天的時間。如果您選取的 CA 在公司外部，則可能需要花幾個星期的時間來回應您的要求。
- 當 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 網站上可能有連結可直接安裝憑證。請按一下此連結，並依照 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 子類型包含在其中，否則憑證對映將會失敗。在 < 前後的空格是有意義的，必須完全依照顯示方式使用。為了使用 < 語法指定檔案名稱，LDIF 陳述式的開頭行必須是 version:1。當 ldapmodify 處理此陳述式時，它會將屬性設為從指定檔案的完整內容讀取而來的值。
- 在 Directory Server 上，依需要安裝並信任為您發行使用者憑證那個 CA 的憑證。要接受來自用戶端的連線就必須信任此 CA。請參閱「信任憑證授權單位」。
- 依《Administration Server Administration Guide》Chapter 9 的 "Using Client Authentication" 所述，為 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 Plug-in 動態載入的共享程式庫，因此您應該依下列方式設定 SASL_PATH 變數 (以 Korn shell 為例)：
export SASL_PATH=ServerRoot/lib/sasl
此路徑假設 Directory Server 安裝在即將啟動 LDAP 工具的同一主機上。
ldapsearch 指令的範例
執行 DIGEST-MD5 用戶端驗證可以不必使用 SSL。以下範例將使用預設 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 選項。範圍是選用的，但如果指定範圍，它必須是伺服器主機電腦的完全合格網域名稱。authid 與 authzid 都必須存在而且完全相同，但不使用預計用於代理作業的 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
您必須在即將執行 LDAP 用戶端的主機電腦上配置 Kerberos V5：
指定 Kerberos 驗證的 SASL 選項
- 使用啟用 GSSAPI 的用戶端應用程式之前，您必須用下列指令，以您的使用者 Principal 初始化 Kerberos 安全性系統：
kinit userPrincipal
userPrincipal 是您的 SASL 識別，例如 bjensen@example.com。
- 以下 ldapsearch 工具的範例顯示如何使用 -o (小寫字母 o) 選項指定使用 Kerberos 的 SASL 選項：
ldapsearch -h host -p securePort \
-Z -P .mozilla/bjensen/string.slt/cert8.db \
-N "certificateName" -W keyPassword \
-o mech=GSSAPI [-o realm="example.com" \
-o authid="bjensen@example.com" \
-o authzid="bjensen@example.com"] \
-b "dc=example,dc=com" "(givenname=Richard)"- 在此範例中，-N 與 -W 選項是 ldapsearch 指令所需，但不用在用戶端驗證中。realm、authid 與 authzid 可省略，因為 kinit 指令所初始化的 Kerberos 快取中會提供這兩個選項。如果提供的話，authid 與 authzid 必須完全一樣，但不使用計劃供代理作業使用的 authzid。authid 的值是識別對映中所用的 Principal。如需詳細資訊，請參閱「GSSAPI 識別對映」。