LDAP 学习全纪录

转载：

http://www.iteye.com/topic/167125

http://baike.baidu.com/view/159263.htm

LDAP是如何工作的?

LDAP采用客户－服务器模式. 包含在一个或多个LDAP服务器中的数据组成了目录信息树(DIT). 客户端连接到服务器然后问一个问题. 服务器返回一个应答和/或一个指针告诉客户端去哪里获得更多的信息 (通常是另一台 LDAP 服务器). 客户端连接哪台LDAP服务器不重要, 目录的视图看起来都一样; 一个提交到某台LDAP服务器的名字在另一台LDAP服务器上也将指向相同的条目. 这是全球目录服务的一个重要功能.

LDAP的实质

不少LDAP开发人员喜欢把LDAP与关系数据库相比，认为是另一种的存贮方式，然后在读性能上进行比较。实际上，这种对比的基础是错误的。LDAP和关 系数据库是两种不同层次的概念，后者是存贮方式（同一层次如网格数据库，对象数据库），前者是存贮模式和访问协议。LDAP是一个比关系数据库抽象层次更 高的存贮概念，与关系数据库的查询语言SQL属同一级别。LDAP最基本的形式是一个连接数据库的标准方式。该数据库为读查询作了优化。因此它可以很快地 得到查询结果，不过在其它方面，例如更新，就慢得多。

 

目录与关系数据库相似，是指具有描述性的基于属性的记录集合，但它的数据类型主要是字符型，为了检索的需要添加了BIN（二进制数据）、CIS（忽略大小 写）、CES（大小写敏感）、TEL（电话型）等语法（Syntax），而不是关系数据库提供的整数、浮点数、日期、货币等类型，同样也不提供象关系数据 库中普遍包含的大量的函数，它主要面向数据的查询服务（查询和修改操作比一般是大于10:1），不提供事务的回滚（rollback）机制，它的数据修改 使用简单的锁定机制实现All-or-Nothing，它的目标是快速响应和大容量查询并且提供多目录服务器 的信息复制功能。

 

LDAP的使用权限

　　LDAP允许你根据需要使用ACI（一般都称为ACL或者访问控制列表）控制对数据读和写的权限。例如，设备管 理员可以有权改变员工的工作地点和办公室号码，但是不允许改变记录中其它的域。ACI可以根据谁访问数据、访问什么数据、数据存在什么地方以及其它对数据 进行访问控制。因为这些都是由LDAP目录服务器完成的，所以不用担心在客户端的应用程序上是否要进行安全检查。

　　LDAP提供很复杂的不同层次的访问控制或者ACI。因这些访问可以在服务器端控制，这比用客户端的软件保证数据的安全可安全多了。

　　用LDAP的ACI，可以完成： 　　l 给予用户改变他们自己的电话号码和家庭地址的权限，但是限制他们对其它数据（如，职务名称，经理的登录名，等等）只有“只读”权限。 　　l 给予“HR-admins"组中的所有人权限以改变下面这些用户的信息：经理、工作名称、员工号、部门名称和部门号。但是对其它域没有写权限。 　　l 禁止任何人查询LDAP服务器上的用户口令，但是可以允许用户改变他或她自己的口令。 　　l 给予经理访问他们上级的家庭电话的只读权限，但是禁止其他人有这个权限。 　　l 给予“host-admins"组中的任何人创建、删除和编辑所有保存在LDAP服务器中的与计算机主机有关的信息 　　l 通过Web，允许“foobar-sales"组中的成员有选择地给予或禁止他们自己读取一部分客户联系数据的读权限。这将允许他们把客户联系信息下载到 本地的笔记本电脑或个人数字助理（PDA）上。（如果销售人员的软件都支持LDAP，这将非常有用） 　　l 通过Web，允许组的所有者删除或添加他们拥有的组的成员。例如：可以允许销售经理给予或禁止销售人员改变Web页的权限。也可以允许邮件假名（mail aliase）的所有者不经过IT技术人员就直接从邮件假名中删除或添加用户。“公用”的邮件列表应该允许用户从邮件假名中添加或删除自己（但是只能是自 己）。也可以对IP地址或主机名加以限制。例如，某些域只允许用户IP地址以192.168.200.*开头的有读的权限，或者用户反向查找DNS得到的 主机名必须为*.foobar点com。

LDAP数据结构

在LDAP中目录是按照树型结构组织，目录由条目（Entry）组成，条目相当于关系数据库中表的记录；条目是具有区别名 DN（Distinguished Name）的属性（Attribute）集合，DN相当于关系数据库表中的关键字 （Primary 　　Key）；属性由类型（Type）和多个值（Values）组成，相当于关系数据库中的域 （Field）由域名和数据类型组成，只是为了方便检索的需要，LDAP中的Type可以有多个Value，而不是关系数据库中为降低数据的冗余性要求实 现的各个域必须是不相关的。LDAP中条目的组织一般按照地理位置和组织关系进行组织，非常的直观。LDAP把数据存放在文件中，为提高效率可以使用基于 索引的文件数据库，而不是关系数据库。

 

