組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：kenvin（kenvin9   kenvinhuang@gtong.net）
譯文發布時間：2001-3-30
版權：本中文翻譯文檔版權歸中國互動出版網所有?？梢杂糜诜巧虡I用途自由轉載，但必須保留本文檔的翻譯及版權信息。


Network Working Group                                                 W. Yeong
Request for Comments: 1777                         Performance Systems International
Obsoletes: 1487                                                        T. Howes
Category: Standards Track                                     University of Michigan
                                                                       S. Kille
                                                             ISODE Consortium
                                                                   March 1995



RFC1777  輕量級目錄訪問協議
(RFC1777  Lightweight Directory Access Protocol)

本備忘錄狀態
   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

摘要
   在本文檔中描述的協議是設計來在不增加目錄訪問協議(DAP)的資源需求的情況下訪問X.500的目錄服務.本協議特別定位于那些能提供對X.500的目錄進行簡單的讀/寫交互的簡單的管理和瀏覽應用,同時它也是對DAP本身的一種補充.

  LDAP主要包括以下幾個方面:
    - 協議元素直接提供TCP或其他傳輸協議傳輸,而不管頂層的會晤和表示層.
    - 大多數的協議數據以一般的字符串進行編碼(如標識名)
    - 用一個輕量級的BER編碼來對所有協議元素進行編碼.







目錄
1.  歷史	3
2.  協議的模型	3
3.  映射到傳輸服務	3
3.1.  傳輸控制協議 (TCP)	3
3.2.  面向連接的傳輸服務 (COTS)	4
4.  協議的元素	4
4.1.  綁定操作	7
4.2.  放棄綁定操作	8
4.3.  查找操作.	8
4.4.  修改操作	10
4.5.  添加操作	11
4.6.  刪除操作	12
4.7.  修改RDN操作	12
4.8.  比較操作	13
4.9.  丟棄操作	13
5.  協議元素的編碼	14
6.  安全方面的考慮	14
7.  參考書目	14
8.  作者地址	15
附錄 A - 完整的 ASN.1 定義	16
1.  歷史
     在Internet上,對X.500技術的巨大興趣,使人們努力去減少在使用該技術時所需要花費的較高的"條目開銷",如目錄協助服務,DIXIE.盡管這些努力取得了成功,但他們所選用的是一些特殊的實現方法,因此具有有限的可應用性.本文檔也是在定義目錄協議的可選方法上進行,但跟以前不同的是,它有意識地避免對特殊實現的依賴.
2.  協議的模型
   本協議所采納的通用模型是一個客戶在一個服務器上進行協議操作.在這個模型中,一個客戶通過發送一個帶有描述需要在服務器上實施的操作的協議請求給服務器,接著服務器負責在目錄中實施所必須的操作.在完成必要的操作之后,服務器返回一個帶有結果或出錯信息的回應給請求服務的客戶.為了保證減少目錄使用所需開銷這個目標,盡量減少客戶的復雜性是本協議的一個目標,以推動利用目錄服務的應用的廣泛發布.

   要注意到的是,盡管只要回應已經在本協議中定義,服務器必須把該回應返回給客戶,但在客戶和服務器的實現上,并不需要同步他們的行為:服務器和客戶可以以任何順序來交換多個操作請求和回應的消息,只要最終客戶能對每個要求必須有一個回應的請求都接收到一個回應.
  
    考慮服務器代表客戶實施協議操作這種模型,也要注意到協議服務器同時要對處理結果進行篩選,而不依賴于客戶的篩選操作.本協議不把篩選結果返回給客戶,因為在這個模型中,一個服務器要保證在目錄上所有必需的操作,而只把最終結果或出錯信息返回給客戶.
    
   注意到本協議可以映射到目錄抽象服務的一個嚴格子集,因此它可以完全由DAP來提供.
3.  映射到傳輸服務
     本協議設計來運行在面向連接的,可靠的傳輸上,所傳輸的數據流的每一個字符的所有的8位都有意義.在這里定義了規定的兩種底層服務,盡管其他的服務也是可能的.
   3.1.  傳輸控制協議 (TCP)
       LDAP消息協議數據單元(LDAPMessage PDU)直接映射到TCP字節流.運行在TCP上的服務器實現應該提供一個在389端口上的監聽程序.
   3.2.  面向連接的傳輸服務 (COTS)
       連接建立后,并不需要使用特殊的T-連接.所有LDAP消息協議數據單元(LDAPMessage PDU)直接映射到T-數據上.
