什么是LDAPWord格式.docx

什么是LDAPWord格式.docx

《什么是LDAPWord格式.docx》由会员分享，可在线阅读，更多相关《什么是LDAPWord格式.docx（10页珍藏版）》请在冰豆网上搜索。

不象很多商用的关系型数据库，你不必为LDAP的每一个客户端连接或许可协议付费大多数的LDAP服务器安装起来很简单，也容易维护和优化。

LDAP服务器可以用“推”或“拉”的方法复制部分或全部数据，例如：

可以把数据“推”到远程的办公室，以增加数据的安全性。

复制技术是内置在LDAP服务器中的而且很容易配置。

如果要在DBMS中使用相同的复制功能，数据库产商就会要你支付额外的费用，而且也很难管理。

LDAP允许你根据需要使用ACI（一般都称为ACL或者访问控制列表）控制对数据读和写的权限。

例如，设备管理员可以有权改变员工的工作地点和办公室号码，但是不允许改变记录中其它的域。

ACI可以根据谁访问数据、访问什么数据、数据存在什么地方以及其它对数据进行访问控制。

因为这些都是由LDAP目录服务器完成的，所以不用担心在客户端的应用程序上是否要进行安全检查。

LDAP（LightweightDirectoryAcessProtocol）是目录服务在TCP/IP上的实现（RFC1777V2版和RFC2251V3版）。

它是对X500的目录协议的移植，但是简化了实现方法，所以称为轻量级的目录服务。

在LDAP中目录是按照树型结构组织，目录由条目（Entry）组成，条目相当于关系数据库中表的记录；

条目是具有区别名DN（DistinguishedName）的属性（Attribute）集合，DN相当于关系数据库表中的关键字（PrimaryKey）；

属性由类型（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可以把数据存在平面数据库（flatdatabase）而不是关系型数据库中吗？

换句话来说，也就是不管什么范式不式的，把所有东西都存在一个记录中（差不多只要满足第一范式）。

最后一个问题可能会唬住一些人，其实用平面数据库去存储一些关系型的数据也是很一般的。

例如，一条公司员工的记录就可以包含经理的登录名。

用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页的权限。

也可以允许邮件假名（mailaliase）的所有者不经过IT技术人员就直接从邮件假名中删除或添加用户。

“公用”的邮件列表应该允许用户从邮件假名中添加或删除自己（但是只能是自己）。

也可以对IP地址或主机名加以限制。

例如，某些域只允许用户IP地址以192.168.200.*开头的有读的权限，或者用户反向查找DNS得到的主机名必须为*。

LDAP目录树的结构 

LDAP目录以树状的层次结构来存储数据。

如果你对自顶向下的DNS树或UNIX文件的目录树比较熟悉，也就很容易掌握LDAP目录树这个概念了。

就象DNS的主机名那样，LDAP目录记录的标识名（DistinguishedName，简称DN）是用来读取单个记录，以及回溯到树的顶部。

后面会做详细地介绍。

为什么要用层次结构来组织数据呢？

原因是多方面的。

下面是可能遇到的一些情况：

l如果你想把所有的美国客户的联系信息都“推”到位于到西雅图办公室（负责营销）的LDAP服务器上，但是你不想把公司的资产管理信息“推”到那里。

l你可能想根据目录树的结构给予不同的员工组不同的权限。

在下面的例子里，资产管理组对“asset-mgmt"

部分有完全的访问权限，但是不能访问其它地方。

l把LDAP存储和复制功能结合起来，可以定制目录树的结构以降低对WAN带宽的要求。

位于西雅图的营销办公室需要每分钟更新的美国销售状况的信息，但是欧洲的销售情况就只要每小时更新一次就行了。

刨根问底：

基准DN 

LDAP目录树的最顶部就是根，也就是所谓的“基准DN"

。

基准DN通常使用下面列出的三种格式之一。

假定我在名为FooBar的电子商务公司工作，这家公司在Internet上的名字是。

o="

FooBar,Inc."

c=US（以X.500格式表示的基准DN）在这个例子中o=FooBar,Inc.表示组织名，在这里就是公司名的同义词。

c=US表示公司的总部在美国。

以前，一般都用这种方式来表示基准DN。

但是事物总是在不断变化的，现在所有的公司都已经（或计划）上Internet上。

随着 

Internet的全球化，在基准DN中使用国家代码很容易让人产生混淆。