刨根问底：基准DN

　　LDAP目录树的最顶部就是根，也就是所谓的“基准DN"。基准DN通常使用下面列出的三种格 式之一。假定我在名为FooBar的电子商务公司工作，这家公司在Internet上的名字是foobar 　　o="FooBar, Inc.", c=US 　　（以X.500格式表示的基准DN） 　　在这个例子中，o=FooBar, Inc. 表示组织名，在这里就是公司名的同义词。c=US 表示公司的总部在美国。以前，一般都用这种方式来表示基准DN。但是事物总是在不断变化的，现在所有的公司都已经（或计划）上Internet上。随着 Internet的全球化，在基准DN中使用国家代码很容易让人产生混淆。现在，X.500格式发展成下面列出的两种格式。 　　o=foobar . com 　　（用公司的Internet地址表示的基准DN） 　　这种格式很直观，用公司的域名作为基准DN。这也是现在最常用的格式。 　　dc=foobar, dc=com 　　（用DNS域名的不同部分组成的基准DN） 　　就象上面那一种格式，这种格式也是以DNS域名为基础的，但是上面那种格式不改变域名（也就更 易读），而这种格式把域名：foobar点com分成两部分 dc=foobar, dc=com。在理论上，这种格式可能会更灵活一点，但是对于最终用户来说也更难记忆一点。考虑一下foobar点com这个例子。当foobar点 com和gizmo点com合并之后，可以简单的把“dc=com"当作基准DN。把新的记录放到已经存在的dc=gizmo, dc=com目录下，这样就简化了很多工作（当然，如果foobar点com和wocket点edu合并，这个方法就不能用了）。如果LDAP服务器是新 安装的，我建议你使用这种格式。再请注意一下，如果你打算使用活动目录 （Actrive Directory），Microsoft已经限制你必须使用这种格式。

 

在目录树中怎么组织数据

　　在UNIX文件系统中，最顶层是根目录（root）。在根目录的下面有很多的文件和目录。象上面介绍的那 样，LDAP目录也是用同样的方法组织起来的。 　　在根目录下，要把数据从逻辑上区分开。因为历史上（X.500）的原因，大多数LDAP目录用 OU从逻辑上把数据分开来。OU表示“Organization Unit"，在X.500协议中是用来表示公司内部的机构：销售部、财务部，等等。现在LDAP还保留ou=这样的命名规则，但是扩展了分类的范围，可以 分类为：ou=people, ou=groups, ou=devices，等等。更低一级的OU有时用来做更细的归类。例如：LDAP目录树（不包括单独的记录）可能会是这样的： 　　dc=foobar, dc=com 　　ou=customers 　　ou=asia 　　ou=europe 　　ou=usa 　　ou=employees 　　ou=rooms 　　ou=groups 　　ou=assets-mgmt 　　ou=nisgroups 　　ou=recipes

 

单独的LDAP记录

　　DN是LDAP记录项的名字 　　在LDAP目录中的所有记录项都有一个唯一的“Distinguished Name"，也就是DN。每一个LDAP记录项的DN是由两个部分组成的：相对DN（RDN）和记录在LDAP目录中的位置。 　　RDN是DN中与目录树的结构无关的部分。在LDAP目录中存储的记录项都要有一个名字，这个 名字通常存在cn（Common Name）这个属性里。因为几乎所有的东西都有一个名字，在LDAP中存储的对象都用它们的cn值作为RDN的基础。如果我把最喜欢的吃燕麦粥食谱存为一 个记录，我就会用cn=Oatmeal Deluxe作为记录项的RDN。 　　l 我的LDAP目录的基准DN是dc=foobar,dc=com 　　l 我把自己的食谱作为LDAP的记录项存在ou=recipes 　　l 我的LDAP记录项的RDN设为cn=Oatmeal Deluxe 　　上面这些构成了燕麦粥食谱的LDAP记录的完整DN。记住，DN的读法和DNS主机名类似。下 面就是完整的DN： 　　cn=Oatmeal Deluxe,ou=recipes,dc=foobar,dc=com 　　举一个实际的例子来说明DN 　　现在为公司的员工设置一个DN。可以用基于cn或uid（User ID），作为典型的用户帐号。例如，FooBar的员工Fran Smith（登录名：fsmith）的DN可以为下面两种格式： 　　uid=fsmith,ou=employees,dc=foobar,dc=com 　　（基于登录名） 　　LDAP（以及X.500）用uid表示“User ID"，不要把它和UNIX的uid号混淆了。大多数公司都会给每一个员工唯一的登录名，因此用这个办法可以很好地保存员工的信息。你不用担心以后还会有 一个叫Fran Smith的加入公司，如果Fran改变了她的名字（结婚？离婚？或宗教原因？），也用不着改变LDAP记录项的DN。 　　cn=Fran Smith,ou=employees,dc=foobar,dc=com 　　（基于姓名） 　　可以看到这种格式使用了Common Name（CN）。可以把Common Name当成一个人的全名。这种格式有一个很明显的缺点就是：如果名字改变了，LDAP的记录就要从一个DN转移到另一个DN。但是，我们应该尽可能地避 免改变一个记录项的DN。

 

