rfc2829：LDAP 的身份驗證方法

組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：張海斌（netdebug internetdebug@elong.com ）
譯文發布時間：2001-12-14
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須保留本文檔的翻譯及版權信息。

Network Working Group
Request for Comments: 2829
Category: Standards Track

M. Wahl
Sun Microsystems, Inc.
H. Alvestrand
EDB Maxware
J. Hodges
Oblix, Inc.
R. Morgan
University of Washington
May 2000

備忘錄狀況

這份文檔為Internet社區指定為Internet標準（軌跡）協議，并且為進一步改進需要討論和建議。這份協議的標準化狀態和狀況請參閱"Internet官方協議標準（Internet Official Protocol Standards ）"(STD 1)的當前版。這份備忘錄的分發不受限制。

版權聲明

Copyright (C) The Internet Society (2000)。版權所有。

摘要

這篇文檔針對在LDAP [1]實現工具（implementations）中被需求和推薦的安全機制（security mechanisms）的特定結合。

0.譯者的話

譯者在翻譯這份文檔的時候，采取直譯的方式，盡量保證原文的原意。同時也盡量考慮了中文的語義順暢，便于中文讀者閱讀，譯者在譯文中加入了一些修飾語和譯注，修飾語一般在括號中寫明，而譯注均有“譯者注”字樣。由于譯者翻譯本篇文擋時間有限，譯文中一定會存在許多理解有誤、用詞不當之處，歡迎讀者來信指正，共同學習。

1. 引論

LDAP版本3是針對目錄（服務）功能強大的訪問協議。

它提供了搜索（searching）、獲取（fetching）和操作（manipulating）目錄內容的方法，以及豐富的安全函數集合的訪問方法。

為了Internet 運轉的更好，這些安全功能能夠很好的交互是至關重要的（vital）；因此應該存在一個對所有需求LDAPv3 一致性的工具（LDAPv3）通用的最小安全功能子集。

對LDAP目錄服務基本的威脅包括：

通過數據獲取（data-fetching）操作非特許存取數據，

通過監聽（monitoring）其他的訪問（通道）非特許存取可再用的客戶（身份）證明信息，

通過監聽其他的訪問（通道）非特許存取數據，

未經授權的數據修改，

未經授權的配置修改，

未經授權的或者過分的資源使用（拒絕服務），以及

目錄的電子欺騙：欺騙客戶（client）相信信息來自目錄（directory）而實際上沒有，或者在轉接中修改數據或者錯誤指引客戶的連接。

威脅(1), (4), (5)和(6)針對惡意的（hostile）客戶（clients）。威脅(2), (3)和(7)針對惡意的在客戶端和服務端（傳輸）路徑上的代理，或者冒充服務端。

LDAP協議組（protocol suite）能通過下面的安全機制得到保護：

客戶（身份）證明利用SASL [2]機制設置，或者依靠（backed by）TLS證明擴展機制，

客戶授權利用依靠于請求者證明的身份（標識）存取控制，

數據完整性保護（Data integrity）利用TLS協議或者數據完整（data-integrity）SASL機制，

避免窺探者（snooping）損害的保護利用TLS協議或者數據加密
（data-encrypting）SASL機制，

資源限制利用基于服務控制（service controls）的管理限制，以及

服務（身份）證明利用TLS協議或者SASL機制。

譯者注：SASL：Simple Authentication and Security Layer

同時，存取控制的強制（執行）（imposition）利用LDAP協議范圍以外的（機制）完成。

在本文中，術語"user"代表其是使用目錄獲取或者存儲信息的LDAP客戶的任何應用（application）。

在本文中的關鍵字"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",和"OPTIONAL"在RFC 2119 [3]中的描述來作解釋。

2. 樣例展開腳本（Example deployment scenarios）

下面的腳本是在Internet上針對LDAP目錄服務的典型的有不同安全需求的樣例。(在下面的樣例中，"sensitive"（敏感的）意味著數據如果暴露（revealed）將對擁有者帶來真正的損害；也有受保護的數據但不是敏感的)。這里不是為了列舉廣泛的綜合的腳本為目的，其他腳本是可能的，特別是在物理保護的網絡上。