现在，X.500格式发展成下面列出的两种格式。

o= 

（用公司的Internet地址表示的基准DN） 

这种格式很直观，用公司的域名作为基准DN。

这也是现在最常用的格式。

dc=foobar,dc=com 

（用DNS域名的不同部分组成的基准DN） 

就象上面那一种格式，这种格式也是以DNS域名为基础的，但是上面那种格式不改变域名（也就更易读），而这种格式把域名：

分成两部分dc=foobar,dc=com。

在理论上，这种格式可能会更灵活一点，但是对于最终用户来说也更难记忆一点。

考虑一下这个例子。

当和合并之后，可以简单的把“dc=com"

当作基准DN。

把新的记录放到已经存在的dc=gizmo,dc=com目录下，这样就简化了很多工作（当然，如果和wocket.edu合并，这个方法就不能用了）。

如果LDAP服务器是新安装的，我建议你使用这种格式。

再请注意一下，如果你打算使用活动目录（ActriveDirectory），Microsoft已经限制你必须使用这种格式。

更上一层楼：

在目录树中怎么组织数据 

在UNIX文件系统中，最顶层是根目录（root）。

在根目录的下面有很多的文件和目录。

象上面介绍的那样，LDAP目录也是用同样的方法组织起来的。

在根目录下，要把数据从逻辑上区分开。

因为历史上（X.500）的原因，大多数LDAP目录用OU从逻辑上把数据分开来。

OU 

表示“OrganizationUnit"

，在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目录中的所有记录项都有一个唯一的“DistinguishedName"

，也就是DN。

每一个LDAP记录项的DN是由两个部分组成的：

相对DN（RDN）和记录在LDAP目录中的位置。

RDN是DN中与目录树的结构无关的部分。

在LDAP目录中存储的记录项都要有一个名字，这个名字通常存在cn（CommonName）这个属性里。

因为几乎所有的东西都有一个名字，在LDAP中存储的对象都用它们的cn值作为RDN的基础。

如果我把最喜欢的吃燕麦粥食谱存为一个记录，我就会用cn=OatmealDeluxe作为记录项的RDN。

l我的LDAP目录的基准DN是dc=foobar,dc=com 

l我把自己的食谱作为LDAP的记录项存在ou=recipes 

l我的LDAP记录项的RDN设为cn=OatmealDeluxe 

上面这些构成了燕麦粥食谱的LDAP记录的完整DN。

记住，DN的读法和DNS主机名类似。

下面就是完整的DN：

cn=OatmealDeluxe,ou=recipes,dc=foobar,dc=com 

举一个实际的例子来说明DN 

现在为公司的员工设置一个DN。

可以用基于cn或uid（UserID），作为典型的用户帐号。

例如，FooBar的员工FranSmith（登录名：

fsmith）的DN可以为下面两种格式：

uid=fsmith,ou=employees,dc=foobar,dc=com 

（基于登录名） 

LDAP（以及X.500）用uid表示“UserID"

，不要把它和UNIX的uid号混淆了。

大多数公司都会给每一个员工唯一的登录名，因此用这个办法可以很好地保存员工的信息。

你不用担心以后还会有一个叫FranSmith的加入公司，如果Fran改变了她的名字（结婚？

离婚？

或宗教原因？

），也用不着改变LDAP记录项的DN。

cn=FranSmith,ou=employees,dc=foobar,dc=com 

（基于姓名） 

可以看到这种格式使用了CommonName（CN）。

可以把CommonName当成一个人的全名。

这种格式有一个很明显的缺点就是：

如果名字改变了，LDAP的记录就要从一个DN转移到另一个DN。

但是，我们应该尽可能地避免改变一个记录项的DN。

定制目录的对象类型 

你可以用LDAP存储各种类型的数据对象，只要这些对象可以用属性来表示，下面这些是可以在LDAP中存储的一些信息：

l员工信息：

员工的姓名、登录名、口令、员工号、他的经理的登录名，邮件服务器，等等。

l物品跟踪信息：

计算机名、IP地址、标签、型号、所在位置，等等。

l客户联系列表：

客户的公司名、主要联系人的电话、传真和电子邮件，等等。

l会议厅信息：

会议厅的名字、位置、可以坐多少人、电话号码、是否有投影机。

l食谱信息：

菜的名字、配料、烹调方法以及准备方法。

因为LDAP目录可以定制成存储任何文本或二进制数据，到底存什么要由你自己决定。