4.  協議的元素
     為了能進行協議數據的交換,所有的協議操作都封裝在一個通用信封中,LDAP消息(LDAPMessage)定義在下面:

     LDAPMessage ::=
         SEQUENCE {
              messageID      MessageID,
              protocolOp     CHOICE {
                                  bindRequest         BindRequest,
                                  bindResponse        BindResponse,
                                  unbindRequest       UnbindRequest,
                                  searchRequest       SearchRequest,
                                  searchResponse      SearchResponse,
                                  modifyRequest       ModifyRequest,
                                  modifyResponse      ModifyResponse,
                                  addRequest          AddRequest,
                                  addResponse         AddResponse,
                                  delRequest          DelRequest,
                                  delResponse         DelResponse,
                                  modifyRDNRequest    ModifyRDNRequest,
                                  modifyRDNResponse   ModifyRDNResponse,
                                  compareDNRequest    CompareRequest,
                                  compareDNResponse   CompareResponse,
                                  abandonRequest      AbandonRequest
                             }
         }

     MessageID ::= INTEGER (0 .. maxInt)

     LDAP消息(LDAPMessage)的功能是給所有的協議交換定義一個包含通用字段的信封.在現在,唯一的通用字段是一個消息標識符,該標識符需要一個與在本次LDAP會晤中發送出的其他請求不同的值.

     消息標識符必須包含在LDAPMessage信封中.該消息標識符最早是包含在客戶請求的LDAPMessage 中的.
  
   除了在上面定義的LDAPMessage ,在定義協議操作時,也使用下面這些定義.
        LDAPString ::= OCTET STRING

    LDAPString是一種符號上的方便表示,它表明盡管LDAPString 是一種用字符串類型來編碼的串,但實際上該串能使用的合法字符集由IA5字符集限定.
  
     LDAPDN ::= LDAPString
     RelativeLDAPDN ::= LDAPString

     一個LDAPDN 和一個RelativeLDAPDN被獨立地定義,分別代表一個標識名和一個相對標識名.用來命名地編碼符合[5]中的規范,也就是:

     <distinguished-name> ::= <name>
     <relative-distinguished-name> ::= <name-component>
    
      <name> 和<name-component> 在[5]定義.

     AttributeValueAssertion ::=
         SEQUENCE {
              attributeType       AttributeType,
              attributeValue      AttributeValue
         }

    AttributeValueAssertion 的類型定義與X.500目錄標準類似

     AttributeType ::= LDAPString
     AttributeValue ::= OCTET STRING

   一個AttributeType的值代表X.500標準中的AttributeType 的文本串值.例如,AttributeType 'organizationName' 與對象標識2.5.4.10在本協議中是通過字符串""organizationName"這個AttributeType來表示的.在協議實現中,如果遇到一個無法用文本字符串來賦值的AttributeType,那么就應該用該對象的對象標識符的ASCII 編碼串來賦給AttributeType.例如,如果在協議實現中無法把字符串"organizationName"賦給一個organizationName AttributeType,那么可以用ASCII 串"2.5.4.10"來代表該AttributeType.

   一個類型為AttributeValue 的域的值用目錄中的AttributeValue 類型的一個八位編碼串來表示. 同本文檔在下面定義的各種屬性的編碼對比,有不同目錄服務的AttributeValue類型的字符串編碼的定義.
 
     LDAPResult ::=
         SEQUENCE {
             resultCode    ENUMERATED {
                             success                      (0),
                             operationsError              (1),
                             protocolError                (2),
                             timeLimitExceeded            (3),
                             sizeLimitExceeded            (4),
                             compareFalse                 (5),
                             compareTrue                  (6),
                             authMethodNotSupported       (7),
                             strongAuthRequired           (8),
                             noSuchAttribute              (16),
                             undefinedAttributeType       (17),
                             inappropriateMatching        (18),
                             constraintViolation          (19),
                             attributeOrValueExists       (20),
                             invalidAttributeSyntax       (21),
                             noSuchObject                 (32),
                             aliasProblem                 (33),
                             invalidDNSyntax              (34),
                             isLeaf                       (35),
                             aliasDereferencingProblem    (36),
                             inappropriateAuthentication  (48),
                             invalidCredentials           (49),
                             insufficientAccessRights     (50),
                             busy                         (51),
                             unavailable                  (52),
                             unwillingToPerform           (53),
                             loopDetect                   (54),
                             namingViolation              (64),
                             objectClassViolation         (65),
                             notAllowedOnNonLeaf          (66),
                             notAllowedOnRDN              (67),
                             entryAlreadyExists           (68),
                             objectClassModsProhibited    (69),
                             other                        (80)
                           },
             matchedDN     LDAPDN,
             errorMessage  LDAPString
         }

   LDAPResult 是本協議中從服務器返回給客戶用以指明操作成功或失敗的結構.對不同的請求,服務器應該返回包含LDAPResult 結構中的不同域的回應給客戶,來指明協議操作請求的最終狀態.對服務器來說,這個結構中的errorMessage 域應該用來返回一個包含可讀文本的錯誤診斷的ASCII 串給客戶.由于這個錯誤診斷不是標準的,在實現中不應該依賴這些返回值.如果服務器不返回一個文本的錯誤診斷,LDAPResult 結構中的errorMessage 應該包含一個長度為零的字符串.
   
   對于noSuchObject, aliasProblem,invalidDNSyntax,isLeaf,及aliasDereferencingProblem這些resultCodes,相應的matchedDN域應該設為在DIT中最為匹配的條目,而且應該是所提供名字的簡短格式.或者,如果別名已被丟棄,應該返回結果名字.在其他情況下,matchedDN 域都應該設為NULL DN(也就是長度為零的字符串)


