第 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 Principal 與目錄中的識別產生關聯。

Directory Server 中的 SSL 簡介

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 的步驟摘要

取得 Directory Server 的憑證及安裝，並配置 Directory Server 以信任該憑證授權單位的憑證。此程序包括：

依需要建立憑證資料庫。

從您的伺服器產生憑證要求，並傳送給即將為您的伺服器提供憑證的憑證授權單位。

在伺服器中安裝新的憑證。

信任您的憑證授權單位及它發行的所有憑證。

在您的目錄中啟動與配置 SSL，包括 LDAP 與 DSML 作業的安全連接埠。您也可以將 Directory Server Console 配置為使用 SSL 來存取伺服器。

或者，將伺服器配置為使用下列一或多種用戶端驗證機制：

以憑證為基礎的預設驗證。

透過 SASL 的 DIGEST_MD5 驗證機制。

透過 SASL 的 GSSAPI 驗證，它可允許使用 Kerberos V5 安全機制。

完成這些步驟之後，將您的用戶端配置為在與 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) 所指定的 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-----

使用主控台

顯示 [管理憑證] 對話方塊。

選擇 [伺服器憑證] 標籤，並按一下 [要求] 按鈕。

顯示 [憑證要求精靈]。

如果您已安裝可讓伺服器直接與 CA 通訊的外掛程式，現在可以選取該外掛程式；否則，您必須經由電子郵件或網站傳送產生的要求，以手動要求憑證。按一下 [下一步] 繼續。

在空白文字欄位中輸入要求者資訊：

伺服器名稱。輸入 Directory Server 的完整格式主機名稱，例如 east.example.com，此名稱與 DNS 查詢中所使用的名稱相同。

組織。輸入您公司或機構的正式名稱。大部分的 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 的網站輸入要求。

一旦傳送要求後，您必須等待 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 憑證後，您便可以使用 [憑證安裝精靈] 配置 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 編碼文字格式的 CA 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，如取得和安裝伺服器憑證中所述。

接著，下列程序將啟動 SSL 通訊，並啟用 Directory Server 中的加密機制：

在 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。

當用戶端啟動與伺服器的 SSL 連線時，用戶端與伺服器雙方必須同意用於加密資訊的加密方式。在任何雙向加密處理中，雙方必須使用相同的加密，通常是用雙方同時支援的最強加密方式。

表 11-1 Directory Server所提供的加密
加密名稱	描述
無	未加密，只進行 MD5 訊息驗證 (rsa_null_md5)。
RC4 (128 位元)	具有 128 位元加密和 MD5 訊息驗證的 RC4 加密 (rsa_rc4_128_md5)。
RC4 (匯出)	具有 40 位元加密和 MD5 訊息驗證的 RC4 加密 (rsa_rc4_40_md5)。
RC2 (匯出)	具有 40 位元加密和 MD5 訊息驗證的 RC2 加密 (rsa_rc2_40_md5)。
DES 或 DES (匯出)	具有 56 位元加密和 SHA 訊息驗證的 DES (rsa_des_sha)。
DES (FIPS)	具有 56 位元加密和 SHA 訊息驗證的 FIPS DES。此加密符合 FIPS 140-1 美國政府密碼模組執行標準 (rsa_fips_des_sha)。
三重 DES	具有 168 位元加密和 SHA 訊息驗證的三重 DES (rsa_3des_sha)。
三重 DES (FIPS)	具有 168 位元加密和 SHA 訊息驗證的 FIPS 三重 DES。此加密符合 FIPS 140-1 美國政府密碼模組執行標準 (rsa_fips_3des_sha)。
Fortezza	具有 80 位元加密和 SHA 訊息驗證的 Fortezza 加密。
RC4 (Fortezza)	具有 128 位元加密和 SHA 訊息驗證的 Fortezza RC4 加密。
無 (Fortezza)	未加密，只進行 Fortezza SHA 訊息驗證。

為了繼續使用具有 SSL 的 Server Console，您必須至少選擇下列其中一個加密：

具有 40 位元加密和 MD5 訊息驗證的 RC4 加密。

未加密，只進行 MD5 訊息驗證 (不建議使用)。

具有 56 位元加密和 SHA 訊息驗證的 DES。

具有 128 位元加密和 MD5 訊息驗證的 RC4 加密。

具有 168 位元加密和 SHA 訊息驗證的三重 DES。

在 Directory Server Console 最上層的 [配置] 標籤上，選擇有伺服器名稱的根節點，然後選擇右面板中的 [加密] 標籤。

標籤中會顯示目前伺服器的加密設定值。務必確認伺服器的 SSL 已啟用，如啟用 SSL 所述。

按一下 [加密設定值]。

顯示 [加密喜好設定] 對話方塊。

在 [加密喜好設定] 對話方塊中，選擇或取消選取加密旁的核取方塊，以指定您希望伺服器使用的加密。

