LDAP协议

网站建设1490 更新时间：2025-06-08 05:02:52

2023年6月21日发(作者：)

LDAP协议LDAP协议⽬录前⾔ (3)第⼀章起源与影响 (3)1.1 起源 (3)1.2 影响 (4)第⼆章协议概况 (4)2.1 LDAP协议模型 (4)2.2 数据模型 (5)第三章⽬录结构 (7)3.1 基准DN (7)3.2 在⽬录树中组织数据 (8)3.3 数据结构 (9)第四章操作 (9)4.1 添加 (10)4.2 绑定（认证） (10)4.3 删除 (11)4.4 查询⽐较 (11)4.5 修改 (11)4.6 StartTLS (12)4.7 Unbind (12)第五章LDAP URLs (13)第六章模式 (13)6.1 模式概述 (13)6.2 模式扩展 (14)6.3 不同⽬录服务器对扩展模式的⽀持 (16)第七章变化 (16)第⼋章RFC 2254 (16)8.1 LDAP搜索过滤器定义 (16)8.2 字符串搜索过滤器定义 (17)8.3 举例 (19)8.4 安全注意事项 (20)第九章连接⽬录服务器（java） (20)9.1 ⽬录服务器建⽴连接 (20)9.2 获取⽬录服务器指定条⽬的属性值 (21)总结 (23)LDAP协议前⾔现在LDAP技术不仅发展得很快⽽且也是激动⼈⼼的。在企业范围内实现LDAP可以让运⾏在⼏乎所有计算机平台上的所有的应⽤程序从LDAP⽬录中获取信息。LDAP⽬录中可以存储各种类型的数据：电⼦邮件地址、邮件路由信息、⼈⼒资源数据、公⽤密匙、联系⼈列表，等等。通过把LDAP⽬录作为系统集成中的⼀个重要环节，可以简化员⼯在企业内部查询信息的步骤，甚⾄连主要的数据源都可以放在任何地⽅。如果Oracle、Sybase、Informix或Microsoft SQL数据库中已经存储了类似的数据，那么LDAP 和这些数据库到底有什么不同呢？是什么让它更具优势？请继续读下去吧！第⼀章起源与影响1.1 起源1.1.1 X.500的出现LDAP（Light-weight Directory Access Protocol）是在国际电报电话咨询委员会（CCITT）和国际标准化组织（ISO）联合开发的许多标准的基础上建⽴的。CCITT现在称为国际电信联盟（ITU）。ITU和ISO的⽬标是定义⼀个通⽤的⽬录标准，尽可能包括最⼴泛的⽬录服务。所开发的标准将构成⾯向CCITT和ITU开发的开放系统互连（OSI）⽹络模型的⽬录服务。最终的标准X.500是⼀个既复杂⼜全⾯的标准，很难实施，⽽且成本⾼昂，需要运⾏复杂的OSI⽹络协议。该标准旨在拥有⼀个分布全球的⽬录，并且带有标准访问接⼝。X.500⽬录标准极其复杂。作为其设计操作平台的OSI⽹络协议也⽐现在通常使⽤的传输控制协议，Internet 协议（TCP/IP）套件复杂得多。1.1.2 到LDAP的过渡X.500接受和实施的主要问题是其过于复杂，并且实施和管理相关成本⾮常⾼。为了提⾼X.500⽬录的可接受性，Internet⼯程任务组（IETF）决定定义新的访问协议。该协议更简单，不依赖于OSI堆栈，⽽使⽤TCP/IP堆栈。这产⽣了两个新协议：⽬录辅助服务（Directory Assistance Service，DAS）和有效实施X.500的⽬录接⼝（Directory Interface to X.500 ImplementedEfficiently，DIXIE）。LDAP旨在作为访问X.500⽬录的轻型⽅法。然⽽，随着时间的推移，情况越来越明显，对X.500 ⽬录服务器的访问⼤部分是通过LDAP协议进⾏的。当这⼀情况变得清晰时，⽬录服务器只能通过LDAP访问被设计和实施。这些服务器不再有X.500⽬录服务器中的复杂性，其实施和管理费⽤也更低。LDAP服务器还拥有⽐X.500⽬录服务器更出⾊的性能。LDAP的当前版本是LDAP v3。LDAP v1没有作为标准发布。LDAP v2于1995年3⽉公布，并在三个RFC中进⾏了定义：RFC1777、RFC 1778和RFC 1779。LDAP v2在RFC 3494中停⽌作为标准使⽤。现在⽀持扩展操作和控制，使LDAP v3能够在不改变标准协议的情况下进⾏扩展。 LDAP v3可向后兼容LDAP v2。LDAP v3服务器的⼀个要求是LDAP v2客户端要能够与之连接。LDAP v3作为操作系统、⽹络操作系统、⽬录服务、应⽤程序（⽐如：电⼦邮件服务器）和客户端应⽤程序的组成部分⽽得到⼴泛实施。1.2 影响1.2.1 LDAP协议的作⽤由于LDAP所具有的查询效率⾼、树状的信息管理模式、分布式的部署框架以及灵活⽽细腻的访问控制，使LDAP⼴泛地应⽤于基础性、关键性信息的管理，如⽤户信息、⽹络资源信息等。LDAP的应⽤主要涉及⼏种类型。信息安全类：数字证书管理、授权管理、单点登录；科学计算类：DCE (Distributed Computing Envirionment，分布式计算环境)、UDDI （UniversalDescription，Discovery and Integration, 统⼀描述、发现和集成协议）；⽹络资源管理类：MAIL系统、DNS系统、⽹络⽤户管理、电话号码簿；电⼦政务资源管理类：内⽹组织信息服务、电⼦政务⽬录体系、⼈⼝基础库、法⼈基础库。1.2.2 LDAP协议的应⽤⽬前，LDAP已应⽤在北京⼤学校园⽹络⽤户管理系统、Novell的eProvision应⽤解决⽅案、上海公务⽹统⼀⽤户管理、中国数字图书馆系统的⽤户管理部分，以及北京、上海、天津、福建等省级CA等。第⼆章协议概况2.1 LDAP协议模型LDAP协议采⽤客户机/服务器模型。客户机构造⼀个LDAP协议请求，LDAP服务器必须分配⼀个端⼝来监听客户端请求，通过TCP/IP传递给LDAP服务器，在服务器执⾏完请求的操作后，把包含结果或者错误信息的相应回传给客户机。LDAP协议请求的PDU是⼀个LDAPMessage结构，响应的PDU是⼀个LDAPResult结构。LDAP的PDU都直接映射到TCP的字节流在⽹上传输。LDAP客户和LDAP服务器的⼀般交互过程如下：图2－1 LDAP 会话1）客户端与LDAP服务器建⽴连接，要求客户端指定服务器的主机名或IP地址和伺服端⼝号。服务器将返回⼀个连接句柄，它指向了这次连接的所有信息。2）客户端与服务器建⽴⼀个会话（session），称为绑定。客户端提供⽤户名和⼝令进⾏认证，也可以建⽴⼀个具有缺省访问权限的匿名会话，还可以建⽴⼀个使⽤加密的安全会话。3）客户端发送操作请求，服务器执⾏操作。4）客户端结束所有请求后，关闭和服务器的会话，称为解除绑定。5）断开与服务器的连接。LDAP客户端的请求可以是同步的，也可以是异步的。在LDAPMessage结构中的messgeID整型变量唯⼀的标识⼀个请求，因此服务器通过messageID可以识别客户机发出的请求并正确返回该请求的响应，这是异步操作实现的原理。2.2 数据模型2.2.1条⽬的构成⽬录中存放数据的基本单位是条⽬。条⽬代表了真实世界中的对象，例如⼈、服务器、组织等等，是具有区别名DN（Distinguished Name）的属性（Attribute）集合，每个属性由⼀个类型（Type）和多个值（Values）构成，条⽬的逻辑结构如图2－2所⽰图2－2 条⽬的逻辑结构类型通常是容易记忆的名称，⽐如“cn”是通⽤名称（common name），或者“mail”是电⼦邮件地址。条⽬的值的语法取决于属性类型。⽐如，cn属性可能具有⼀个值“Jia Chen”。⼀个mail属性可能包含值“iris@/doc/ ”。⼀个jpegphoto属性可能包含⼀幅JPEG（⼆进制）格式的图⽚。另外，LDAP通过使⽤⼀个特殊的，叫做objectClass的属性来允许您控制哪⼀个属性必须出现或者允许出现在⼀个条⽬中。objectClass属性的值决定了该条⽬必须遵守的模式规则。⼀般来说，⼤多数属性的取值对于服务器并⽆意义，⽽由客户去解释和使⽤，但有⼀类属性叫操作属性（OperationalAttribute），它们往往由服务器⾃动⽣产和修改，⽤户⽆法修改。2.2.2 DIT的组织和命名在LDAP中所有的条⽬以⽬录信息树（Directory Information Tree,DIT）组织。图2-3表⽰了了⼀个⽬录树，它由位于不同层次的节点组成。LDAP不允许悬挂条⽬（即没有⽗节点的条⽬）存在于DIT中。在创建⼀个DIT之前，必须先定义根节点，即基准DN,也称为DSE(DSA-specific Entry ⽬录服务代理条⽬)，它描述了LDAP服务器⾃⾝的信息。⽬录对象必须有名字以便⽆歧义的由客户端引⽤或识别，相对区别名RDN和可区别名DN是两种识别⽬录对象的主要⽅法。图2－3RDN由⼀个称为命名属性的项⽬属性构成，它在⽗节点下的⼦树范围内唯⼀的识别每⼀个项⽬。每⼀个对象类都定义了⼀组属性充当命名属性，但在⼀个对象类的任何实例中只能由⼀个命名属性。要在整个⽬录层次中唯⼀的识别⼀个⽬录对象，就必须使⽤DN。每⼀个LDAP记录项的DN是由两个部分组成的：相对DN（RDN）和记录在LDAP⽬录中的位置。RDN是DN 中与⽬录树的结构⽆关的部分。可以看出，DN的定义是递归的，⽬录对象的DN就是其RDN与⽬录对象所在⽗条⽬DN的简单连接。第三章⽬录结构LDAP⽬录以树状的层次结构来存储数据。如果你对⾃顶向下的DNS树或UNIX⽂件的⽬录树⽐较熟悉，也就很容易掌握LDAP⽬录树这个概念了。就象DNS的主机名那样，LDAP⽬录记录的标识名（Distinguished Name，简称DN）是⽤来读取单个记录，以及回溯到树的顶部。每⼀个DN都是唯⼀的。3.1 基准DNLDAP⽬录树的最顶部就是根，也就是所谓的“基准DN"。基准DN通常使⽤下⾯列出的三种格式之⼀。假定我在名为FooBar的电⼦商务公司⼯作，这家公司在Internet上的名字是/doc/ 。o="FooBar, Inc.", c=US在这个例⼦中，o=FooBar, Inc. 表⽰组织名，在这⾥就是公司名的同义词。c=US 表⽰公司的总部在美国。以前，⼀般都⽤这种⽅式来表⽰基准DN。但是事物总是在不断变化的，现在所有的公司都已经（或计划）上Internet上。随着Internet的全球化，在基准DN中使⽤国家代码很容易让⼈产⽣混淆。现在，X.500格式发展成下⾯列出的两种格式。o=/doc/（⽤公司的Internet地址表⽰的基准DN）这种格式很直观，⽤公司的域名作为基准DN。这也是现在最常⽤的格式。dc=foobar, dc=com（⽤DNS域名的不同部分组成的基准DN）就象上⾯那⼀种格式，这种格式也是以DNS域名为基础的，但是上⾯那种格式不改变域名（也就更易读），⽽这种格式把域名：/doc/ 分成两部分dc=foobar, dc=com。在理论上，这种格式可能会更灵活⼀点，但是对于最终⽤户来说也更难记忆⼀点。3.2 在⽬录树中组织数据因为LDAP⽬录可以定制成存储任何⽂本或⼆进制数据，到底存什么要由你⾃⼰决定。LDAP⽬录⽤对象类型（objectclasses）的概念来定义运⾏哪⼀类的对象使⽤什么属性。在⼏乎所有的LDAP服务器中，你都要根据⾃⼰的需要扩展基本的LDAP⽬录的功能，创建新的对象类型或者扩展现存的对象类型。LDAP⽬录以⼀系列“属性对”的形式来存储记录项，每⼀个记录项包括属性类型和属性值（这与关系型数据库⽤⾏和列来存取数据有根本的不同）属性的值在保存的时候是保留⼤⼩写的，但是在默认情况下搜索的时候是不区分⼤⼩写的。某些特殊的属性（例如，password）在搜索的时候需要区分⼤⼩写。dn: cn=Oatmeal Deluxe, ou=recipes, dc=foobar, dc=comcn: Instant Oatmeal DeluxerecipeCuisine: breakfastrecipeIngredient: 1 packet instant oatmealrecipeIngredient: 1 cup waterrecipeIngredient: 1 pinch saltrecipeIngredient: 1 tsp brown sugarrecipeIngredient: 1/4 apple, any type请注意上⾯每⼀种配料都作为属性recipeIngredient值。LDAP⽬录被设计成象上⾯那样为⼀个属性保存多个值的，⽽不是在每⼀个属性的后⾯⽤逗号把⼀系列值分开。因为⽤这样的⽅式存储数据，所以数据库就有很⼤的灵活性，不必为加⼊⼀些新的数据就重新创建表和索引。更重要的是，LDAP⽬录不必花费内存或硬盘空间处理“空”域，也就是说，实际上不使⽤可选择的域也不会花费你任何资源。3.3 数据结构在⽬录基本DN 的下⾯是容器或组织单元（OU），它们从逻辑上对您的数据进⾏分隔或分组。还要紧记⼀点，您将结构容器嵌套得越深，它返回查询所⽤的时间就越长。图3-1第四章操作LDAP是⼀种消息协议，请求和相关的应答都带有相同的message ID。它定义了⼏种消息Add - 添加Bind (authentication) - 绑定(认证）Delete - 删除Search and Compare - 查询⽐较Modify - 修改StartTLS –扩展的TLS协商通知消息Unbind –客户端通知服务器结束会话(不是bind的反向操作)4.1 添加添加是向⽬录服务数据库添加⼀个新的条⽬。如果在添加请求中的可分辨名称已经存在于⽬录中，则服务器将不添加重复的条⽬，但在添加结果中将设置结果代码为⼗进制的“条⽬已经存在”。LDAP兼容服务器当试图定位条⽬时将永远不会取消在添加请求中传送的可分辨名称，所以可分辨名称从未有别名。LDAP兼容的服务器将确保可分辨名称并且所有属性符合命名标准。要添加的条⽬必须不存在，但直接上级必须存在。dn: uid=user,ou=people,dc=example,dc=comchangetype: addobjectClass: topobjectClass: personuid: usersn: last-namecn: common-nameuserPassword: password在上⾯的例⼦中，uid=user,ou=people,dc=example,dc=com必须不存在，ou=people,dc=example,dc=com必须存在。4.2 绑定（认证）当创建⼀个LDAP会话，也就是说，当⼀个LDAP客户端连接到服务器，⾝份验证会话的状态设置为“匿名”。 BIND操作为会话建⽴⼀个认证状态。简单绑定和SASL PLAIN可以以明⽂的⽅式发送⽤户的DN和密码，所以利⽤简单或SASLPLAIN的连接应使⽤传输层安全（TLS）进⾏加密。服务器在指定的条⽬通常对userPassword属性检查密码。匿名BIND（空DN和密码）重置到匿名状态的连接。SASL（简单认证和安全层）通过⼴泛的机制提供认证服务，如Kerberos或⽤TLS 发送客户端证书。BIND还设置了LDAP协议的版本。这个版本是⼀个整数，虽然协议中的标准的⽀持整数1到127（含）之间，但⽬前必须是2或3。如果客户端请求的是服务器不⽀持的版本，服务器必须在BIND中设置结果代码去回应错误协议的代码。通常情况下客户端必须使⽤LDAPv3,它在协议中是默认的，但它不总是在LDAP库中。BIND在LDAPv2的会话中是第⼀个操作，但在LDAPv3中不是必须的（当前LDAP版本）。在LDAPv3中，每个成功的BIND需要改变会话的认证状态，每个不成功的BIND 需要重置会话的认证状态。4.3 删除要删除⼀个条⽬，LDAP客户端需要发送正确格式的请求到服务器。删除请求必须包含要删除的条⽬的可分辨名称请求控件也可以连接到删除请求当处理⼀个删除请求时服务器不引⽤别名只有叶⼦节点(条⽬没有下属)可能通过删除请求被删除4.4 查询⽐较baseObject 基本对象–从⽬录树的何处开始查找，在DN (Distinguished Name) 处定义。scope 范围–查找层数：baseObject (如果baseObject所指的DN为某⼀个对象条⽬，则查找⼀个对象), singleLevel ⼀级(查找基本对象所指DN的成员), 全部⼦树(查找基本对象所指DN 及⼦树的所有成员)。filter 过滤器–怎样核查每个条⽬. ⽐如过滤器。(&(objectClass=person)(|(givenName=guoqing)(mail=*guoqing*))) –查找名字为guoqing或emai地址包含guoqing的⼈。derefAliases 废弃参照别名–是否/怎样跟从别名条⽬。attributes 属性–查找返回结果的哪些属性。sizeLimit, timeLimit –最⼤返回条⽬数限制, 最⼤允许的查找时间。typesOnly –只返回属性类型。4.5 修改修改操作使⽤LDAP服务器进⾏更改现有条⽬。不能尝试修改不存在的项⽬。修改请求是由服务器来实现访问控制的。修改操作要求指定可分辨名称（DN）的条⽬和序列的变化。序列中的每⼀个变化必须是下列之⼀：添加（添加⼀个新的值，必须不中已存在的条⽬）删除（删除现有值）更换（⽤新的值替换现有值）添加到属性值的LDIF的例⼦：dn: dc=example,dc=comchangetype: modifyadd: cncn: the-new-cn-value-to-be-added要替换现有属性的值，可以使⽤关键字替换。如果该属性是多值，客户端必须指定要删除的属性的值。要从条⽬中删除⼀个属性，可以使⽤关键字删除和更改类型指⽰符修改。如果该属性是多值，客户端必须指定要删除的属性的值。4.6 StartTLS –扩展的TLS协商通知消息STARTTLS操作在连接上建⽴传输层安全（SSL）。它可以提供数据的保密性（保护数据不被第三⽅观察）和/或数据的完整性保护（保护数据不被篡改）。在TLS协商的服务器发送X.509证书，以证明其⾝份。客户也可以发送⼀个证书，以证明其⾝份。这样做之后，客户端可以使⽤SASL /外部。通过使⽤SASL /外部客户端请求的服务器获得它的⾝份，在⼀个较低的⽔平（如TLS）提供凭据。尽管技术上服务器可能在任何低⽔平使⽤任何⾝份信息建⽴,但通常服务器将通过TLS建⽴⾝份信息。服务器在⼀个单独的端⼝上也常常⽀持⾮标准的“LDAPS”协议（“安全LDAP”，俗称“通过SSL的LDAP”），默认情况下端⼝为636。LDAPS与LDAP之间有两个不同点：1）在连接上，客户端和服务器在任何LDAP信息被传递之前建⽴TLS ；2）LDAPS连接必须在TLS关闭后关闭。应该指出的是,⼀些“ldap”客户端库只加密通信,他们不针对提供的证书上的名字检查主机名。LDAPS与LDAPv2⼀起使⽤，因为StartTLS操作尚未定义。使⽤LDAPS 已过时，现代软件应该只使⽤STARTTLS。4.7 Unbind客户端通知服务器结束会话(不是bind的反向操作),客户端可以通过简单地关闭连接中⽌会话，但他们应该解除绑定。取消绑定允许服务器正常关闭连接和免费资源，否则它会保持⼀段时间，直到发现客户已经放弃了连接。它还指⽰服务器可以取消能取消的操作，并且发送响应的操作不能被取消。第五章LDAP URLsLDAP URL格式在不同程度上⽀持客户端的时候存在，并且在转介和继续引⽤上返回到服务器（参见RFC 4516）：ldap://host:port/DN?attributes?scope?filter?extensions下⾯描述的⼤多数组件都是可选的。主机是⽤来搜索LDAP服务器的FQDN或IP地址的。端⼝是LDAP服务器的⽹络端⼝（默认端⼝389）。DN是⽤作搜索基本的可分辨名称的。属性是检索以逗号分隔的属性列表的。范围指定搜索范围，可以是“base”（默认值），“one”或“sub”。过滤器是⼀个搜索过滤器。例如在RFC 4515中定义的(objectClass=*)。扩展是LDAP URL格式的扩展。例如，"ldap:///doc/ /cn=John%20Doe,dc=example,dc=com"，是指在John Doe的条⽬/doc/ 中所有的⽤户属性，⽽"ldap:///dc=example,dc=com??sub?(givenName=John)"在默认的服务器中搜索条⽬（注意三个斜杠，省略了主机，双问号和属性）。⾄于其他的URL，特殊字符必须编码。⼀个类似的⾮标准的LDAP：通过SSL的LDAP URL⽅案。它不应该被混同于LDAP和 TLS，它是通过使⽤标准的LDAP模式和STARTTLS操作来实现的。第六章模式6.1 模式概述LDAP中关于属性、对象类⽂法和匹配规则等的规定构成所谓schema。模式信息在⽬录中通过objectclass为subschema的条⽬来表⽰，通常在DIT中占据⼀个独⽴的分⽀，可以对模式信息进⾏同其他⽬录对象⼀样的搜索操作。在LDAP中，schema居于核⼼地位，模式管理和扩展也是最复杂和具有挑战性的⼯作。Openldap随软件发布了⼀组模式定义，要使⽤任何⼀个模式⽂件，只需在⽂件中的全局定义部分包含所需要的⽂件。如：include/usr/local/etc/openldap/schema/6.2 模式扩展在实际应⽤中，需要设计⽬录模式描述将要存储在⽬录中的数据类型。如果有的数据⽆法⽤服务器⽀持的标准模式来表⽰，这就需要对模式进⾏扩展和⾃定义。下⾯是定义⼀个新的模式的4个步骤：获取和分配对象标识符；命名属性类型和对象类；创建本地模式⽂件；定义对象类和属性类型；获取和分配对象标识符。每个LDAP对象类和属性必须分配⼀个唯⼀的名字和对象标识符。在⾃定义模式时，每个公司或组织需要⼀个唯⼀的OID,⼀个OID可以满⾜所有的模式需要，因为可以通过创建新的分⽀来满⾜所有的OID需要。获取和分配对象标识符的过程如下：从IANA为⾃⼰的组织申请OID;创建⼀个登记表来维护对此OID的分配；为模式元素提供OID创建分⽀。例如某组织被赋予⼀个OID1.1，可以按照如下所⽰的⽅法扩展树：1）命名属性类型和对象类为模式元素分配⼀个唯⼀的OID之外，还应该为每个模式元素提供⼀个具有描述性的名字，⾃定义模式元素的名字不能和标准模式元素冲突，解决办法是为每个⾃定义的模式元素添加前缀。在RFC2377中有关于模式元素命名⽅案的详细信息。2）创建本地模式⽂件虽然在配置⽂件指令中的objectClass和attributeTypes可以被⽤来定义⽬录中的模式规则，但实际应⽤中创建⼀个⽂件来包含对于定制的模式元素的定义可能是⼀种更好的选择。可以在openldap的安装⽬录下的schema⽬录中创建⼀个本地⽂件，然后包含在⽂件中。3）定义对象类和属性类型对象类和属性类型定义的正式语法在RFC2252中。下⾯是⼀个属性类型的定义：attributetype ( 1.1.2.1.1 NAME'xjtuUniqueName'DESC ' Xjtu Unique Name 'EQUALITY caseIgnoreMatchSUBSTR caseIgnoreSubstringsMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.15SINGLE-VALUE )其中，1.1.2.1.1是属性类型的OID,NAME后是属性类型的名称，DESC后是属性类型的说明性的描述，EQUALITY和SUBSTR定义了属性⽀持的匹配规则。SYNTAX后是属性的属性语法，由⼀个OID描述。SINGLE-VALUE指明该属性为单值，若要允许该属性为多值属性，SINGLE-VALUE应替换为COLLECTIVE或为空。下⾯是⼀个对象类的定义objectclass ( 1.1.2.2.2 NAME 'xjtuPerson'DESC 'xjtu person objectclass'SUP inetOrgPersonMUST ( 'xjtuUniqueName' $ 'givenName' )MAY ('class' )其中，1.1.2.2.2是对象类的名字，NAME后是对象的名字，DESC后的字符串是对象类的描述，SUP后的inetOrgPerson是xjtuPerson对象类的超类或⽗类，表⽰xjtuPeron从inetorgPerson类继承所有的可选属性和必须属性，MAY后⾯是xjtuPerson新添加的可选属性，属性之间⽤$分隔。MUST指令制定新对象类的必须属性。对象类可以按照类似⾯向对象的⽅式进⾏组织，通过继承和包含机制可以利⽤标准模式中的对象类定义，不需要从头开始构造⾃⼰的对象类层次。扩展模式的原则：尽可能重⽤存在的模式元素在定义对象类时，保持必须属性的个数最⼩化对象类和属性定义的⽬的应该明确避免重复尽量保持模式简单不要修改已经存在的对象类或属性定义6.3 不同⽬录服务器对扩展模式的⽀持微软的活动⽬录（Active Directory）在域控制器允许时允许动态扩展模式，⽽openldap不⽀持动态模式扩展，⽆法在运⾏时扩展模式，只能通过修改服务器的配置⽂件实现。第七章变化⼤量的服务器操作是留给实现者或管理员决定的。因此,可以建⽴服务器来⽀持事情的多样性。例如, 服务器中的数据存储没有被指定-服务器可以⽤平⾯⽂件，数据库,或只是⼀个通向其他服务器的通道。访问控制不是标准化的,尽管在它上⾯已经有⼯作正在运⾏，并且他还有通⽤的模型。⽤户的密码可能存储在他们的条⽬中或其他地⽅。当服务器的愿望和实施存在各种限制时它可以拒绝执⾏操作。⼤部分的LDAP都是可以扩展的。⽐如:⼀个可定义的新的操作。控制可能修改请求和响应,如请求排序搜索结果。可以定义新搜索范围和绑定⽅法。属性可以有修改他们的语义的选项。第⼋章RFC 2254RFC 2254是LDAP搜索过滤器的字符串表⽰形式。LDAP定义了⼀个传送到LDAP服务器的搜索过滤器的⽹络表⽰。对于某些应⽤程序，拥有⼀种使⽤公共的可读的格式来表⽰搜索过滤器的⽅法可能会有⽤处。本章定义了⼀种表⽰LDAP搜索过滤器的可读串格式。RFC2254取代了RFC 1960，字符串LDAP过滤器的定义包括了⽀持LDAP版本3扩展匹配过滤器，也包括了⽀持全部的LDAP搜索过滤器。8.1 LDAP搜索过滤器定义⼀种LDAPv3搜索过滤器的定义如下：Filter ::= CHOICE {and [0] SET OF Filter,or [1] SET OF Filter,not [2] Filter,equalityMatch [3] AttributeValueAssertion,substrings [4] SubstringFilter,greaterOrEqual [5] AttributeValueAssertion,lessOrEqual [6] AttributeValueAssertion,present [7] AttributeDescription,approxMatch [8] AttributeValueAssertion,extensibleMatch [9] MatchingRuleAssertion}SubstringFilter ::= SEQUENCE {type AttributeDescription,SEQUENCE OF CHOICE {initial [0] LDAPString,any [1] LDAPString,final [2] LDAPString}}AttributeValueAssertion ::= SEQUENCE {attributeDesc AttributeDescription,attributeValue AttributeValue}MatchingRuleAssertion ::= SEQUENCE {matchingRule [1] MatchingRuleID OPTIONAL,type [2] AttributeDescription OPTIONAL,matchValue [3] AssertionValue,dnAttributes [4] BOOLEAN DEFAULT FALSE}AttributeDescription ::= LDAPStringAttributeValue ::= OCTET STRINGMatchingRuleID ::= LDAPStringAssertionValue ::= OCTET STRINGLDAPString ::= OCTET STRING上⾯的LDAPString仅限于utf - 8编码的ISO 10646字符集。AttributeDescription是属性描述的⼀个字符串表⽰。8.2 字符串搜索过滤器定义LDAP搜索过滤器的字符串表⽰是通过下⾯的语法来定义的，过滤器格式使⽤⼀个前缀符号。filter = "(" filtercomp ")"filtercomp = and / or / not / itemand = "&" filterlistor = "|" filterlistnot = "!" filterfilterlist = 1*filteritem = simple / present / substring / extensiblesimple = attr filtertype valuefiltertype = equal / approx / greater / lessequal = "="approx = "~="greater = ">="less = "<="extensible = attr [":dn"] [":" matchingrule] ":=" value/ [":dn"] ":" matchingrule ":=" valuepresent = attr "=*"substring = attr "=" [initial] any [final]initial = valueany = "*" *(value "*")final = valueattr = AttributeDescription from Section 4.1.5 of [1] matchingrule = MatchingRuleId from Section 4.1.9 of [1]value = AttributeValue from Section 4.1.6 of [1]在上⾯给出的相应的部分中描述了attr,matchingrule和值构造。如果⼀个值包含以下任何字符Character ASCII value---------------------------* 0x2a

