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。

form：http://www.bloghome.cn/index.php?op=ViewArticle&articleId=2513&blogId=7

<!-- google_ad_client = "pub-9232855773311077"; google_ad_width = 250; google_ad_height = 250; google_ad_format = "250x250_as"; google_ad_type = "text_image"; google_ad_channel =""; google_color_border = "FFFFFF"; google_color_bg = "FFFFFF"; google_color_link = "0000FF"; google_color_url = "666666"; google_color_text = "000000"; //--> <iframe name="google_ads_frame" marginwidth="0" marginheight="0" src="http://pagead2.googlesyndication.com/pagead/ads?client=ca-pub-9232855773311077&amp;dt=1114852795578&amp;format=250x250_as&amp;output=html&amp;color_bg=FFFFFF&amp;color_text=000000&amp;color_link=0000FF&amp;color_url=666666&amp;color_border=FFFFFF&amp;ad_type=text_image&amp;u_h=768&amp;u_w=1024&amp;u_ah=740&amp;u_aw=1024&amp;u_cd=16&amp;u_tz=480&amp;u_his=26&amp;u_java=true" frameborder="0" width="250" scrolling="no" height="250" allowtransparency="65535"></iframe>