只讀目錄（服務），不包含敏感數據，對任何人（"anyone"）訪問公開，并且TCP連接攔截或者IP欺騙不是問題。這個目錄不需要安全功能，除非管理服務的限制。

只讀目錄（服務）不包含敏感數據；讀訪問基于身份（標識）授權。TCP連接攔截在當前不是問題。這個腳本需要安全認證（authentication）功能。

只讀目錄（服務）不包含敏感數據；并且客戶（程序）需要確保目錄數據是經過服務（程序）驗證的和在從服務（程序）返回中沒有修改。

讀寫目錄（服務），不包含敏感數據；讀訪問對任何人（"anyone"）有效，更新訪問只針對適當授權的人。TCP連接攔截當前不是問題。這個腳本需要安全認證功能。

目錄包含敏感數據。這個腳本需要會話（session）秘密性保護和（AND）安全認證。

3. 認證和授權：定義和概念

這部分定義基本的術語，概念，和認證（authentication）、授權（authorization）、證明（credentials）及身份（標識）（identity）相關狀態（interrelationships）。這些概念被使用在描述客戶（程序）認證和授權中利用的多少種不同的安全進路（approaches）。

3.1. 存取控制策略Access Control Policy

存取控制策略是定義資源的保護、個人或者其他實體（entities）存取這些資源能力的術語通常規則。存取控制策略的公用表達式（common expression）是存取控制表（access control list）。安全的對象和機制，就像這里描述的那些能夠存取控制策略表達和實施（enforcement）。 存取控制策略是在下文描述的存取控制屬性術語的典型表示。

3.2. 存取控制因素Access Control Factors

一個請求，當被服務（程序）處理過的時候，可以和各種各樣的安全相關（security-related）因素關聯（參見[1]中部分4.2）。服務（程序）使用這些因素決定是否或者如何處理請求。這些被稱作存取控制因素（ACFs）。他們將包括源IP地址、加密強度（encryption strength）、被請求操作的類型、時間日期等等。一些因素可以針對請求自身所有，其他可以是通過請求被傳送的連接關聯、另一些（例如，時間日期）可以是環境（"environmental"）（相關的）。

存取控制策略是存取控制因素術語的表示。例如，請求有ACFs （存取控制因素）i,j,k 能夠執行在資源Z 上的Y操作。這套術語其服務（程序）使這樣的表達可用（available）是工具相關的（implementation-specific）。

3.3. 認證（Authentication）、證明（Credentials）、身份標識（Identity）

認證證明是通過一方提供給另一方的證據（evidence），斷言提供者一方（例如，一用戶）的身份標識，其試圖與另一方（典型為一服務器）建立關聯。認證是產生（generating）、傳遞（transmitting）和核實（verifying）這些證明的過程，這樣（它們）斷言了身份標識。認證身份標識是存在于證明中的名字（name）。

存在許多認證證明的形式——使用的形式依賴于通過雙方協商的特定認證機制。例如：X.509證書、Kerberos tickets、簡單身份標識和口令對（password pairs）。注意認證機制可以強制隨著它使用的認證身份標識的形式。

3.4. 授權身份標識（Authorization Identity）

授權身份標識是存取控制因素的一種。它是用戶或者其他實體的名字（name），其請求操作被執行。存取控制策略經常表達在授權身份標識術語中；例如，實體X能夠在資源Z上執行操作Y。

授權身份標識屬于一協會（bound to an association），其經常與通過客戶提出的認證身份標識完全地相同，但是它可以是不同的。SASL允許客戶具體指定在客戶證明中區別于認證身份標識的授權身份標識。這個許可主體（permits agents）正如使用它們自己的證明認證的代理服務器（proxy servers），然而（要求）賦予它們的代理[2]請求身份標識的存取特權（privileges）。另外，通過像TLS服務提供的認證身份標識的形式可以不相對于應用于明確的服務存取控制協議的授權身份標識，需要服務特指映射（server-specific mapping）被做。從客戶提供的認證證明中通過服務組成和生效的授權身份標識的方法是工具相關的（implementation-specific）。