2023年6月21日发(作者：)

LDAP协议LDAP协议⽬录前⾔ (3)第⼀章起源与影响 (3)1.1 起源 (3)1.2 影响 (4)第⼆章协议概况 (4)2.1 LDAP协议模型 (4)2.2 数据模型 (5)第三章⽬录结构 (7)3.1 基准DN (7)3.2 在⽬录树中组织数据 (8)3.3 数据结构 (9)第四章操作 (9)4.1 添加 (10)4.2 绑定（认证） (10)4.3 删除 (11)4.4 查询⽐较 (11)4.5 修改 (11)4.6 StartTLS (12)4.7 Unbind (12)第五章LDAP URLs (13)第六章模式 (13)6.1 模式概述 (13)6.2 模式扩展 (14)6.3 不同⽬录服务器对扩展模式的⽀持 (16)第七章变化 (16)第⼋章RFC 2254 (16)8.1 LDAP搜索过滤器定义 (16)8.2 字符串搜索过滤器定义 (17)8.3 举例 (19)8.4 安全注意事项 (20)第九章连接⽬录服务器（java） (20)9.1 ⽬录服务器建⽴连接 (20)9.2 获取⽬录服务器指定条⽬的属性值 (21)总结 (23)LDAP协议前⾔现在LDAP技术不仅发展得很快⽽且也是激动⼈⼼的。在企业范围内实现LDAP可以让运⾏在⼏乎所有计算机平台上的所有的应⽤程序从LDAP⽬录中获取信息。LDAP⽬录中可以存储各种类型的数据：电⼦邮件地址、邮件路由信息、⼈⼒资源数据、公⽤密匙、联系⼈列表，等等。通过把LDAP⽬录作为系统集成中的⼀个重要环节，可以简化员⼯在企业内部查询信息的步骤，甚⾄连主要的数据源都可以放在任何地⽅。如果Oracle、Sybase、Informix或Microsoft SQL数据库中已经存储了类似的数据，那么LDAP 和这些数据库到底有什么不同呢？是什么让它更具优势？请继续读下去吧！第⼀章起源与影响1.1 起源1.1.1 X.500的出现LDAP（Light-weight Directory Access Protocol）是在国际电报电话咨询委员会（CCITT）和国际标准化组织（ISO）联合开发的许多标准的基础上建⽴的。CCITT现在称为国际电信联盟（ITU）。ITU和ISO的⽬标是定义⼀个通⽤的⽬录标准，尽可能包括最⼴泛的⽬录服务。所开发的标准将构成⾯向CCITT和ITU开发的开放系统互连（OSI）⽹络模型的⽬录服务。最终的标准X.500是⼀个既复杂⼜全⾯的标准，很难实施，⽽且成本⾼昂，需要运⾏复杂的OSI⽹络协议。该标准旨在拥有⼀个分布全球的⽬录，并且带有标准访问接⼝。X.500⽬录标准极其复杂。作为其设计操作平台的OSI⽹络协议也⽐现在通常使⽤的传输控制协议，Internet 协议（TCP/IP）套件复杂得多。1.1.2 到LDAP的过渡X.500接受和实施的主要问题是其过于复杂，并且实施和管理相关成本⾮常⾼。为了提⾼X.500⽬录的可接受性，Internet⼯程任务组（IETF）决定定义新的访问协议。该协议更简单，不依赖于OSI堆栈，⽽使⽤TCP/IP堆栈。这产⽣了两个新协议：⽬录辅助服务（Directory Assistance Service，DAS）和有效实施X.500的⽬录接⼝（Directory Interface to X.500 ImplementedEfficiently，DIXIE）。LDAP旨在作为访问X.500⽬录的轻型⽅法。然⽽，随着时间的推移，情况越来越明显，对X.500 ⽬录服务器的访问⼤部分是通过LDAP协议进⾏的。当这⼀情况变得清晰时，⽬录服务器只能通过LDAP访问被设计和实施。这些服务器不再有X.500⽬录服务器中的复杂性，其实施和管理费⽤也更低。LDAP服务器还拥有⽐X.500⽬录服务器更出⾊的性能。LDAP的当前版本是LDAP v3。LDAP v1没有作为标准发布。LDAP v2于1995年3⽉公布，并在三个RFC中进⾏了定义：RFC1777、RFC 1778和RFC 1779。LDAP v2在RFC 3494中停⽌作为标准使⽤。现在⽀持扩展操作和控制，使LDAP v3能够在不改变标准协议的情况下进⾏扩展。 LDAP v3可向后兼容LDAP v2。LDAP v3服务器的⼀个要求是LDAP v2客户端要能够与之连接。LDAP v3作为操作系统、⽹络操作系统、⽬录服务、应⽤程序（⽐如：电⼦邮件服务器）和客户端应⽤程序的组成部分⽽得到⼴泛实施。1.2 影响1.2.1 LDAP协议的作⽤由于LDAP所具有的查询效率⾼、树状的信息管理模式、分布式的部署框架以及灵活⽽细腻的访问控制，使LDAP⼴泛地应⽤于基础性、关键性信息的管理，如⽤户信息、⽹络资源信息等。LDAP的应⽤主要涉及⼏种类型。信息安全类：数字证书管理、授权管理、单点登录；科学计算类：DCE (Distributed Computing Envirionment，分布式计算环境)、UDDI （UniversalDescription，Discovery and Integration, 统⼀描述、发现和集成协议）；⽹络资源管理类：MAIL系统、DNS系统、⽹络⽤户管理、电话号码簿；电⼦政务资源管理类：内⽹组织信息服务、电⼦政务⽬录体系、⼈⼝基础库、法⼈基础库。1.2.2 LDAP协议的应⽤⽬前，LDAP已应⽤在北京⼤学校园⽹络⽤户管理系统、Novell的eProvision应⽤解决⽅案、上海公务⽹统⼀⽤户管理、中国数字图书馆系统的⽤户管理部分，以及北京、上海、天津、福建等省级CA等。第⼆章协议概况2.1 LDAP协议模型LDAP协议采⽤客户机/服务器模型。客户机构造⼀个LDAP协议请求，LDAP服务器必须分配⼀个端⼝来监听客户端请求，通过TCP/IP传递给LDAP服务器，在服务器执⾏完请求的操作后，把包含结果或者错误信息的相应回传给客户机。LDAP协议请求的PDU是⼀个LDAPMessage结构，响应的PDU是⼀个LDAPResult结构。LDAP的PDU都直接映射到TCP的字节流在⽹上传输。LDAP客户和LDAP服务器的⼀般交互过程如下：图2－1 LDAP 会话1）客户端与LDAP服务器建⽴连接，要求客户端指定服务器的主机名或IP地址和伺服端⼝号。服务器将返回⼀个连接句柄，它指向了这次连接的所有信息。2）客户端与服务器建⽴⼀个会话（session），称为绑定。客户端提供⽤户名和⼝令进⾏认证，也可以建⽴⼀个具有缺省访问权限的匿名会话，还可以建⽴⼀个使⽤加密的安全会话。3）客户端发送操作请求，服务器执⾏操作。4）客户端结束所有请求后，关闭和服务器的会话，称为解除绑定。5）断开与服务器的连接。LDAP客户端的请求可以是同步的，也可以是异步的。在LDAPMessage结构中的messgeID整型变量唯⼀的标识⼀个请求，因此服务器通过messageID可以识别客户机发出的请求并正确返回该请求的响应，这是异步操作实现的原理。2.2 数据模型2.2.1条⽬的构成⽬录中存放数据的基本单位是条⽬。条⽬代表了真实世界中的对象，例如⼈、服务器、组织等等，是具有区别名DN（Distinguished Name）的属性（Attribute）集合，每个属性由⼀个类型（Type）和多个值（Values）构成，条⽬的逻辑结构如图2－2所⽰图2－2 条⽬的逻辑结构类型通常是容易记忆的名称，⽐如“cn”是通⽤名称（common name），或者“mail”是电⼦邮件地址。条⽬的值的语法取决于属性类型。⽐如，cn属性可能具有⼀个值“Jia Chen”。⼀个mail属性可能包含值“iris@/doc/ ”。⼀个jpegphoto属性可能包含⼀幅JPEG（⼆进制）格式的图⽚。另外，LDAP通过使⽤⼀个特殊的，叫做objectClass的属性来允许您控制哪⼀个属性必须出现或者允许出现在⼀个条⽬中。objectClass属性的值决定了该条⽬必须遵守的模式规则。⼀般来说，⼤多数属性的取值对于服务器并⽆意义，⽽由客户去解释和使⽤，但有⼀类属性叫操作属性（OperationalAttribute），它们往往由服务器⾃动⽣产和修改，⽤户⽆法修改。2.2.2 DIT的组织和命名在LDAP中所有的条⽬以⽬录信息树（Directory Information Tree,DIT）组织。图2-3表⽰了了⼀个⽬录树，它由位于不同层次的节点组成。LDAP不允许悬挂条⽬（即没有⽗节点的条⽬）存在于DIT中。在创建⼀个DIT之前，必须先定义根节点，即基准DN,也称为DSE(DSA-specific Entry ⽬录服务代理条⽬)，它描述了LDAP服务器⾃⾝的信息。⽬录对象必须有名字以便⽆歧义的由客户端引⽤或识别，相对区别名RDN和可区别名DN是两种识别⽬录对象的主要⽅法。图2－3RDN由⼀个称为命名属性的项⽬属性构成，它在⽗节点下的⼦树范围内唯⼀的识别每⼀个项⽬。每⼀个对象类都定义了⼀组属性充当命名属性，但在⼀个对象类的任何实例中只能由⼀个命名属性。要在整个⽬录层次中唯⼀的识别⼀个⽬录对象，就必须使⽤DN。每⼀个LDAP记录项的DN是由两个部分组成的：相对DN（RDN）和记录在LDAP⽬录中的位置。RDN是DN 中与⽬录树的结构⽆关的部分。可以看出，DN的定义是递归的，⽬录对象的DN就是其RDN与⽬录对象所在⽗条⽬DN的简单连接。第三章⽬录结构LDAP⽬录以树状的层次结构来存储数据。如果你对⾃顶向下的DNS树或UNIX⽂件的⽬录树⽐较熟悉，也就很容易掌握LDAP⽬录树这个概念了。就象DNS的主机名那样，LDAP⽬录记录的标识名（Distinguished Name，简称DN）是⽤来读取单个记录，以及回溯到树的顶部。每⼀个DN都是唯⼀的。3.1 基准DNLDAP⽬录树的最顶部就是根，也就是所谓的“基准DN"。基准DN通常使⽤下⾯列出的三种格式之⼀。假定我在名为FooBar的电⼦商务公司⼯作，这家公司在Internet上的名字是/doc/ 。o="FooBar, Inc.", c=US在这个例⼦中，o=FooBar, Inc. 表⽰组织名，在这⾥就是公司名的同义词。c=US 表⽰公司的总部在美国。以前，⼀般都⽤这种⽅式来表⽰基准DN。但是事物总是在不断变化的，现在所有的公司都已经（或计划）上Internet上。随着Internet的全球化，在基准DN中使⽤国家代码很容易让⼈产⽣混淆。现在，X.500格式发展成下⾯列出的两种格式。o=/doc/（⽤公司的Internet地址表⽰的基准DN）这种格式很直观，⽤公司的域名作为基准DN。这也是现在最常⽤的格式。dc=foobar, dc=com（⽤DNS域名的不同部分组成的基准DN）就象上⾯那⼀种格式，这种格式也是以DNS域名为基础的，但是上⾯那种格式不改变域名（也就更易读），⽽这种格式把域名：/doc/ 分成两部分dc=foobar, dc=com。在理论上，这种格式可能会更灵活⼀点，但是对于最终⽤户来说也更难记忆⼀点。3.2 在⽬录树中组织数据因为LDAP⽬录可以定制成存储任何⽂本或⼆进制数据，到底存什么要由你⾃⼰决定。LDAP⽬录⽤对象类型（objectclasses）的概念来定义运⾏哪⼀类的对象使⽤什么属性。在⼏乎所有的LDAP服务器中，你都要根据⾃⼰的需要扩展基本的LDAP⽬录的功能，创建新的对象类型或者扩展现存的对象类型。LDAP⽬录以⼀系列“属性对”的形式来存储记录项，每⼀个记录项包括属性类型和属性值（这与关系型数据库⽤⾏和列来存取数据有根本的不同）属性的值在保存的时候是保留⼤⼩写的，但是在默认情况下搜索的时候是不区分⼤⼩写的。某些特殊的属性（例如，password）在搜索的时候需要区分⼤⼩写。dn: cn=Oatmeal Deluxe, ou=recipes, dc=foobar, dc=comcn: Instant Oatmeal DeluxerecipeCuisine: breakfastrecipeIngredient: 1 packet instant oatmealrecipeIngredient: 1 cup waterrecipeIngredient: 1 pinch saltrecipeIngredient: 1 tsp brown sugarrecipeIngredient: 1/4 apple, any type请注意上⾯每⼀种配料都作为属性recipeIngredient值。LDAP⽬录被设计成象上⾯那样为⼀个属性保存多个值的，⽽不是在每⼀个属性的后⾯⽤逗号把⼀系列值分开。因为⽤这样的⽅式存储数据，所以数据库就有很⼤的灵活性，不必为加⼊⼀些新的数据就重新创建表和索引。更重要的是，LDAP⽬录不必花费内存或硬盘空间处理“空”域，也就是说，实际上不使⽤可选择的域也不会花费你任何资源。3.3 数据结构在⽬录基本DN 的下⾯是容器或组织单元（OU），它们从逻辑上对您的数据进⾏分隔或分组。还要紧记⼀点，您将结构容器嵌套得越深，它返回查询所⽤的时间就越长。图3-1第四章操作LDAP是⼀种消息协议，请求和相关的应答都带有相同的message ID。它定义了⼏种消息Add - 添加Bind (authentication) - 绑定(认证）Delete - 删除Search and Compare - 查询⽐较Modify - 修改StartTLS –扩展的TLS协商通知消息Unbind –客户端通知服务器结束会话(不是bind的反向操作)4.1 添加添加是向⽬录服务数据库添加⼀个新的条⽬。如果在添加请求中的可分辨名称已经存在于⽬录中，则服务器将不添加重复的条⽬，但在添加结果中将设置结果代码为⼗进制的“条⽬已经存在”。LDAP兼容服务器当试图定位条⽬时将永远不会取消在添加请求中传送的可分辨名称，所以可分辨名称从未有别名。LDAP兼容的服务器将确保可分辨名称并且所有属性符合命名标准。要添加的条⽬必须不存在，但直接上级必须存在。dn: uid=user,ou=people,dc=example,dc=comchangetype: addobjectClass: topobjectClass: personuid: usersn: last-namecn: common-nameuserPassword: password在上⾯的例⼦中，uid=user,ou=people,dc=example,dc=com必须不存在，ou=people,dc=example,dc=com必须存在。4.2 绑定（认证）当创建⼀个LDAP会话，也就是说，当⼀个LDAP客户端连接到服务器，⾝份验证会话的状态设置为“匿名”。 BIND操作为会话建⽴⼀个认证状态。简单绑定和SASL PLAIN可以以明⽂的⽅式发送⽤户的DN和密码，所以利⽤简单或SASLPLAIN的连接应使⽤传输层安全（TLS）进⾏加密。服务器在指定的条⽬通常对userPassword属性检查密码。匿名BIND（空DN和密码）重置到匿名状态的连接。SASL（简单认证和安全层）通过⼴泛的机制提供认证服务，如Kerberos或⽤TLS 发送客户端证书。BIND还设置了LDAP协议的版本。这个版本是⼀个整数，虽然协议中的标准的⽀持整数1到127（含）之间，但⽬前必须是2或3。如果客户端请求的是服务器不⽀持的版本，服务器必须在BIND中设置结果代码去回应错误协议的代码。通常情况下客户端必须使⽤LDAPv3,它在协议中是默认的，但它不总是在LDAP库中。BIND在LDAPv2的会话中是第⼀个操作，但在LDAPv3中不是必须的（当前LDAP版本）。在LDAPv3中，每个成功的BIND需要改变会话的认证状态，每个不成功的BIND 需要重置会话的认证状态。4.3 删除要删除⼀个条⽬，LDAP客户端需要发送正确格式的请求到服务器。删除请求必须包含要删除的条⽬的可分辨名称请求控件也可以连接到删除请求当处理⼀个删除请求时服务器不引⽤别名只有叶⼦节点(条⽬没有下属)可能通过删除请求被删除4.4 查询⽐较baseObject 基本对象–从⽬录树的何处开始查找，在DN (Distinguished Name) 处定义。scope 范围–查找层数：baseObject (如果baseObject所指的DN为某⼀个对象条⽬，则查找⼀个对象), singleLevel ⼀级(查找基本对象所指DN的成员), 全部⼦树(查找基本对象所指DN 及⼦树的所有成员)。filter 过滤器–怎样核查每个条⽬. ⽐如过滤器。(&(objectClass=person)(|(givenName=guoqing)(mail=*guoqing*))) –查找名字为guoqing或emai地址包含guoqing的⼈。derefAliases 废弃参照别名–是否/怎样跟从别名条⽬。attributes 属性–查找返回结果的哪些属性。sizeLimit, timeLimit –最⼤返回条⽬数限制, 最⼤允许的查找时间。typesOnly –只返回属性类型。4.5 修改修改操作使⽤LDAP服务器进⾏更改现有条⽬。不能尝试修改不存在的项⽬。修改请求是由服务器来实现访问控制的。修改操作要求指定可分辨名称（DN）的条⽬和序列的变化。序列中的每⼀个变化必须是下列之⼀：添加（添加⼀个新的值，必须不中已存在的条⽬）删除（删除现有值）更换（⽤新的值替换现有值）添加到属性值的LDIF的例⼦：dn: dc=example,dc=comchangetype: modifyadd: cncn: the-new-cn-value-to-be-added要替换现有属性的值，可以使⽤关键字替换。如果该属性是多值，客户端必须指定要删除的属性的值。要从条⽬中删除⼀个属性，可以使⽤关键字删除和更改类型指⽰符修改。如果该属性是多值，客户端必须指定要删除的属性的值。4.6 StartTLS –扩展的TLS协商通知消息STARTTLS操作在连接上建⽴传输层安全（SSL）。它可以提供数据的保密性（保护数据不被第三⽅观察）和/或数据的完整性保护（保护数据不被篡改）。在TLS协商的服务器发送X.509证书，以证明其⾝份。客户也可以发送⼀个证书，以证明其⾝份。这样做之后，客户端可以使⽤SASL /外部。通过使⽤SASL /外部客户端请求的服务器获得它的⾝份，在⼀个较低的⽔平（如TLS）提供凭据。尽管技术上服务器可能在任何低⽔平使⽤任何⾝份信息建⽴,但通常服务器将通过TLS建⽴⾝份信息。服务器在⼀个单独的端⼝上也常常⽀持⾮标准的“LDAPS”协议（“安全LDAP”，俗称“通过SSL的LDAP”），默认情况下端⼝为636。LDAPS与LDAP之间有两个不同点：1）在连接上，客户端和服务器在任何LDAP信息被传递之前建⽴TLS ；2）LDAPS连接必须在TLS关闭后关闭。应该指出的是,⼀些“ldap”客户端库只加密通信,他们不针对提供的证书上的名字检查主机名。LDAPS与LDAPv2⼀起使⽤，因为StartTLS操作尚未定义。使⽤LDAPS 已过时，现代软件应该只使⽤STARTTLS。4.7 Unbind客户端通知服务器结束会话(不是bind的反向操作),客户端可以通过简单地关闭连接中⽌会话，但他们应该解除绑定。取消绑定允许服务器正常关闭连接和免费资源，否则它会保持⼀段时间，直到发现客户已经放弃了连接。它还指⽰服务器可以取消能取消的操作，并且发送响应的操作不能被取消。第五章LDAP URLsLDAP URL格式在不同程度上⽀持客户端的时候存在，并且在转介和继续引⽤上返回到服务器（参见RFC 4516）：ldap://host:port/DN?attributes?scope?filter?extensions下⾯描述的⼤多数组件都是可选的。主机是⽤来搜索LDAP服务器的FQDN或IP地址的。端⼝是LDAP服务器的⽹络端⼝（默认端⼝389）。DN是⽤作搜索基本的可分辨名称的。属性是检索以逗号分隔的属性列表的。范围指定搜索范围，可以是“base”（默认值），“one”或“sub”。过滤器是⼀个搜索过滤器。例如在RFC 4515中定义的(objectClass=*)。扩展是LDAP URL格式的扩展。例如，"ldap:///doc/ /cn=John%20Doe,dc=example,dc=com"，是指在John Doe的条⽬/doc/ 中所有的⽤户属性，⽽"ldap:///dc=example,dc=com??sub?(givenName=John)"在默认的服务器中搜索条⽬（注意三个斜杠，省略了主机，双问号和属性）。⾄于其他的URL，特殊字符必须编码。⼀个类似的⾮标准的LDAP：通过SSL的LDAP URL⽅案。它不应该被混同于LDAP和 TLS，它是通过使⽤标准的LDAP模式和STARTTLS操作来实现的。第六章模式6.1 模式概述LDAP中关于属性、对象类⽂法和匹配规则等的规定构成所谓schema。模式信息在⽬录中通过objectclass为subschema的条⽬来表⽰，通常在DIT中占据⼀个独⽴的分⽀，可以对模式信息进⾏同其他⽬录对象⼀样的搜索操作。在LDAP中，schema居于核⼼地位，模式管理和扩展也是最复杂和具有挑战性的⼯作。Openldap随软件发布了⼀组模式定义，要使⽤任何⼀个模式⽂件，只需在⽂件中的全局定义部分包含所需要的⽂件。如：include/usr/local/etc/openldap/schema/6.2 模式扩展在实际应⽤中，需要设计⽬录模式描述将要存储在⽬录中的数据类型。如果有的数据⽆法⽤服务器⽀持的标准模式来表⽰，这就需要对模式进⾏扩展和⾃定义。下⾯是定义⼀个新的模式的4个步骤：获取和分配对象标识符；命名属性类型和对象类；创建本地模式⽂件；定义对象类和属性类型；获取和分配对象标识符。每个LDAP对象类和属性必须分配⼀个唯⼀的名字和对象标识符。在⾃定义模式时，每个公司或组织需要⼀个唯⼀的OID,⼀个OID可以满⾜所有的模式需要，因为可以通过创建新的分⽀来满⾜所有的OID需要。获取和分配对象标识符的过程如下：从IANA为⾃⼰的组织申请OID;创建⼀个登记表来维护对此OID的分配；为模式元素提供OID创建分⽀。例如某组织被赋予⼀个OID1.1，可以按照如下所⽰的⽅法扩展树：1）命名属性类型和对象类为模式元素分配⼀个唯⼀的OID之外，还应该为每个模式元素提供⼀个具有描述性的名字，⾃定义模式元素的名字不能和标准模式元素冲突，解决办法是为每个⾃定义的模式元素添加前缀。在RFC2377中有关于模式元素命名⽅案的详细信息。2）创建本地模式⽂件虽然在配置⽂件指令中的objectClass和attributeTypes可以被⽤来定义⽬录中的模式规则，但实际应⽤中创建⼀个⽂件来包含对于定制的模式元素的定义可能是⼀种更好的选择。可以在openldap的安装⽬录下的schema⽬录中创建⼀个本地⽂件，然后包含在⽂件中。3）定义对象类和属性类型对象类和属性类型定义的正式语法在RFC2252中。下⾯是⼀个属性类型的定义：attributetype ( 1.1.2.1.1 NAME'xjtuUniqueName'DESC ' Xjtu Unique Name 'EQUALITY caseIgnoreMatchSUBSTR caseIgnoreSubstringsMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.15SINGLE-VALUE )其中，1.1.2.1.1是属性类型的OID,NAME后是属性类型的名称，DESC后是属性类型的说明性的描述，EQUALITY和SUBSTR定义了属性⽀持的匹配规则。SYNTAX后是属性的属性语法，由⼀个OID描述。SINGLE-VALUE指明该属性为单值，若要允许该属性为多值属性，SINGLE-VALUE应替换为COLLECTIVE或为空。下⾯是⼀个对象类的定义objectclass ( 1.1.2.2.2 NAME 'xjtuPerson'DESC 'xjtu person objectclass'SUP inetOrgPersonMUST ( 'xjtuUniqueName' $ 'givenName' )MAY ('class' )其中，1.1.2.2.2是对象类的名字，NAME后是对象的名字，DESC后的字符串是对象类的描述，SUP后的inetOrgPerson是xjtuPerson对象类的超类或⽗类，表⽰xjtuPeron从inetorgPerson类继承所有的可选属性和必须属性，MAY后⾯是xjtuPerson新添加的可选属性，属性之间⽤$分隔。MUST指令制定新对象类的必须属性。对象类可以按照类似⾯向对象的⽅式进⾏组织，通过继承和包含机制可以利⽤标准模式中的对象类定义，不需要从头开始构造⾃⼰的对象类层次。扩展模式的原则：尽可能重⽤存在的模式元素在定义对象类时，保持必须属性的个数最⼩化对象类和属性定义的⽬的应该明确避免重复尽量保持模式简单不要修改已经存在的对象类或属性定义6.3 不同⽬录服务器对扩展模式的⽀持微软的活动⽬录（Active Directory）在域控制器允许时允许动态扩展模式，⽽openldap不⽀持动态模式扩展，⽆法在运⾏时扩展模式，只能通过修改服务器的配置⽂件实现。第七章变化⼤量的服务器操作是留给实现者或管理员决定的。因此,可以建⽴服务器来⽀持事情的多样性。例如, 服务器中的数据存储没有被指定-服务器可以⽤平⾯⽂件，数据库,或只是⼀个通向其他服务器的通道。访问控制不是标准化的,尽管在它上⾯已经有⼯作正在运⾏，并且他还有通⽤的模型。⽤户的密码可能存储在他们的条⽬中或其他地⽅。当服务器的愿望和实施存在各种限制时它可以拒绝执⾏操作。⼤部分的LDAP都是可以扩展的。⽐如:⼀个可定义的新的操作。控制可能修改请求和响应,如请求排序搜索结果。可以定义新搜索范围和绑定⽅法。属性可以有修改他们的语义的选项。第⼋章RFC 2254RFC 2254是LDAP搜索过滤器的字符串表⽰形式。LDAP定义了⼀个传送到LDAP服务器的搜索过滤器的⽹络表⽰。对于某些应⽤程序，拥有⼀种使⽤公共的可读的格式来表⽰搜索过滤器的⽅法可能会有⽤处。本章定义了⼀种表⽰LDAP搜索过滤器的可读串格式。RFC2254取代了RFC 1960，字符串LDAP过滤器的定义包括了⽀持LDAP版本3扩展匹配过滤器，也包括了⽀持全部的LDAP搜索过滤器。8.1 LDAP搜索过滤器定义⼀种LDAPv3搜索过滤器的定义如下：Filter ::= CHOICE {and [0] SET OF Filter,or [1] SET OF Filter,not [2] Filter,equalityMatch [3] AttributeValueAssertion,substrings [4] SubstringFilter,greaterOrEqual [5] AttributeValueAssertion,lessOrEqual [6] AttributeValueAssertion,present [7] AttributeDescription,approxMatch [8] AttributeValueAssertion,extensibleMatch [9] MatchingRuleAssertion}SubstringFilter ::= SEQUENCE {type AttributeDescription,SEQUENCE OF CHOICE {initial [0] LDAPString,any [1] LDAPString,final [2] LDAPString}}AttributeValueAssertion ::= SEQUENCE {attributeDesc AttributeDescription,attributeValue AttributeValue}MatchingRuleAssertion ::= SEQUENCE {matchingRule [1] MatchingRuleID OPTIONAL,type [2] AttributeDescription OPTIONAL,matchValue [3] AssertionValue,dnAttributes [4] BOOLEAN DEFAULT FALSE}AttributeDescription ::= LDAPStringAttributeValue ::= OCTET STRINGMatchingRuleID ::= LDAPStringAssertionValue ::= OCTET STRINGLDAPString ::= OCTET STRING上⾯的LDAPString仅限于utf - 8编码的ISO 10646字符集。AttributeDescription是属性描述的⼀个字符串表⽰。8.2 字符串搜索过滤器定义LDAP搜索过滤器的字符串表⽰是通过下⾯的语法来定义的，过滤器格式使⽤⼀个前缀符号。filter = "(" filtercomp ")"filtercomp = and / or / not / itemand = "&" filterlistor = "|" filterlistnot = "!" filterfilterlist = 1*filteritem = simple / present / substring / extensiblesimple = attr filtertype valuefiltertype = equal / approx / greater / lessequal = "="approx = "~="greater = ">="less = "<="extensible = attr [":dn"] [":" matchingrule] ":=" value/ [":dn"] ":" matchingrule ":=" valuepresent = attr "=*"substring = attr "=" [initial] any [final]initial = valueany = "*" *(value "*")final = valueattr = AttributeDescription from Section 4.1.5 of [1] matchingrule = MatchingRuleId from Section 4.1.9 of [1]value = AttributeValue from Section 4.1.6 of [1]在上⾯给出的相应的部分中描述了attr,matchingrule和值构造。如果⼀个值包含以下任何字符Character ASCII value---------------------------* 0x2a

本文发布于:2023-06-21，感谢您对本站的认可！

本文链接:http://torson.com.cn/wangzhan/1687298748a1399.html