rfc1777.txt

很多RFC的中文文档

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：kenvin（kenvin9   [e-mail]）
译文发布时间：2001-3-30
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。


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 {