从Object Classes谈起
在LDAP目录数据库中，所有的条目都必须定义objectClass这个属性。这有点像Java语言里说阐述的“一切皆对象”的理念，每个条目 （LDAP Entry）都要定义自己的Object Classes。Object Class可以看作是LDAP Entry的模板，它定义了条目的属性集，包括必有属性（requited attribute）和可选属性（option attribute）。这里要着重指出的是，在LDAP的Entry中是不能像关系数据库的表那样随意添加属性字段的，一个Entry的属性是由它所继承 的所有Object Classes的属性集合决定的，此外可以包括LDAP中规定的“操作属性”（操作属性是一种独立于Object Class而存在的属性，它可以赋给目录中的任意条目）。如果你想添加的属性不在Object Classes定义属性的范畴，也不是LDAP规定的操作属性，那么是不能直接绑定（在LDAP中，给Entry赋予属性的过程称为绑定）到条目上的，你 必须自定义一个含有你需要的属性的Object Class，而后将此类型赋给条目。
Object Class是可以被继承的，这使它看上去真的很像Java语言中的POJO对象。继承类的对象实例也必须实现父
类规定的必有属性（requited attribute），同时拥有父类规定的可选属性（option attribute）。继承类可以扩展父类的必有属性和可选属性。由于Object Class的继承特性，因此在一个LDAP Entry上，objectClass属性是一个多值属性，它涵盖了Object Class的完整继承树，如用户条目uid=Linly , ou=People, dc=jsoso , dc=net，它直接实现了inetorgperson这个对象类，那么它的objectClass属性值为 inetorgperson，organizationalPerson，person，top。

 

LDAP复制

 

　　LDAP服务器可以使用基于“推”或者“拉”的技术，用简单或基于安全证书的安全验证，复制一 部分或者所有的数据。 　　例如，Foobar有一个“公用的”LDAP服务器，地址为ldap.foobar点com， 端口为389。Netscape Communicator的电子邮件查询功能、UNIX的“ph"命令要用到这个服务器，用户也可以在任何地方查询这个服务器上的员工和客户联系信息。公 司的主LDAP服务器运行在相同的计算机上，不过端口号 是1389。 　　你可能即不想让员工查询资产管理或食谱的信息，又不想让信息技术人员看到整个公司的LDAP目 录。为了解决这个问题，Foobar有选择地把子目录树从主LDAP服务器复制到“公用”LDAP服务器上，不复制需要隐藏的信息。为了保持数据始终是最 新的，主目录服务器被设置成即时“推”同步。这些种方法主要是为了方便，而不是安全，因为如果有权限的用户想查询所有的数据，可以用另一个LDAP端口。 　　假定Foobar通过从奥克兰到欧洲的低带宽数据的连接用LDAP管理客户联系信息。可以建立 从ldap.foobar点com:1389到munich-ldap.foobar点com:389的数据复制，象下面这样： 　　periodic pull: ou=asia,ou=customers,o=sendmail点com 　　periodic pull: ou=us,ou=customers,o=sendmail点com 　　immediate push: ou=europe,ou=customers,o=sendmail点com 　　“拉”连接每15分钟同步一次，在上面假定的情况下足够了。“推”连接保证任何欧洲的联系信息 发生了变化就立即被“推”到Munich。 　　用上面的复制模式，用户为了访问数据需要连接到哪一台服务器呢？在Munich的用户可以简单 地连接到本地服务器。如果他们改变了数据，本地的LDAP服务器就会把这些变化传到主LDAP服务器。然后，主LDAP服务器把这些变化“推”回本地的 “公用”LDAP服务器保持数据的同步。这对本地的用户有很大的好处，因为所有的查询（大多数是读）都在本地的服务器上进行，速度非常快。当需要改变信息 的时候，最终用户不需要重新配置客户端的软件，因为LDAP目录服务器为他们完成了所有的数据交换工作。