4. 必須的安全機制

允許任何工具，面對上面的需求，在可以選擇的（安全機制）中選擇是不策略的（strategy），很可能導致互操作性問題是很明顯的。在缺少授權（mandates）的情況下，客戶（程序）將被記述（written）不支持任何服務（程序）支持的安全功能（function），或者更壞，僅僅支持類似明文口令的機制其提供明顯不夠的（inadequate）安全。

主動中間攻擊（Active intermediary attacks）對攻擊者的（攻擊）執行是很困難的，同時采用工具防止危害也是很困難的。在基于認識到（perceived）主動中間攻擊的危險下去避免主動中間攻擊的危害所付出的代價的情況下，采取方法（Methods）僅僅避免敵對客戶（hostile client）和被動監聽攻擊（passive eavesdropping attacks）所帶來的危害是有效的（useful）。

給定已存在的目錄，強烈要求看到獲得甄別名（Distinguished Name）的形式和能夠存儲在目錄中的認證數據的身份（標識）機制；這意味著或者這個數據為了虛假的認證是無用的（就像過去Unix使用的"/etc/passwd"文件格式），或者它的內容從來沒有通過無保護的線路中——也就是說它或者更新（updated）協議的外面（outside）或者僅在會話中更新以很好地避免了窺探者的危害。它也希望允許認證方法基于存在的用戶身份（標識）形式攜帶授權身份標識，目的為了與non-LDAP-based 認證服務向后兼容（backwards compatibility）。

因此，下列工具的一致性需求（conformance requirements）如下：

對于只讀、公開目錄、匿名認證在部分5中描述，能被使用。

工具提供基于口令（password-based）的認證訪問必須（MUST）支持使用DIGEST-MD5 SASL 機制[4]的認證，在部分6.1中描述。這提供了客戶避免被動監聽攻擊（passive eavesdropping attacks）的認證，但是沒有提供避免主動中間攻擊。

對于需要會話保護和認證的目錄，啟動TLS擴展操作[5]，和或者簡單認證選擇或者SASL EXTERNAL 機制，被一起使用。工具應該（SHOULD）支持在部分6.2中描述的口令認證，和應該（SHOULD）支持在部分7.1中描述的證書認證。同時，這些能提供完整性和傳輸數據的泄露保護，和客戶及服務的認證，包括避免主動中間攻擊。

如果TLS是被協商的，客戶（程序）必須（MUST）丟棄所有先前TLS協商中獲得的關于服務（程序）的信息。特別是，supportedSASLMechanisms 的值可以（MAY）在TLS已經協商之后不同（特別地，擴展（EXTERNAL）機制或者提出的明文（PLAIN）機制很可能僅在TLS協商執行之后被列舉出來）。

如果SASL安全層（security layer）被協商，客戶（程序）必須（MUST）丟棄所有先前SASL中獲得的關于服務（程序）的信息。特別是，如果客戶（程序）被配置為支持多（multiple）SASL機制，它應該（SHOULD）在SASL安全層被協商之前和之后獲得supportedSASLMechanisms并且驗證其值在SASL安全層協商之后沒有改變。這個探測從supportedSASLMechanisms列表中移去支持的SASL機制的主動攻擊，并且允許客戶確保它使用的由客戶和服務都支持的最好的機制（另外，這個應該（SHOULD）允許支持SASL機制列表的環境對客戶提供通過不同的信任源（trusted source），例如，數字簽名對象（digitally signed object）的一部分）。

5. 匿名認證

其修改實體或者存取受保護的屬性或實體通常需要客戶的認證。沒有打算執行任何這些操作的客戶典型的使用匿名認證。

LDAP工具必須（MUST）支持匿名認證，在部分5.1中定義。

LDAP工具可以（MAY）支持同TLS的匿名認證，在部分5.2中定義。