除非您因安全性的理由而不使用特定加密，否則您應該選擇所有加密，除 none,MD5 之外。



小心	應避免選擇沒有加密或只有 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) 使用。)。

透過 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 識別對映所述建立新的識別對映。

確定已為即將透過 SSL 使用 DIGEST-MD5 存取伺服器的所有使用者在 {CLEAR} 中儲存密碼。如需配置密碼儲存結構的說明，請參閱第 7 章「管理使用者帳戶和密碼」。

如果修改了 SASL 配置項目或 DIGEST-MD5 識別對映項目之一，請重新啟動 Directory Server。

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。

編輯預設識別對映，或在 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 一類協力廠商的安全性系統對用戶端進行驗證。只有以 SPARC 為基礎的 Solaris 平台提供 GSSAPI 程式庫。Sun 建議您在 Sun Enterprise Authentication Mechanism (SEAM) 1.0.1 伺服器上安裝 Kerberos V5 執行。

伺服器使用此 API 驗證使用者的身份。然後，SASL 機制會套用 GSSAPI 對映規則以取得 DN，作為連線期間所有作業的連結 DN。

配置 Kerberos 系統

根據製造廠商的指示配置 Kerberos 軟體。如果使用 SEAM 1.0.1 伺服器，這包括下列步驟：

配置 /etc/krb5 中的檔案。

建立 Kerberos 資料庫以儲存使用者與服務，並在此資料庫中建立 LDAP 服務的 principal。LDAP 服務 principal 是：

ldap/serverFQDN@REALM

其中 serverFQDN 是您 Directory Server 的完整合格的網域名稱。

啟動 Kerberos 常駐程式處理。

請注意，主機電腦上必須已配置 DNS。

配置 GSSAPI 機制

下列程序描述在 Solaris 平台上配置 Directory Server 以使用 GSSAPI 的所需步驟：

依 GSSAPI 識別對映所述建立 GSSAPI 的預設識別對映，以及任何自訂對映。

建立 keytab 以儲存服務金鑰，包括 LDAP 服務的金鑰。

確保 keytab 僅有 Directory Server 使用者可讀取。

建立與預設 /etc/krb5/krb5.keytab 不同的檔名。

設定 start-slapd 程序檔中的 KRB5_KTNAME 環境變數，以確保使用的是新的而不是預設的 keytab 。

如果修改了 SASL 配置項目或 GSSAPI 識別對映項目之一，請重新啟動 Directory Server。

請注意，主機電腦上必須已配置 DNS。

GSSAPI 識別對映

SASL 機制的識別對映會嘗試將 SASL 識別的憑證對應目錄中的使用者項目。如需此機制的完整描述，請參閱識別對映。如果對映找不到與 SASL 識別相對的 DN，驗證將會失敗。

SASL 識別是稱為 Principal 的字串，以每種機制特定的格式代表某使用者。在使用 GSSAPI 的 Kerberos 中，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

這個檔案中的另一個範例顯示當使用者 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 配置分支中的項目。所有必須執行識別對映的通訊協定在此分支內各有一個容器：

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，而自訂對映可擁有任何其他 RDN，只要使用 cn 作為命名屬性。所有自訂對映都會依非決定性順序優先評估，直到成功為止。如果所有自訂對映都失敗，最後才套用預設對映。如果預設對映也失敗，則用戶端的驗證失敗。

對映項目必須包含 top、Container 與 dsIdentityMapping 物件類別。然後項目可包含下列屬性：

dsMappedDN:DN - 為文字字串，定義目錄中的 DN。執行對映時，如果此 DN 存在，則會用於連結。萬一此 DN 不存在時，您也可以定義下列屬性執行搜尋。

dsSearchBaseDN:DN - 搜尋的 Base 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。

dsMatching-pattern 與 dsMatching-regexp 的比較是使用 Posix regexec(3C) 與 regcomp(3C) 函數呼叫。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 喜好設定一起儲存在檔案中，例如 .mozilla/username/string.slt/cert8.db。

如果您使用此程序，請找出 Mozilla 所建立的憑證資料庫並記住其路徑，以供您的用戶端應用程式使用。

使用 Mozilla 瀏覽找出為您要存取的 Directory Server 發行憑證的憑證授權單位網站。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 憑證。

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 與 prefix 指出使用者憑證與金鑰資料庫的位置。certutil 工具將提示使用者輸入金鑰資料庫的密碼。然後工具會以 PEM 編碼文字格式產生 PKCS #10 憑證要求。

將編碼的憑證要求儲存在檔案內，再依憑證授權單位指定的程序傳送到您的憑證授權單位。例如，您可能須以電子郵件傳送憑證要求，或者您可以透過 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 所述，配置 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 指令的範例

執行 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

依照安裝指示安裝 Kerberos V5。Sun 建議要安裝 Sun Enterprise Authentication Mechanism (SEAM) 1.0.1 用戶端軟體。