4.1.  綁定操作
   綁定操作的功能是在客戶和服務器之間初始化一個協議會晤,并允許服務器對客戶進行認證.在一個協議會晤中,綁定操作必須是服務器接收到的第一個操作請求.綁定請求定義如下:

     BindRequest ::=
         [APPLICATION 0] SEQUENCE {
                             version   INTEGER (1 .. 127),
                             name      LDAPDN,
                             authentication CHOICE {
                                  simple        [0] OCTET STRING,
                                  krbv42LDAP    [1] OCTET STRING,
                                  krbv42DSA     [2] OCTET STRING
                             }
         }
 
    綁定請求的參數是:

   - 版本:一個版本號指定本協議會晤中所使用協議的版本.本文檔描述的是LDAP版本2.注意,由于沒有版本選擇談判,客戶只須把這個參數設為它所希望的值.

   - 名稱:客戶希望綁定的目錄對象的名稱.這個域可以是空值(一個長度為零的字符串),用來表示匿名綁定.

   - 認證:如果有的話,綁定請求提供的用來認證該名稱的信息,"簡單"認證選項提供了一個最小的認證機制,在這個最小認證機制中,認證域只包含一個明文密碼.這個選項在不認證或匿名綁定時也可以使用,在這種情況下,該域包含一個長度為零的字符串.LDAP服務器上的版本4的Kerberos認證和DSA 認證分別通過使用"krbv42LDAP" 和 "krbv42DSA"認證選項來實現.注意在這里盡管他們是作為獨立的條目來引用,但并不需要把他們分開(也就是一個DSA可以直接同LDAP對話).
     為了支持所有的實現,兩種獨立的認證選項都提供了.對不同的服務,每個八為字節的串都應該包含一個相應的kerberos戳. (例如:從krb_mk_req()調用返回的值).
LDAP服務器上的認證的建議服務名稱是"ldapserver";DSA服務器上的認證的建議服務名稱是"x500dsa".  在兩種情況中,建議的服務實例名稱都為服務所在的主機的名稱.當然,實際的服務名稱和實例名稱依賴于本地kerberos主數據庫中的值.

      綁定操作需要如下定義的綁定回應:

     BindResponse ::= [APPLICATION 1] LDAPResult

   一個綁定回應只簡單地包含一個服務器在該客戶發出綁定請求后的協議會晤初始化狀態,
  
   在接收到一個綁定請求后,如果有必要,一個協議服務器要認證發出請求的客戶,并嘗試同該客戶建立協議會晤.接著,服務器返回一個指明會晤建立請求的狀態的綁定回應給 客戶.
4.2.  放棄綁定操作
      放棄綁定操作的功能是臨時終止一個協議會晤.放棄綁定操作定義如下:

     UnbindRequest ::= [APPLICATION 2] NULL

    沒有定義放棄綁定操作回應.在發送一個放棄綁定請求后,一個協議的客戶可以假設協議會晤已被終止.在收到一個放棄綁定請求后,一個協議服務器可以假設發送請求的客戶已終止該會晤,所有已收到的請求可以被丟棄.
4.3.  查找操作.
   查找操作允許客戶請求代表他的服務器進行一次查找.查找請求定義如下:

     SearchRequest ::=
         [APPLICATION 3] SEQUENCE {
             baseObject    LDAPDN,
             scope         ENUMERATED {
                                baseObject            (0),
                                singleLevel           (1),
                                wholeSubtree          (2)
                           },
             derefAliases  ENUMERATED {
                                        neverDerefAliases     (0),
                                        derefInSearching      (1),
                                        derefFindingBaseObj   (2),
                                        derefAlways           (3)
                                   },
             sizeLimit     INTEGER (0 .. maxInt),
             timeLimit     INTEGER (0 .. maxInt),
             attrsOnly     BOOLEAN,
             filter        Filter,
             attributes    SEQUENCE OF AttributeType
     }

     Filter ::=
         CHOICE {