當可能（MAY）有存取控制限制（access control restrictions）阻礙目錄實體的存取時，LDAP服務應該（SHOULD）允許匿名綁定（anonymously-bound）的客戶檢索（retrieve）根（root）DSE的supportedSASLMechanisms屬性。

LDAP服務可以（MAY）使用關于客戶通過低層（lower layers）（網絡協議）或者擴展的授權（grant）或拒絕（deny）存取完全（控制）給匿名認證的客戶的其他信息。

5.1. 匿名認證過程

一LDAP客戶其還沒有成功完成在連接之上的綁定操作是匿名地認證。

一LDAP客戶也可以（MAY）具體通過使用簡單的認證選擇的零長度（zero-length）OCTET STRING 綁定需求中指定匿名認證。

5.2. 匿名認證和TLS

LDAP客戶（程序）可以（MAY）使用啟動TLS操作[5]去協商TLS安全的使用[6]。如果客戶還沒有預先綁定，那么直到客戶使用EXTERNAL SASL機制去協商客戶證書的識別（recognition），客戶是匿名地認證。

推薦的TLS密碼組在部分10中給出。

LDAP服務在TLS協商過程中要求客戶提供它們的證書，如果客戶還沒有一個有效證書時，可以（MAY）使用本地安全策略去決定是否成功地完成TLS協商。

6. 基于口令的認證

LDAP工具必須（MUST）支持使用文摘MD5（DIGEST-MD5）SASL機制（保護口令）的口令認證，在部分6.1中定義。

當使用TLS保護連接防止被監聽時，LDAP工具應該（SHOULD）支持"simple"口令選擇認證 ，在部分6.2中定義。

6.1. 文摘認證

LDAP客戶可以通過在根DSE之上執行搜索請求、請求supportedSASLMechanisms屬性、以及檢查是否字符串"DIGEST-MD5"作為值存在于這個屬性中來判定是否服務支持這個機制。

在認證的第一階段，當客戶正在執行在[4]部分2.1中定義的"initial authentication"（初始化認證）時，客戶發送請求綁定，其版本數字是3、認證選擇（authentication choice）是sasl、sasl機制名字是"DIGEST-MD5"、以及證明（credentials）不在場。客戶然后等待服務對這個請求做出的回答。

服務將以resultCode 是saslBindInProgress 、以及serverSaslCreds字段存在的綁定回答做出回答。這個字段的內容是在[4]部分2.1.1中定義的字符串。服務應該（SHOULD）包括域指示（MUST）和必須指明支持UTF-8。

客戶將發送有區別報文id（distinct message id）的綁定請求，其版本數字是3、認證選擇是sasl 、sasl機制名字是"DIGEST-MD5"，以及證明包含在[4]部分2.1.2中"digest-response" 定義的字符串。serv-type是"ldap"。

服務將回答其resultCode 或者是成功，或者是錯誤指示（error indication）的回答綁定。如果認證是成功的和服務不支持隨后的（subsequent）認證，那么證明字段中包含[4]部分2.1.3 中"response-auth"定義的字符串。在客戶和服務之間支持隨后的認證是可選的（OPTIONAL）。

6.2. TLS加密下的簡單認證選擇（"simple" authentication choice）

一個擁有包含用戶口令（userPassword）屬性的目錄實體可以（MAY）通過執行簡單口令綁定序列驗證到目錄，其隨著TLS密碼適配組（ciphersuite）提供的機密連接[6]的協商進行。

客戶將使用啟動TLS操作[5]去協商在連接到LDAP服務之上的TLS安全[6]的使用。客戶不需要事先已綁定到目錄。

對于這個認證過程的成功進行，客戶和服務必須（MUST）協商其包含大量適當強度的加密算法的密碼適配組。在部分10中描述推薦的密碼適配組。

隨著TLS協商的成功的完成，客戶必須（MUST）發送其版本數字是3、名字字段包含用戶的實體名字，和簡單（"simple"）認證選擇、包含口令的LDAP綁定的請求。