LDAP目录用对象类型（objectclasses）的概念来定义运行哪一类的对象使用什么属性。

在几乎所有的LDAP服务器中，你都要根据自己的需要扩展基本的LDAP目录的功能，创建新的对象类型或者扩展现存的对象类型。

LDAP目录以一系列“属性对”的形式来存储记录项，每一个记录项包括属性类型和属性值（这与关系型数据库用行和列来存取数据有根本的不同）。

下面是我存在LDAP目录中的一部分食谱记录：

dn:

cn=OatmealDeluxe,ou=recipes,dc=foobar,dc=com 

cn:

InstantOatmealDeluxe 

recipeCuisine:

breakfast 

recipeIngredient:

1packetinstantoatmeal 

1cupwater 

1pinchsalt 

1tspbrownsugar 

1/4apple,anytype 

请注意上面每一种配料都作为属性recipeIngredient值。

LDAP目录被设计成象上面那样为一个属性保存多个值的，而不是在每一个属性的后面用逗号把一系列值分开。

因为用这样的方式存储数据，所以数据库就有很大的灵活性，不必为加入一些新的数据就重新创建表和索引。

更重要的是，LDAP目录不必花费内存或硬盘空间处理“空”域，也就是说，实际上不使用可选择的域也不会花费你任何资源。

作为例子的一个单独的数据项 

让我们看看下面这个例子。

我们用Foobar,Inc.的员工FranSmith的LDAP记录。

这个记录项的格式是LDIF，用来导入和导出LDAP目录的记录项。

uid=fsmith,ou=employees,dc=foobar,dc=com 

objectclass:

person 

organizationalPerson 

inetOrgPerson 

foobarPerson 

uid:

fsmith 

givenname:

Fran 

sn:

Smith 

FranSmith 

FrancesSmith 

telephonenumber:

510-555-1234 

roomnumber:

122G 

o:

Foobar,Inc. 

mailRoutingAddress:

fsmith@ 

mailhost:

userpassword:

{crypt}3x1231v76T89N 

uidnumber:

1234 

gidnumber:

1200 

homedirectory:

/home/fsmith 

loginshell:

/usr/local/bin/bash 

属性的值在保存的时候是保留大小写的，但是在默认情况下搜索的时候是不区分大小写的。

某些特殊的属性（例如，password）在搜索的时候需要区分大小写。

让我们一点一点地分析上面的记录项。

dn:

这是Fran的LDAP记录项的完整DN，包括在目录树中的完整路径。

LDAP（和X.500）使用uid（UserID），不要把它和UNIX的uid号混淆了。

可以为任何一个对象根据需要分配多个对象类型。

person对象类型要求cn（commonname）和sn（surname）这两个域不能为空。

persion对象类型允许有其它的可选域，包括givenname、telephonenumber，等等。

organizationalPerson给person加入更多的可选域，inetOrgPerson又加入更多的可选域（包括电子邮件信息）。

最后，foobarPerson是为Foobar定制的对象类型，加入了很多定制的属性。

以前说过了，uid表示UserID。

当看到uid的时候，就在脑袋里想一想“login"

请注意CN有多个值。

就象上面介绍的，LDAP允许某些属性有多个值。

为什么允许有多个值呢？

假定你在用公司的LDAP服务器查找Fran的电话号码。

你可能只知道她的名字叫Fran，但是对人力资源处的人来说她的正式名字叫做Frances。

因为保存了她的两个名字，所以用任何一个名字检索都可以找到Fran的电话号码、电子邮件和办公房间号，等等。

就象现在大多数的公司都上网了，Foobar用Sendmail发送邮件和处理外部邮件路由信息。

Foobar把所有用户的邮件信息都存在LDAP中。

最新版本的Sendmail支持这项功能。

Userpassword:

gecos:

注意，Foobar的系统管理员把所有用户的口令映射信息也都存在LDAP中。

FoobarPerson类型的对象具有这种能力。

再注意一下，用户口令是用UNIX的口令加密格式存储的。

UNIX的uid在这里为uidnumber。

提醒你一下，关于如何在LDAP中保存NIS信息，有完整的一份RFC。

在以后的文章中我会谈一谈NIS的集成。

LDAP复制 

LDAP服务器可以使用基于“推”或者“拉”的技术，用简单或基于安全证书的安全验证，复制一部分或者所有的数据。

例如，Foob