配置 Kerberos 軟體。若使用 SEAM，請配置 /etc/krb5 下的檔案，以便設定 kdc 伺服器，定義預設範圍，以及您的 Kerberos 系統所要求的其他任何配置工作。

如有必要，修改 /etc/gss/mech 檔案，使列示的第一個值是 kerberos_v5。

指定 Kerberos 驗證的 SASL 選項

使用啟用 GSSAPI 的用戶端應用程式之前，您必須用下列指令，以您的使用者 Principal 初始化 Kerberos 安全性系統：

kinit userPrincipal

userPrincipal 是您的 SASL 識別，例如 bjensen@EXAMPLE.COM。

指定使用 Kerberos 的 SASL 選項。

請注意，在 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 的話，authid 與 authzid 必須完全一樣，但不使用計劃供代理作業使用的 authzid。authid 的值是識別對映中所用的 Principal。Principal 必須為完整的 Principal，包括範圍。如需詳細資訊，請參閱 GSSAPI 識別對映。

使用 GSSAPI 與 SASL 配置 Kerberos 驗證：範例程序

為 Directory Server 配置 Kerberos 可能會很複雜。您首先應該參考 Kerberos 文件。

如需更多幫助，請使用下列範例程序以決定應遵循哪些步驟。但請注意，此程序為範例，您必須對其進行修改以適合您自己的配置及環境。

關於配置及使用 Solaris 中 Kerberos 的其他資訊，可以在作為 Solaris 文件集一部分的 Security Services System Administration Guide 中找到。您也可以查詢線上手冊。

假設

所有電腦 - 編輯 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 操作，並將第二台電腦配置為執行允許使用者透過 GSSAPI 執行 Kerberos 驗證之 Directory Server 的程序。

也可以在同一台電腦上執行 KDC 及 Directory Server。如果您選擇此做法，請使用相同程序，但在 Directory Server 電腦中，略過已對 KDC 電腦執行的所列出之步驟。

此程序對所使用的環境做了一些假設。它們在下面列出。使用範例程序時，適當地修改這些值以適合您的環境。

此系統會有全新安裝的 Solaris 9 作業環境，並安裝有最新的建議修補程式叢集。安裝最新的建議修補程式叢集是非常重要的，因為在某些情況下因未安裝適當的 Solaris 修補程式而導致 Directory Server 的 Kerberos 驗證失敗。也請注意，雖然大部分詳細文件記錄程序與 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 中的使用者將有 uid=username, ou=People,dc=example, dc=com 格式的 DN，而且對應的 Kerberos principal 的格式將為 username@EXAMPLE.COM。如果使用不同的命名模式，那麼應該使用一個不同的 GSSAPI 識別對映。

所有電腦 - 編輯 Kerberos 用戶端配置檔

/etc/krb5/krb5.conf 配置檔提供 Kerberos 用戶端與 KDC 通訊所需的資訊。

在 KDC 電腦、Directory Server 電腦以及任何將使用 Kerberos 對 Directory Server 進行驗證的用戶端電腦上編輯 /etc/krb5/krb5.conf 配置檔，如下所示：

以 "EXAMPLE.COM" 取代所有的 "___default_realm___"。

以 "kdc.example.com" 取代所有的 "___master_kdc___"。

因為只有一台 Kerberos 伺服器，所以請移除含有 "___slave_kdcs___" 的行。

以 ".example.com = EXAMPLE.COM" 取代 "___domain_mapping___" (請注意 .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 檔案配置檔中，以 "EXAMPLE.COM" 取代 "___default_realm___"。更新的/etc/krb5/kadm5.acl 檔案看起來應該像程式碼範例 11-3：

KDC 電腦 - 編輯 KDC 伺服器配置檔

編輯 /etc/krb5/kdc.conf 檔案，以 "EXAMPLE.COM" 取代 "___default_realm___"。

[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

使用下列指令建立具有 kws/admin@EXAMPLE.COM principal 的管理使用者及 admin 常駐程式所使用的服務金鑰。

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 及 admin 常駐程式。KDC 程序將以 /usr/lib/krb5/krb5kdc 的形式出現在程序清單中，admin 常駐程式將以 /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

使用下面一系列指令來為 KDC 及 Directory Server 電腦的 Kerberos 資料庫加入主機 Principal。主機 Principal 供某些諸如 klist 之類的 Kerberos 公用程式使用。

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 程序內定要求 ldap/fqdn@realm 的 Principal，其中 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

首先，根據 principal 建立檔案 /data/ds52p2/shared/bin/gssapi.ldif 以定義一個對映，該對映用於 Directory Server 識別正在驗證哪一個 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 資料庫中加入了測試使用者及 kerberos-test@EXAMPLE.COM principal。因為識別對映配置被加入目錄中，所以該使用者的對應目錄項目必須具有 uid=kerberos-test,ou=People,dc=example,dc=com 形式的 DN。

首先建立如下內容的 /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#

若要使用 ldapsearch 實際對 Directory Server 執行以 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#

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 管理指南