服務將對每一個在用戶的實體命名中的用戶口令（userPassword）屬性的值和客戶提出的口令按照大小寫敏感相等比較。如果比配，那么服務將發送resultCode 為成功的回答，否則服務將發送resultCode 為invalidCredentials 的回答。

6.3. 隨TLS的其它認證選擇

隨著TLS的協商，執行其沒有涉及明文可再用口令的交換的SASL認證也是可能的。在這種情況下，客戶和服務不需要協商其提供機密性的密碼適配組，如果僅當服務必需是數據完整性的。

7. 基于證書的認證（Certificate-based authentication）

LDAP工具應該（SHOULD）支持在TLS中通過客戶證書的認證，在部分7.1中定義。

7.1. 隨TLS基于證書的認證

一個擁有公/私密鑰對的用戶，其公鑰已經被證書認證中心（Certification Authority）簽發，可以使用這個密鑰對驗證到目錄服務，如果用戶的證書被服務需求。用戶的證書的主題字段應該（SHOULD）是用戶的目錄實體的名字，并且證書認證中心必須被目錄服務充分信任以便（目錄）服務能夠處理被簽發的證書（譯者注：目錄服務通過證書認證中心驗證證書的有效性）。關于服務（驗證）有效證書路徑的方法不在本文檔討論范圍之內。

服務可以（MAY）支持其主題字段名不同于用戶的目錄實體名的證書映射。支持名字映射的服務必須（MUST）有能力被配置為支持無映射證書。

在連接LDAP服務之上的客戶將使用啟動TLS操作[5]去協商TLS安全的使用。在這之前客戶不需要已經綁定到目錄。

在TLS協商中，服務必須（MUST）請求證書。客戶將提供它的證書給服務，并且必須（MUST）執行與提供證書相關的私有密鑰的加密。

作為（上述身份驗證的）展開將需求在傳輸中敏感數據的保護，客戶和服務必須協商其包含大量適當強度的加密算法的密碼適配組。推薦的密碼適配組在部分10中給出。

服務必須（MUST）驗證客戶的證書是有效的。服務將通常檢查證書是被已知的CA簽發的，以及在客戶的證書鏈中沒有哪個證書是無效的（invalid）和被撤銷（revoked）。服務做這些檢查存在幾個過程。

隨著TLS協商的成功完成，客戶將發送SASL "EXTERNAL"機制的LDAP綁定請求。

8. 其他機制

LDAP簡單（"simple"）認證選擇不適合沒有網絡或者傳輸層機密性（安全）的Internet認證。

當LDAP包括本機匿名（native anonymous）和明文認證機制，"ANONYMOUS"和 "PLAIN" SASL機制不能同LDAP使用。如果不同于DN的形式的授權標識被客戶需求，在傳輸中保護口令的機制應該（SHOULD）被使用。

在本文檔中下列基于SASL（SASL-based）的機制沒有被考慮：

KERBEROS_V4, GSSAPI 和 SKEY.

擴展（"EXTERNAL"）SASL機制能夠通過低層（lower layer）安全證明交換的使用用于請求LDAP服務。如果TLS會話在制造（making）SASL擴展綁定（SASL EXTERNAL Bind）請求之前還沒有在客戶和服務之間建立以及沒有其他外部認證證明源（例如，IP-level security [8]），或者如果TLS會話建立處理期間，服務沒有請求客戶的認證證明，那么SASL擴展綁定必須（MUST）以inappropriateAuthentication結果碼失敗。任何客戶的認證和LDAP關聯的授權狀態將丟失，所以LDAP關聯在失敗之后是在匿名狀態。

9. 授權標識

授權標識作為在LDAP綁定請求和回答中SASL證明字段的一部分被攜帶。

當擴展（"EXTERNAL"）機制被協商時，如果證明字段存在，它包含的authzId形式的授權標識在下面描述。

其他機制定義在證明字段中的授權標識的單元（location）。

授權標識是一個UTF-8字符集的字符串，相當于下面的ABNF [7]：

; 特有的預先定義授權（Specific predefined authorization）(authz) id模式定義
; 如下——新的模式在將來可能被定義。

