转自:http://www.hudong.com/wiki/LDAP
LDAP的英文全称是Lightweight Directory Access Protocol,一般都简称为LDAP。
它是基于X.500标准的,但是简单多了并且可以根据需要定制。与X.500不同,LDAP支持TCP/IP,这对访问Internet是必须的。LDAP的核心规范在RFC中都有定义,所有与LDAP相关的RFC都可以在LDAPman RFC网页中找到。现在LDAP技术不仅发展得很快而且也是激动人心的。在企业范围内实现LDAP可以让运行在几乎所有计算机平台上的所有的应用程序从 LDAP目录中获取信息。LDAP目录中可以存储各种类型的数据:电子邮件地址、邮件路由信息、人力资源数据、公用密匙、联系人列表,等等。通过把 LDAP目录作为系统集成中的一个重要环节,可以简化员工在企业内部查询信息的步骤,甚至连主要的数据源都可以放在任何地方。
LDAP - 主要特点
跨平台
可以在任何计算机平台上,用很容易获得的而且数目不断增加的LDAP的客户端程序访问LDAP目录。而且也很容易定制应用程序为它加上LDAP的支持。
LDAP协议是跨平台的和标准的协议,因此应用程序就不用为LDAP目录放在什么样的服务器上操心了。实际上,LDAP得到了业界的广泛认可,因为它是Internet的标准。产商都很愿意在产品中加入对LDAP的支持,因为他们根本不用考虑另一端(客户端或服务端)是怎么样的。LDAP服务器可以是任何一个开发源代码或商用的LDAP目录服务器(或者还可能是具有LDAP界面的关系型数据库),因为可以用同样的协议、客户端连接软件包和查询命令与LDAP服务器进行交互。与LDAP不同的是,如果软件产商想在软件产品中集成对DBMS的支持,那么通常都要对每一个数据库服务器单独定制。
费用低、维护简单
不象很多商用的关系型数据库,用户不必为LDAP的每一个客户端连接或许可协议付费。大多数的LDAP服务器安装起来很简单,也容易维护和优化。
复制技术
LDAP服务器可以用“推”或“拉”的方法复制部分或全部数据,例如:可以把数据“推”到远程的办公室,以增加数据的安全性。复制技术是内置在LDAP服务器中的而且很容易配置。如果要在DBMS中使用相同的复制功能,数据库产商就会要求支付额外的费用,而且也很难管理。
允许使用ACL
LDAP允许根据需要使用ACL(访问控制列表)控制对数据读和写的权限。例如,设备管理员可以有权改变员工的工作地点和办公室号码,但是不允许改变记录中其它的域。ACL可以根据谁访问数据、访问什么数据、数据存在什么地方以及其它对数据进行访问控制。因为这些都是由LDAP目录服务器完成的,所以不用担心在客户端的应用程序上是否要进行安全检查。
LDAP - 存储数据
LDAP存储什么数据
LDAP对于数据需要从不同的地点读取,但是不需要经常更新,这些信息存储在LDAP目录中是十分有效的,例如:
公司员工的电话号码簿和组织结构图
客户的联系信息
计算机管理需要的信息,包括NIS映射/、email/名称等
软件包的配置信息
公用证书和安全密匙
什么时候用LDAP存储数据
大多数的LDAP服务器都为读密集型的操作进行专门的优化。因此,当从LDAP服务器中读取数据的时候会比从专门为OLTP优化的关系型数据库中读取数据快一个数量级。也是因为专门为读的性能进行优化,大多数的LDAP目录服务器并不适合存储需要经常改变的数据。例如,用LDAP服务器来存储电话号码是一个很好的选择,但是它不能作为电子商务站点的数据库服务器。
LDAP - 基本模型
信息模型:描述LDAP的信息表示方式
在LDAP中信息以树状方式组织,在树状信息中的基本数据单元是条目,而每个条目由属性构成,属性中存储有属性值;LDAP中的信息模式,类似于面向对象的概念,在LDAP中每个条目必须属于某个或多个对象类(Object Class),每个Object Class由多个属性类型组成,每个属性类型有所对应的语法和匹配规则;对象类和属性类型的定义均可以使用继承的概念。每个条目创建时,必须定义所属的对象类,必须提供对象类中的必选属性类型的属性值,在LDAP中一个属性类型可以对应多个值。
在LDAP中把对象类、属性类型、语法和匹配规则统称为Schema,在LDAP中有许多系统对象类、属性类型、语法和匹配规则,这些系统Schema在LDAP标准中进行了规定,同时不同的应用领域也定义了自己的Schema,同时用户在应用时,也可以根据需要自定义Schema。这有些类似于XML,除了XML标准中的XML定义外,每个行业都有自己标准的DTD或DOM定义,用户也可以自扩展;也如同XML,在LDAP中也鼓励用户尽量使用标准的Schema,以增强信息的互联互通。
在Schema中最难理解的是匹配规则,这是LDAP中为了加快查询的速度,针对不同的数据类型,可以提供不同的匹配方法,如针对字符串类型的相等、模糊、大于小于均提供自己的匹配规则。
命名模型:描述LDAP中的数据如何组织
LDAP中的命名模型,也即LDAP中的条目定位方式。在LDAP中每个条目均有自己的DN和RDN。DN是该条目在整个树中的唯一名称标识,RDN是条目在父节点下的唯一名称标识,如同文件系统中,带路径的文件名就是DN,文件名就是RDN。
功能模型:描述LDAP中的数据操作访问
在LDAP中共有四类10种操作:查询类操作,如搜索、比较;更新类操作,如添加条目、删除条目、修改条目、修改条目名;认证类操作,如绑定、解绑定;其它操作,如放弃和扩展操作。除了扩展操作,另外9种是LDAP的标准操作;扩展操作是LDAP中为了增加新的功能,提供的一种标准的扩展框架,当前已经成为LDAP标准的扩展操作,有修改密码和StartTLS扩展,在新的RFC标准和草案中正在增加一些新的扩展操作,不同的LDAP厂商也均定义了自己的扩展操作。
安全模型:描述LDAP中的安全机制
LDAP中的安全模型主要通过身份认证、安全通道和访问控制来实现。
1.身份认证
在LDAP中提供三种认证机制,即匿名、基本认证和SASL(Simple Authentication and Secure Layer)认证。匿名认证即不对用户进行认证,该方法仅对完全公开的方式适用;基本认证均是通过用户名和密码进行身份识别,又分为简单密码和摘要密码认证;SASL认证即LDAP提供的在SSL和TLS安全通道基础上进行的身份认证,包括数字证书的认证。
2.通讯安全
在LDAP中提供了基于SSL/TLS的通讯安全保障。SSL/TLS是基于PKI信息安全技术,是目前Internet上广泛采用的安全服务。LDAP通过StartTLS方式启动TLS服务,可以提供通讯中的数据保密性、完整性保护;通过强制客户端证书认证的TLS服务,同时可以实现对客户端身份和服务器端身份的双向验证。
3.访问控制
虽然LDAP目前并无访问控制的标准,但从一些草案中或是事实上LDAP产品的访问控制情况,我们不难看出:LDAP访问控制异常的灵活和丰富,在LDAP中是基于访问控制策略语句来实现访问控制的,这不同于现有的关系型数据库系统和应用系统,它是通过基于访问控制列表来实现的,无论是基于组模式或角色模式,都摆脱不了这种限制。
在使用关系型数据库系统开发应用时,往往是通过几个固定的数据库用户名访问数据库。对于应用系统本身的访问控制,通常是需要建立专门的用户表,在应用系统内开发针对不同用户的访问控制授权代码,这样一旦访问控制策略变更时,往往需要代码进行变更。总之一句话,关系型数据库的应用中用户数据管理和数据库访问标识是分离的,复杂的数据访问控制需要通过应用来实现。而对于LDAP,用户数据管理和访问标识是一体的,应用不需要关心访问控制的实现。这是由于在LDAP中的访问控制语句是基于策略语句来实现的,无论是访问控制的数据对象,还是访问控制的主体对象,均是与这些对象在树中的位置和对象本身的数据特征相关。
在LDAP中,可以把整个目录、目录的子树、制定条目、特定条目属性集或符合某过滤条件的条目作为控制对象进行授权;可以把特定用户、属于特定组或所有目录用户作为授权主体进行授权;最后,还可以定义对特定位置(例如IP地址或DNS名称)的访问权。
LDAP - 数据结构
LDAP是实现了指定的数据结构的存贮,它包括以下可以用关系数据库实现的结构要求:树状组织、条目认证、类型定义、许可树形记录拷贝。
树状组织
无论是X500还是LDAP都是采用树状方式进行记录。每一个树目录都有一个树根的入口条目,子记录全部是这一根条目的子孙。这是目录与关系数据类型最大的区别(关系数据库的应用结构也可实现树状记录)。因此,把目录看作是更高级的树状数据库也未尝不可,只不过除此外,它不能实现关系存贮的重要功能。
条目和条目认证
LDAP是以条目作为认证的根据。ROOT的权限认证与目录本身无关,但除此外所有条目的认证权限由条目本身的密码进行认证。LDAP可以配置成各种各样不同的父子条目权限继承方式。
每一个条目相当于一个单一的平面文本记录,由条目自身或指定的条目认证进行访问控制。因此,LDAP定义的存贮结构等同于一批树状组织的平面数据库,并提供相应的访问控制。
条目中的记录以名-值对的形式存在,每一个名值对必须由数据样式schema预定义。因此,LDAP可以看作是以规定的值类型以名值对形式存贮在一系列以树状组织的平面数据库的记录的集合。
数据样式
数据样式schema是针对不同的应用,由用户指定(设计)类和属性类型预定义,条目中的类(objectclass)和属性必须在在LDAP服务器启动时载入内存的schema已有定义。因此,AD活动目录中的条目记录就必须符合Active Directory的schema中。如果已提供的schema中的定义不够用,用户可以自行定义新的schema。
对象类型
因为LDAP目录可以定制成存储任何文本或二进制数据,到底存什么要由用户自己决定。LDAP目录用对象类型(objectclass)的概念来定义运行哪一类的对象使用什么属性。在几乎所有的LDAP服务器中,都要根据自己的需要扩展基本的LDAP目录的功能,创建新的对象类型或者扩展现存的对象类型。
条目中的记录通过objectclass实现分类,objectClass是一个继承性的类定义,每一个类定义指定必须具备的属性。如某一条目指定必须符合某个类型,则它必须具备超类所指定的属性。
通过objectclass分类,分散的条目中的记录就实际上建立了一个索引结构,为高速的读查询打下了基础。Objectclass也是过滤器的主要查询对象。
过滤器和语法
LDAP是一个查询为主的记录结构,无论是何种查询方式,最终都由过滤器缺点查询的条件。过滤器相当于SQL中的WHERE子句。任何LDAP的类过滤和字符串都必须放在括号内,如(objectclass=*),指列出所有类型的记录。
基本 LDAP 语法
• =(等于)
此 LDAP 参数表明某个属性等于某个值的条件得到满足。例如,如果希望查找“名“属性为“John”的所有对象,可以使用:
(givenName=John)
这会返回“名”属性为“John”的所有对象。圆括号是必需的,以便强调 LDAP 语句的开始和结束。
• &(逻辑与)
如果具有多个条件并且希望全部条件都得到满足,则可使用此语法。例如,如果希望查找居住在 Dallas 并且“名”为“John”的所有人员,可以使用:
(&(givenName=John)(l=Dallas))
请注意,每个参数都被属于其自己的圆括号括起来。整个 LDAP 语句必须包括在一对主圆括号中。操作符 & 表明,只有每个参数都为真,才会将此筛选条件应用到要查询的对象。
• !(逻辑非)
此操作符用来排除具有特定属性的对象。假定需要查找“名”为“John”的对象以外的所有对象。则应使用如下语句:
(!givenName=John)
此语句将查找“名”不为“John”的所有对象。请注意:! 操作符紧邻参数的前面,并且位于参数的圆括号内。由于本语句只有一个参数,因此使用圆括号将其括起以示说明。
• *(通配符)
可使用通配符表示值可以等于任何值。使用它的情况可能是:希望查找具有职务头衔的所有对象。为此,可以使用:
(title=*)
这会返回“title”属性包含内容的所有对象。另一个例子是:知道某个对象的“名”属性的开头两个字母是“Jo”。那么,可以使用如下语法进行查找:
(givenName=Jo*)
这会返回“名”以“Jo”开头的所有对象。
LDAP - 典型应用
由于LDAP所具有的查询效率高、树状的信息管理模式、分布式的部署框架以及灵活而细腻的访问控制,使LDAP广泛地应用于基础性、关键性信息的管理,如用户信息、网络资源信息等。LDAP的应用主要涉及几种类型。
信息安全类:数字证书管理、授权管理、单点登录;
科学计算类:DCE (Distributed Computing Envirionment,分布式计算环境)、UDDI (Universal Description,Discovery and Integration, 统一描述、发现和集成协议);
网络资源管理类:MAIL系统、DNS系统、网络用户管理、电话号码簿;电子政务
资源管理类:内网组织信息服务、电子政务目录体系、人口基础库、法人基础库。
LDAP提供很复杂的不同层次的访问控制或者ACI。因这些访问可以在服务器端控制,这比用客户端的软件保证数据的安全可安全多了。例如使用用LDAP的ACL,可以完成:
1. 给予用户改变他们自己的电话号码和家庭地址的权限,但是限制他们对其它数据(如,职务名称,登录名等)只有“只读”权限。
2. 给予“HR-admins”组中的所有人权限以改变下面这些用户的信息:经理、工作名称、员工号、部门名称和部门号。但是对其它域没有写权限。
3. 禁止任何人查询LDAP服务器上的用户口令,但是可以允许用户改变他自己的口令。
4. 给予经理访问他们上级的家庭电话的只读权限,但是禁止其他人有这个权限。
5. 给予“host-admins”组中的任何人创建、删除和编辑所有保存在LDAP服务器中的与计算机主机有关的信息
6. 通过Web,允许“foobar-sales”组中的成员有选择地给予或禁止他们自己读取一部分客户联系数据的读权限。这将允许他们把客户联系信息下载到本地的笔记本电脑或个人数字助理(PDA)上。
7. 通过Web,允许组的所有者删除或添加他们拥有的组的成员。例如:可以允许销售经理给予或禁止销售人员改变Web 页的权限。也可以允许邮件别名(mail aliase)的所有者不经过IT技术人员就直接从邮件别名中删除或添加用户。
8. “公用”的邮件列表应该允许用户从邮件假名中添加或删除自己(但是只能是自己)。也可以对IP地址或主机名加以限制。例如,某些域只允许用户IP地址以192.168.200.*开头的有读的权限,或者用户反向查找DNS得到的主机名必须为*.foobar.com。
LDAP - 与X.500的比较
从目录服务技术的发展来看,LDAP标准实际上是在X.500标准基础上产生的一个简化版本,两者之间的关系与那种为解决同一个问题出现的两个独立发展的技术有很大的不同之处,因此需要在此基础上对这两个标准进行理解和分析。
首先,作为IETF(Internet Engineering Task Force)一个正式的标准,LDAP是X.500标准中的目录访问协议DAP的一个子集,可用于建立X.500目录。因此这两个目录服务技术标准有着许多的共同之处,即在平台上,都实现了一个通用的平台结构,提供了一个操作系统和应用程序需要的信息服务类型,可以被许多平台和应用程序接收和实现;在信息模型上,都使用了项、对象类、属性等概念和模式来描述信息;在命名空间方面,都使用了目录信息树结构和层次命名模型;在功能模型上,都使用了相似的操作命令来管理目录信息;在认证框架方面,都可以实现用户名称和密码,或者基于安全加密方式的认证机制;在灵活性上,它们的目录规模都可大可小,大到全球目录树,小到只有一台目录服务器;在分布性方面,目录信息都可以分布在多个目录服务器中,这些服务器可以由各组织管理,既保证了目录信息总体结构一致性,又满足了分级管理的需要。
LDAP与X.500的DAP相同之处是,LDAP也是被设计用来从分层目录中提取信息。但与之不同的是,为保持网络的带宽, LDAP对来自X.500目录询问的应答次数加以限制。最初LDAP只是一种访问X.500目录的简单方法,是X.500的功能子集,但随着它的成熟和独立发展,已经增加了许多在X.500中没有的新特性。现在的LDAP既可以为X.500目录服务提供一个轻型前端,也可以实现一个独立的目录服务。
LDAP的独特之处主要表现在如下几个方面:
1. AP(Access Protocol)既是一个X.500的访问协议,又是一个灵活的可以独立实现的目录系统。
2. DAP(Directory Access Protocol)基于Internet协议,X.500基于OSI(开放式系统互联)协议:建立在应用层上的X.500 目录访问协议DAP,需要在OSI会话层和表示层上进行许多的建立连接和包处理的任务,需要特殊的网络软件实现对网络的访问;LDAP则直接运行在更简单和更通用的TCP/IP或其它可靠的传输协议层上,避免了在OSI会话和表示层的开销,使连接的建立和包的处理更简单、更快,对于互联网和企业网应用更理想。
3. LDAP协议更为简单:LDAP继承了X.500最好的特性,同时去掉了它的复杂性。LDAP通过使用查找操作实现列表操作和读操作,另一方面省去了X.500中深奥的和很少使用的服务控制和安全特性,只保留常用的特性,简化了LDAP的实现。
4. LDAP通过引用机制实现分布式访问:X.500 DSA通过服务器之间的链操作实现分布式的访问,这样查询的压力集中于服务器端;而LDAP通过客户端API实现分布式操作(对于应用透明)平衡了负载;
5. LDAP实现具有低费用、易配置和易管理的特点。经过性能测试,LDAP比X.500具有更少的响应时间;LDAP提供了满足应用程序对目录服务所需求的特性。
LDAP - 优势
LDAP目录的优势
如果需要开发一种提供公共信息查询的系统一般的设计方法可能是采用基于WEB的数据库设计方式,即前端使用浏览器而后端使用WEB服务器加上关系数据库。后端在Windows的典型实现可能是Windows NT + IIS + Acess数据库或者是SQL服务器,IIS和数据库之间通过ASP技术使用ODBC进行连接,达到通过填写表单查询数据的功能;
后端在Linux系统的典型实现可能是Linux+ Apache + postgresql,Apache 和数据库之间通过PHP3提供的函数进行连接。使用上述方法的缺点是后端关系数据库的引入导致系统整体的性能降低和系统的管理比较繁琐,因为需要不断的进行数据类型的验证和事务的完整性的确认;并且前端用户对数据的控制不够灵活,用户权限的设置一般只能是设置在表一级而不是设置在记录一级。
目录服务的推出主要是解决上述数据库中存在的问题。目录与关系数据库相似,是指具有描述性的基于属性的记录集合,但它的数据类型主要是字符型,为了检索的需要添加了BIN (二进制数据)、CIS(忽略大小写)、CES(大小写敏感)、TEL(电话型)等语法(Syntax),而不是关系数据库提供的整数、浮点数、日期、货币等类型,同样也不提供象关系数据库中普遍包含的大量的函数,它主要面向数据的查询服务(查询和修改操作比一般是大于10:1),不提供事务的回滚(rollback)机制,它的数据修改使用简单的锁定机制实现All-or-Nothing,它的目标是快速响应和大容量查询并且提供多目录服务器的信息复制功能。
现在该说说LDAP目录到底有些什么优势了。现在LDAP的流行是很多因数共同作用的结果。可能LDAP最大的优势是:可以在任何计算机平台上,用很容易获得的而且数目不断增加的LDAP的客户端程序访问LDAP目录。而且也很容易定制应用程序为它加上LDAP的支持。
LDAP协议是跨平台的和标准的协议,因此应用程序就不用为LDAP目录放在什么样的服务器上操心了。实际上,LDAP得到了业界的广泛认可,因为它是Internet的标准。产商都很愿意在产品中加入对LDAP的支持,因为他们根本不用考虑另一端(客户端或服务端)是怎么样的。LDAP服务器可以是任何一个开发源代码或商用的LDAP目录服务器(或者还可能是具有LDAP界面的关系型数据库),因为可以用同样的协议、客户端连接软件包和查询命令与LDAP服务器进行交互。与LDAP不同的是,如果软件产商想在软件产品中集成对DBMS的支持,那么通常都要对每一个数据库服务器单独定制。不象很多商用的关系型数据库,你不必为LDAP的每一个客户端连接或许可协议付费 大多数的LDAP服务器安装起来很简单,也容易维护和优化。
LDAP服务器可以用“推”或“拉”的方法复制部分或全部数据,例如:可以把数据“推”到远程的办公室,以增加数据的安全性。复制技术是内置在LDAP服务器中的而且很容易配置。如果要在DBMS中使用相同的复制功能,数据库产商就会要你支付额外的费用,而且也很难管理。
LDAP允许你根据需要使用ACI(一般都称为ACL或者访问控制列表)控制对数据读和写的权限。例如,设备管理员可以有权改变员工的工作地点和办公室号码,但是不允许改变记录中其它的域。ACI可以根据谁访问数据、访问什么数据、数据存在什么地方以及其它对数据进行访问控制。因为这些都是由LDAP目录服务器完成的,所以不用担心在客户端的应用程序上是否要进行安全检查。
LDAP(Lightweight Directory Acess Protocol)是目录服务在TCP/IP上的实现(RFC 1777 V2版和RFC 2251
V3版)。它是对X500的目录协议的移植,但是简化了实现方法,所以称为轻量级的目录服务。在LDAP中目录是按照树型结构组织,目录由条目(Entry)组成,条目相当于关系数据库中表的记录;条目是具有区别名DN(Distinguished
Name)的属性(Attribute)集合,DN相当于关系数据库表中的关键字(Primary
Key);属性由类型(Type)和多个值(Values)组成,相当于关系数据库中的域(Field)由域名和数据类型组成,只是为了方便检索的需要,LDAP中的Type可以有多个Value,而不是关系数据库中为降低数据的冗余性要求实现的各个域必须是不相关的。LDAP中条目的组织一般按照地理位置和组织关系进行组织,非常的直观。LDAP把数据存放在文件中,为提高效率可以使用基于索引的文件数据库,而不是关系数据库。LDAP协议集还规定了DN的命名方法、存取控制方法、搜索格式、复制方法、URL格式、开发接口等
LDAP对于这样存储这样的信息最为有用,也就是数据需要从不同的地点读取,但是不需要经常更新。
例如,这些信息存储在LDAP目录中是十分有效的:
l 公司员工的电话号码簿和组织结构图
l 客户的联系信息
l 计算机管理需要的信息,包括NIS映射、email假名,等等
l 软件包的配置信息
l 公用证书和安全密匙
什么时候该用LDAP存储数据
大多数的LDAP服务器都为读密集型的操作进行专门的优化。因此,当从LDAP服务器中读取数据的时候会比从专门为OLTP优化的关系型数据库中读取数据快一个数量级。也是因为专门为读的性能进行优化,大多数的LDAP目录服务器并不适合存储需要需要经常改变的数据。例如,用LDAP服务器来存储电话号码是一个很好的选择,但是它不能作为电子商务站点的数据库服务器。
如果下面每一个问题的答案都是“是”,那么把数据存在LDAP中就是一个好主意。
l 需要在任何平台上都能读取数据吗?
l 每一个单独的记录项是不是每一天都只有很少的改变?
l 可以把数据存在平面数据库(flat database)而不是关系型数据库中吗?换句话来说,也就是不管什么范式不范式的,把所有东西都存在一个记录中(差不多只要满足第一范式)。
最后一个问题可能会唬住一些人,其实用平面数据库去存储一些关系型的数据也是很一般的。例如,一条公司员工的记录就可以包含经理的登录名。用LDAP来存储这类信息是很方便的。一个简单的判断方法:如果可以把保数据存在一张张的卡片里,就可以很容易地把它存在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目录树的结构
LDAP目录以树状的层次结构来存储数据。如果你对自顶向下的DNS树或UNIX文件的目录树比较熟悉,也就很容易掌握LDAP目录树这个概念了。就象DNS的主机名那样,LDAP目录记录的标识名(Distinguished Name,简称DN)是用来读取单个记录,以及回溯到树的顶部。后面会做详细地介绍。
为什么要用层次结构来组织数据呢?原因是多方面的。下面是可能遇到的一些情况:
l 如果你想把所有的美国客户的联系信息都“推”到位于到西雅图办公室(负责营销)的LDAP服务器上,但是你不想把公司的资产管理信息“推”到那里。
l 你可能想根据目录树的结构给予不同的员工组不同的权限。在下面的例子里,资产管理组对“asset-mgmt"部分有完全的访问权限,但是不能访问其它地方。
l 把LDAP存储和复制功能结合起来,可以定制目录树的结构以降低对WAN带宽的要求。位于西雅图的营销办公室需要每分钟更新的美国销售状况的信息,但是欧洲的销售情况就只要每小时更新一次就行了。
刨根问底:基准DN
LDAP目录树的最顶部就是根,也就是所谓的“基准DN"。基准DN通常使用下面列出的三种格式之一。假定我在名为FooBar的电子商务公司工作,这家公司在Internet上的名字是foobar.com。
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。
定制目录的对象类型
你可以用LDAP存储各种类型的数据对象,只要这些对象可以用属性来表示,下面这些是可以在LDAP中存储的一些信息:
l 员工信息:员工的姓名、登录名、口令、员工号、他的经理的登录名,邮件服务器,等等。
l 物品跟踪信息:计算机名、IP地址、标签、型号、所在位置,等等。
l 客户联系列表:客户的公司名、主要联系人的电话、传真和电子邮件,等等。
l 会议厅信息:会议厅的名字、位置、可以坐多少人、电话号码、是否有投影机。
l 食谱信息:菜的名字、配料、烹调方法以及准备方法。
因为LDAP目录可以定制成存储任何文本或二进制数据,到底存什么要由你自己决定。LDAP目录用对象类型(object classes)的概念来定义运行哪一类的对象使用什么属性。在几乎所有的LDAP服务器中,你都要根据自己的需要扩展基本的LDAP目录的功能,创建新的对象类型或者扩展现存的对象类型。
LDAP目录以一系列“属性对”的形式来存储记录项,每一个记录项包括属性类型和属性值(这与关系型数据库用行和列来存取数据有根本的不同)。下面是我存在LDAP目录中的一部分食谱记录:
dn: cn=Oatmeal Deluxe, ou=recipes, dc=foobar, dc=com
cn: Instant Oatmeal Deluxe
recipeCuisine: breakfast
recipeIngredient: 1 packet instant oatmeal
recipeIngredient: 1 cup water
recipeIngredient: 1 pinch salt
recipeIngredient: 1 tsp brown sugar
recipeIngredient: 1/4 apple, any type
请注意上面每一种配料都作为属性recipeIngredient值。LDAP目录被设计成象上面那样为一个属性保存多个值的,而不是在每一个属性的后面用逗号把一系列值分开。
因为用这样的方式存储数据,所以数据库就有很大的灵活性,不必为加入一些新的数据就重新创建表和索引。更重要的是,LDAP目录不必花费内存或硬盘空间处理“空”域,也就是说,实际上不使用可选择的域也不会花费你任何资源。
作为例子的一个单独的数据项
让我们看看下面这个例子。我们用Foobar, Inc.的员工Fran Smith的LDAP记录。这个记录项的格式是LDIF,用来导入和导出LDAP目录的记录项。
dn: uid=fsmith, ou=employees, dc=foobar, dc=com
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: foobarPerson
uid: fsmith
givenname: Fran
sn: Smith
cn: Fran Smith
cn: Frances Smith
telephonenumber: 510-555-1234
roomnumber: 122G
o: Foobar, Inc.
mailRoutingAddress: fsmith@foobar.commailhost: mail.foobar.com
userpassword: 3x1231v76T89N
uidnumber: 1234
gidnumber: 1200
homedirectory: /home/fsmith
loginshell: /usr/local/bin/bash
属性的值在保存的时候是保留大小写的,但是在默认情况下搜索的时候是不区分大小写的。某些特殊的属性(例如,password)在搜索的时候需要区分大小写。
让我们一点一点地分析上面的记录项。
dn: uid=fsmith, ou=employees, dc=foobar, dc=com
这是Fran的LDAP记录项的完整DN,包括在目录树中的完整路径。LDAP(和X.500)使用uid(User ID),不要把它和UNIX的uid号混淆了。
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: foobarPerson
可以为任何一个对象根据需要分配多个对象类型。person对象类型要求cn(common name)和sn(surname)这两个域不能为空。persion对象类型允许有其它的可选域,包括givenname、 telephonenumber,等等。organizational Person给person加入更多的可选域,inetOrgPerson又加入更多的可选域(包括电子邮件信息)。最后,foobarPerson是为 Foobar定制的对象类型,加入了很多定制的属性。
uid: fsmith
givenname: Fran
sn: Smith
cn: Fran Smith
cn: Frances Smith
telephonenumber: 510-555-1234
roomnumber: 122G
o: Foobar, Inc.
以前说过了,uid表示User ID。当看到uid的时候,就在脑袋里想一想“login"。
请注意CN有多个值。就象上面介绍的,LDAP允许某些属性有多个值。为什么允许有多个值呢?假定你在用公司的LDAP服务器查找Fran 的电话号码。你可能只知道她的名字叫Fran,但是对人力资源处的人来说她的正式名字叫做Frances。因为保存了她的两个名字,所以用任何一个名字检索都可以找到Fran的电话号码、电子邮件和办公房间号,等等。
mailRoutingAddress: fsmith@foobar.commailhost: mail.foobar.com
就象现在大多数的公司都上网了,Foobar用Sendmail发送邮件和处理外部邮件路由信息。Foobar把所有用户的邮件信息都存在LDAP中。最新版本的Sendmail支持这项功能。
Userpassword: 3x1231v76T89N
uidnumber: 1234
gidnumber: 1200
gecos: Frances Smith
homedirectory: /home/fsmith
loginshell: /usr/local/bin/bash
LDAP -
Foobar的系统管理员把所有用户的口令映射信息也都存在LDAP中。FoobarPerson类型的对象具有这种能力。再注意一下,用户口令是用UNIX的口令加密格式存储的。UNIX的uid在这里为uidnumber。提醒你一下,关于如何在LDAP中保存NIS信息,有完整的一份RFC。在以后的文章中我会谈一谈NIS的集成。
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目录服务器为他们完成了所有的数据交换工作。