authzId = dnAuthzId / uAuthzId

; distinguished-name-based authz id.
dnAuthzId = "dn:" dn
dn = utf8string ; 句法在RFC 2253中定義

; unspecified userid, UTF-8 encoded.
uAuthzId = "u:" userid
userid = utf8string ; 非特指的句法（syntax unspecified）

utf8string被定義為一個或者多個ISO 10646字符的UTF-8編碼。

所有支持認真證明存儲的服務，例如口令或者證書，在目錄中必須（MUST）支持dnAuthzId 選擇。

uAuthzId選擇允許兼容客戶應用程序希望認證本地目錄，但是不知道它們自己的甄別名（Distinguished Name）或者有一個目錄實體。字符串的格式被定義僅作為UTF-8編碼的ISO 10646字符集的序列，進一步的解釋需要在客戶和服務之間優先協定的。

例如，userid（用戶ID）能標識目錄服務的明確的用戶，或者是一個登錄名或者RFC 822電子郵件地址的local-part。通常uAuthzId必須不能（MUST NOT）被假定為全局唯一。

附加的授權標識方案可以（MAY）定義在本文檔的將來版本中。

10. TLS 密碼適配組

下面定義在[6]中的密碼適配組一定不能（MUST NOT）用于口令或者數據的機密性保護:

TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA

下面定義在[6]中的密碼適配組能被輕易破解（在1997年標準CPU上少于一周的CPU（計算）時間）。客戶和服務應該（SHOULD）在使用這些密碼適配組保護的口令或者數據的值之前小心考慮：

TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA

下面的密碼適配組易受手動之間攻擊（man-in-the-middle attacks）,而且不應該（SHOULD NOT）用于保護口令或者敏感數據，除非網絡配置上對這樣的手動中間攻擊的危險是可容忍的：

TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

支持TLS的客戶或者服務必須（MUST）至少支持TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA。

11. 對于LDAP的SASL服務名字

對于SASL[2]的使用，協議必須制定各種不同SASL機制使用的服務名字，例如GSSAPI。對于LDAP，服務名字是"ldap"，其已經在IANA注冊作為GSSAPI服務名字。

12. 安全考慮

安全問題在這份備忘錄（memo）中全篇被討論；結論（令人驚奇的）是強制（mandatory）安全是重要的，并且當窺探是一個問題的時候會話加密是需要的。

服務（程序）被促進去防止被匿名用戶修改。服務（程序）也可以通過超時無效連接希望最小化服務否定攻擊，并且返回unwillingToPerform 結果代碼而不執行被未授權客戶（程序）請求的昂貴計算操作。

在客戶（程序）還沒有執行啟動TLS操作或者為連接完整性和加密服務協商一套SASL機制之上的連接是在傳輸中手動之間攻擊（man-in-the-middle attacks）查看和修改信息方面的主題。

相關于協商TLS擴展（EXTERNAL）機制的安全考慮能在[2]，[5]和[6]中找到。

13. 確認

這篇文檔是IETF的LDAPEXT Working Group 的產物。其成員的貢獻是非常值得欣賞的。

14. 文獻

Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.

Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.

Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, May 2000.

Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.

Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

15. 作者的地址

Mark Wahl
Sun Microsystems, Inc.
8911 Capital of Texas Hwy #4140
Austin TX 78759
USA
EMail: M.Wahl@innosoft.com

Harald Tveit Alvestrand
EDB Maxware
Pirsenteret
N-7462 Trondheim, Norway
Phone: +47 73 54 57 97
EMail: Harald@Alvestrand.no

Jeff Hodges
Oblix, Inc.
18922 Forge Drive
Cupertino, CA 95014
USA
Phone: +1-408-861-6656
EMail: JHodges@oblix.com

RL "Bob" Morgan
Computing and Communications
University of Washington
Seattle, WA 98105
USA
Phone: +1-206-221-3307
EMail: rlmorgan@washington.edu

類別：Ldap?查看評論

總結

以上是生活随笔為你收集整理的LDAP身份验证的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。