设计LDAP目录树
原著：Michael Donnelly
翻译：Beta Xmu/Grind
原文：http://www.ldapman.org/articles/tree_design.html
乍看之下，设计一个LDAP服务器的目录拓扑好像是很麻烦的事。但是只要预先计划一下，那这件事就变得相对简单了。此文中，我们将分别讨论每个你必须考虑的主题：
什么是目录树？它们看起来像什么？
选择你的目录的基准DN
一个目录树的例子
规划你的目录拓扑
这是为sendmail.net关于LDAP这个话题的一系列文章中的第二篇。这个系列作为一个整体将为带着你从“只是看一下”到配置一个可以应用和服务的目录的LDAP基础集的整个过程。这个系列的其它文章可以在http://www.ldapman.or/articles 上找到。你可以看一下“An Introduction to LDAP”
的第一和第二部分，在ldapman.org上也可以找到。
什么是目录树？
简单来说，一个目录树就是一个规定储藏各种不同类型信息的容器的组织方法。你可以把它看做是你的数据的归档系统。
LDAP目录服务器分层保存着它们的信息，和UNIX的文件系统很像。这些层次规定从逻辑上把一定条目的信息分组（或者划分子组）。这些组在许多情况下很有用：
为一个或多个组的数据在其它服务器或站点上授权认证
数据复制
安全和访问控制
可伸缩性
参考下面这个非常简单的目录树的例子。我将任何无关的信息都拿掉了，这样我们就能够把注意力集中在树的本身。
在最上层，我们有个root，这是每个目录树的起点。root下面的是两个类别，每个下面还有两个子类别。注意Employees是按照部门分的，Customers是按照地区分的。如何分组是没有限制的。虽然我在这里只是每层显示了两个组，但是如果你需要的话，你的目录里的任何一层里面都可以有许多组。
选择你的目录基准DN
在开始之前，我要说这里没有一种正确的方法来设置目录结构。你选择的设计可能看起来和其它你看到的相似，下次就可能差别很大。你如果想测试你的目录树的设计，这里有个主要的标准：是否有效的适合你当前的和计划的需要？如果是，你就是正确的。
目录的最顶层，即上面提及得目录树的root，是目录树的基准，也就是所谓的基准标识名（Base Distinguished Name），或者基准DN（base DN）。原则上，你可以选择你的基准DN的格式，我推荐一个当前最流行的格式（你可能需要借这个机会更新对改变基准DN格式的记忆）。
追溯到1998年，RFC2247把DNS域名编码作为LDAP（和X.500）的标识名的基础。从那时起，越来越多的地方使用这种格式。如果你正在计划整合Microsoft Active Directory，这是你唯一能使用的方法，所以不要为选择操心了――Redmond已经为你做好了这个选择。
这种格式是非常简单的。让我们假设你的公司的Intenet域名是foobar.com。RFC2247把这个DNS域名转换为下面的DN：
dc=foobar，dc=com
这个dc指“Domain Component”，注意DNS名字的每个部分都按顺序描述。
那么你的基准DN是什么呢？假设你公司的Internet域名以.com结尾，你最好的选择是dc=com。如果你的Internet域名以.net结尾，那么基准DN使用dc=net。知道这个方法了吗？如果你公司现在或者将来都不会上网，那你可以选择dc=local。
在基准DN下面，你就有一个和你DNS域名剩下部分相应的条目。例如，foobar.com的上几层看起来就像这样：
让我们假设foobar.com公司准备与wocket.com和gizmo.com合并。没问题！感谢你的先知先觉，你的目录结构可以适应在公司命运中的突然变化。你只需要简单的在dc=com下面加入dc=work和dc=gizmo条目。那么你目录的上几层就像这样：
一个目录树的例子
你初始的目录结构越好，以后需要重新修补的就越少。通常来说，你设计你的目录要保证个别的条目不必从一棵树移到另一个棵。你可能会发现一个分布均匀层次较浅的结构工作得最好，树的每个分枝包含的对象根本不太可能移动很多。考虑下面的问题，一个虚构的foobar.com的目录树。他们花一年时间分阶段铺开他们的LDAP目录，渐渐的基于LADP的服务越来越多。
注意每个分支是由ou=的形式组成，OU表示Organizational Unit，在以前X.500时，OU被用来描述你的公司的组织结构。你今天所做好的，但是每次公司部门结构改变时，你不得不重新组织你的目录树，为什么要给自己带来额外的工作呢？相反的，foobar采用了简单的途径：他们把工作关系，部门信息，和类似的数据保存在每个雇员的LDAP条目里。他们依然存储了同样的数据，但是少了很多工作。
ou=employees
foobar.com的所有员工都这里列出。既然随着时间的改变分组方案不可避免要改变，Foobar控制住了任何形式的企图把这个分组方案改变成小组的趋势：人们改变了职位，部门，甚至从一个洲到另一个洲。取而代之，每个员工的位置，部门和公司分配信息都被保存在员工的LDAP条目里，包括email，公共HR信息，和NIS信息。
ou＝ITaccounts
当foobar.com把NIS password和mail路由信息都放到LDAP里时，那将会有一点困惑。你如何处理诸如root，nobody，www等账号呢？像这些的IT accounts共享了许多与员工账号相同的属性（密码，uid和gid，email地址，等等）但是和一般人们有根本上的不同。（你上次是什么时候查找root的电话号码？）为了保持员工信息的唯一性，他们创建一个特别的OU来存放这种账号。LDAP连接控制可以防止非IT职员读到这些数据。
ou＝customers
Foobar.com把他们的顾客联系信息放到LDAP目录里。这样每个雇员都可以查询这个目录来找到顾客的销售报告，支持联系信息，等等。很少有顾客从一个洲移到另一个洲。
当公司成长时，他们可能希望把地域性的服务器之间的信息做个拷贝。因为他们已经把客户的信息分到各个小组里去，所以他们能整理这个拷贝来适应每个站点的销售人员的需要。
ou=locations
常常想知道你New York办公室的地址吗？或者是“Coffe Stain Conference Romm”的电话号码？是不是常被人叫在上午10点去“Scenic View”会议室开会，但你不知道怎么样去找到那个地方？
那么，这样事不会发生在foobar.com的员工身上，他们把所有有关他们的办公室，会议室，和其它类似的信息都放在LDAP目录里。公司的基于LDAP的电话簿可以很快的很简单的提取这些信息。
ou=devices
Foobar同时也决定把他们的计算机，打印机，和其它计算机设备的信息保存在LDAP里面。这也让他们的系统管理员可以把他们网络的每个设备的主机名、IP地址、MAC地址、当前用户和组、标记、系列号、结构型号、操作系统名称版本、位置和描述信息都保存在一个地方。
一个自定义的Web GUI允许系统管理员和公司的资产管理员输入，修改和查询这些信息。一些自定义的脚本可以用来直接从LDAP产生DNS和NIS的主机映射。资产管理工具可以自动定时更新硬件信息，这样你不费吹灰之力也能保证这些信息是最新的。
但是为什么把所有路由器、交换机、打印机、个人电脑、苹果机和UNIX系统信息都放在一个OU里呢？因为他们都共享同类型的信息。一个UNIX服务器和一个打印机有很大不同，但是保存这种类型的信息在本质上是一样的。如果有个问题：“给我所有Windows PCs的列表”，他们就很容易通过OS Name来查询到。
好的，但是如果是这样的问题：“给我所有laptop的列表”？Foobar.com实现了一些自定义的LDAP属性来让他们来跟踪每个设备的“Machine Class”和“Machine SubClass”属性，以提供他们所需要的粒度。“Machine Class”的值包括了Netgear，Printer，Windows，Mac，UNIX。“Machine SubClass”包括了router，switch，inkjet，laser，desktop，laptop，workstation，server。这些类和子类信息的集合可以灵活和精确的在许多情况下跟踪所有的网络设备。
规划你的目录拓扑
现在你可能想知道怎样设计的自己的目录了吧，让我们来看一个例子。在上面的例子里，foobar.com用了五个主要的类别，ou=customers再分成子类。（记住，这只是一个例子，对每个公司来说它不一定是最好的）。实际上，你可能想增加一个类别来处理NIS组的信息，邮件列表信息等等。
那么那些OU适合你呢？我让你看一下设计的过程。毕竟，你正在建立你的LDAP服务器来适应你自己情况的需要。上面的例子应该可以帮助你对如何组织你的数据有个感觉。这儿有一些比较广泛的指导方针来帮助你完成这个过程：
如果有可能，要避免一个不得不修改的目录树设计。设法不要让目录树基于公司组织图，一个当前的商业模式或者相似的东西。
你要避免从一个OU向另一个OU移动LDAP记录。如果你可以预见这会经常发生在你的设计中，设法去重新设计。你能把两个或者更多的分支整合成一个吗？你能用一个属性－location，department－去完成同样的目的吗？
你是否有在某些关系上相似的数据，但是如何使用这些数据却有很大的不同？你能为每种类型的条目创建独立的OU吗？如果条目无论什么理由都没有必要从一个OU移动到另一个OU，那么保持这些组是分开的。（考虑上面的例子，ou＝Employees和ou＝ITaccounts）
如果你要在同一点复制数据，考虑是否你能把一个OU分成按照你用户的需要的子OU。重新考虑这样做是否会导致一个对象从一个OU移动到另一个OU。（在上面的例子里，customers的OU要分类是正常选择，employees的OU则不是）
如果你需要隐藏目录中的一部分数据，不管是为安全原因或者只是简单的防止混淆，你可以用一个OU来做这个事。如果这违反了上面主要方针的任何一条，那么你就不得不判断自己要做什么－安全是棘手的话题，有不同的处理方法。
这儿有一些你可能考虑存放在LDAP目录的数据对象的比较广泛的指导方针。根据你的需要，每个都可以分成单独的OU。
员工信息
顾客信息，新老顾客
当地饭店的电话号码和描述，taxi服务，等等
会议室，办公场所信息，等等
LCD放映机,flip chars,和其它便携式“会议室”设备
计算机：桌面电脑,便携电脑,服务器,打印机,网络设备
邮件列表
NIS group map
NIS netgroup map
看起来很简单吧？但是不要忽略了下面这些：
NIS password map。这个map保存了个别员工的信息。你能够分析这个文件和保存每个用户login name，password，uid和gid numbers，login shell，和home directories作为在ou＝employees和ou＝Itaccounts下的个别的LDAP条目的用户特定的属性。
Organizational charts。Org charts本质上来说反映了每一个员工的job title，manager，department，和（或者）business unit。通过你的org chart和每个员工单独记录的相关信息的分析。你总可以从保存在目录里的一系列managers来得出公司的org chart。
NIS aliases map。Aliases map保护了许多不同类型的信息，个人的mail routing信息和交替的email地址都要作为每个员工的LDAP条目的部分来保存。Mailing list 信息能被保存在自己的OU里，如cetera。我有一整篇文章来描述在LDAP中存放email，所以请耐心等待。
最后，我希望你觉得这篇文章对你有用。如果你有任何意见或者问题，请发email: [email protected]
Michael Donnelly
9 may 2000
翻译：Beta Xmu/Grind
原文：http://www.ldapman.org/articles/tree_design.html
乍看之下，设计一个LDAP服务器的目录拓扑好像是很麻烦的事。但是只要预先计划一下，那这件事就变得相对简单了。此文中，我们将分别讨论每个你必须考虑的主题：
什么是目录树？它们看起来像什么？
选择你的目录的基准DN
一个目录树的例子
规划你的目录拓扑
这是为sendmail.net关于LDAP这个话题的一系列文章中的第二篇。这个系列作为一个整体将为带着你从“只是看一下”到配置一个可以应用和服务的目录的LDAP基础集的整个过程。这个系列的其它文章可以在http://www.ldapman.or/articles 上找到。你可以看一下“An Introduction to LDAP”
的第一和第二部分，在ldapman.org上也可以找到。
什么是目录树？
简单来说，一个目录树就是一个规定储藏各种不同类型信息的容器的组织方法。你可以把它看做是你的数据的归档系统。
LDAP目录服务器分层保存着它们的信息，和UNIX的文件系统很像。这些层次规定从逻辑上把一定条目的信息分组（或者划分子组）。这些组在许多情况下很有用：
为一个或多个组的数据在其它服务器或站点上授权认证
数据复制
安全和访问控制
可伸缩性
参考下面这个非常简单的目录树的例子。我将任何无关的信息都拿掉了，这样我们就能够把注意力集中在树的本身。
在最上层，我们有个root，这是每个目录树的起点。root下面的是两个类别，每个下面还有两个子类别。注意Employees是按照部门分的，Customers是按照地区分的。如何分组是没有限制的。虽然我在这里只是每层显示了两个组，但是如果你需要的话，你的目录里的任何一层里面都可以有许多组。
选择你的目录基准DN
在开始之前，我要说这里没有一种正确的方法来设置目录结构。你选择的设计可能看起来和其它你看到的相似，下次就可能差别很大。你如果想测试你的目录树的设计，这里有个主要的标准：是否有效的适合你当前的和计划的需要？如果是，你就是正确的。
目录的最顶层，即上面提及得目录树的root，是目录树的基准，也就是所谓的基准标识名（Base Distinguished Name），或者基准DN（base DN）。原则上，你可以选择你的基准DN的格式，我推荐一个当前最流行的格式（你可能需要借这个机会更新对改变基准DN格式的记忆）。
追溯到1998年，RFC2247把DNS域名编码作为LDAP（和X.500）的标识名的基础。从那时起，越来越多的地方使用这种格式。如果你正在计划整合Microsoft Active Directory，这是你唯一能使用的方法，所以不要为选择操心了――Redmond已经为你做好了这个选择。
这种格式是非常简单的。让我们假设你的公司的Intenet域名是foobar.com。RFC2247把这个DNS域名转换为下面的DN：
dc=foobar，dc=com
这个dc指“Domain Component”，注意DNS名字的每个部分都按顺序描述。
那么你的基准DN是什么呢？假设你公司的Internet域名以.com结尾，你最好的选择是dc=com。如果你的Internet域名以.net结尾，那么基准DN使用dc=net。知道这个方法了吗？如果你公司现在或者将来都不会上网，那你可以选择dc=local。
在基准DN下面，你就有一个和你DNS域名剩下部分相应的条目。例如，foobar.com的上几层看起来就像这样：
让我们假设foobar.com公司准备与wocket.com和gizmo.com合并。没问题！感谢你的先知先觉，你的目录结构可以适应在公司命运中的突然变化。你只需要简单的在dc=com下面加入dc=work和dc=gizmo条目。那么你目录的上几层就像这样：
一个目录树的例子
你初始的目录结构越好，以后需要重新修补的就越少。通常来说，你设计你的目录要保证个别的条目不必从一棵树移到另一个棵。你可能会发现一个分布均匀层次较浅的结构工作得最好，树的每个分枝包含的对象根本不太可能移动很多。考虑下面的问题，一个虚构的foobar.com的目录树。他们花一年时间分阶段铺开他们的LDAP目录，渐渐的基于LADP的服务越来越多。
注意每个分支是由ou=的形式组成，OU表示Organizational Unit，在以前X.500时，OU被用来描述你的公司的组织结构。你今天所做好的，但是每次公司部门结构改变时，你不得不重新组织你的目录树，为什么要给自己带来额外的工作呢？相反的，foobar采用了简单的途径：他们把工作关系，部门信息，和类似的数据保存在每个雇员的LDAP条目里。他们依然存储了同样的数据，但是少了很多工作。
ou=employees
foobar.com的所有员工都这里列出。既然随着时间的改变分组方案不可避免要改变，Foobar控制住了任何形式的企图把这个分组方案改变成小组的趋势：人们改变了职位，部门，甚至从一个洲到另一个洲。取而代之，每个员工的位置，部门和公司分配信息都被保存在员工的LDAP条目里，包括email，公共HR信息，和NIS信息。
ou＝ITaccounts
当foobar.com把NIS password和mail路由信息都放到LDAP里时，那将会有一点困惑。你如何处理诸如root，nobody，www等账号呢？像这些的IT accounts共享了许多与员工账号相同的属性（密码，uid和gid，email地址，等等）但是和一般人们有根本上的不同。（你上次是什么时候查找root的电话号码？）为了保持员工信息的唯一性，他们创建一个特别的OU来存放这种账号。LDAP连接控制可以防止非IT职员读到这些数据。
ou＝customers
Foobar.com把他们的顾客联系信息放到LDAP目录里。这样每个雇员都可以查询这个目录来找到顾客的销售报告，支持联系信息，等等。很少有顾客从一个洲移到另一个洲。
当公司成长时，他们可能希望把地域性的服务器之间的信息做个拷贝。因为他们已经把客户的信息分到各个小组里去，所以他们能整理这个拷贝来适应每个站点的销售人员的需要。
ou=locations
常常想知道你New York办公室的地址吗？或者是“Coffe Stain Conference Romm”的电话号码？是不是常被人叫在上午10点去“Scenic View”会议室开会，但你不知道怎么样去找到那个地方？
那么，这样事不会发生在foobar.com的员工身上，他们把所有有关他们的办公室，会议室，和其它类似的信息都放在LDAP目录里。公司的基于LDAP的电话簿可以很快的很简单的提取这些信息。
ou=devices
Foobar同时也决定把他们的计算机，打印机，和其它计算机设备的信息保存在LDAP里面。这也让他们的系统管理员可以把他们网络的每个设备的主机名、IP地址、MAC地址、当前用户和组、标记、系列号、结构型号、操作系统名称版本、位置和描述信息都保存在一个地方。
一个自定义的Web GUI允许系统管理员和公司的资产管理员输入，修改和查询这些信息。一些自定义的脚本可以用来直接从LDAP产生DNS和NIS的主机映射。资产管理工具可以自动定时更新硬件信息，这样你不费吹灰之力也能保证这些信息是最新的。
但是为什么把所有路由器、交换机、打印机、个人电脑、苹果机和UNIX系统信息都放在一个OU里呢？因为他们都共享同类型的信息。一个UNIX服务器和一个打印机有很大不同，但是保存这种类型的信息在本质上是一样的。如果有个问题：“给我所有Windows PCs的列表”，他们就很容易通过OS Name来查询到。
好的，但是如果是这样的问题：“给我所有laptop的列表”？Foobar.com实现了一些自定义的LDAP属性来让他们来跟踪每个设备的“Machine Class”和“Machine SubClass”属性，以提供他们所需要的粒度。“Machine Class”的值包括了Netgear，Printer，Windows，Mac，UNIX。“Machine SubClass”包括了router，switch，inkjet，laser，desktop，laptop，workstation，server。这些类和子类信息的集合可以灵活和精确的在许多情况下跟踪所有的网络设备。
规划你的目录拓扑
现在你可能想知道怎样设计的自己的目录了吧，让我们来看一个例子。在上面的例子里，foobar.com用了五个主要的类别，ou=customers再分成子类。（记住，这只是一个例子，对每个公司来说它不一定是最好的）。实际上，你可能想增加一个类别来处理NIS组的信息，邮件列表信息等等。
那么那些OU适合你呢？我让你看一下设计的过程。毕竟，你正在建立你的LDAP服务器来适应你自己情况的需要。上面的例子应该可以帮助你对如何组织你的数据有个感觉。这儿有一些比较广泛的指导方针来帮助你完成这个过程：
如果有可能，要避免一个不得不修改的目录树设计。设法不要让目录树基于公司组织图，一个当前的商业模式或者相似的东西。
你要避免从一个OU向另一个OU移动LDAP记录。如果你可以预见这会经常发生在你的设计中，设法去重新设计。你能把两个或者更多的分支整合成一个吗？你能用一个属性－location，department－去完成同样的目的吗？
你是否有在某些关系上相似的数据，但是如何使用这些数据却有很大的不同？你能为每种类型的条目创建独立的OU吗？如果条目无论什么理由都没有必要从一个OU移动到另一个OU，那么保持这些组是分开的。（考虑上面的例子，ou＝Employees和ou＝ITaccounts）
如果你要在同一点复制数据，考虑是否你能把一个OU分成按照你用户的需要的子OU。重新考虑这样做是否会导致一个对象从一个OU移动到另一个OU。（在上面的例子里，customers的OU要分类是正常选择，employees的OU则不是）
如果你需要隐藏目录中的一部分数据，不管是为安全原因或者只是简单的防止混淆，你可以用一个OU来做这个事。如果这违反了上面主要方针的任何一条，那么你就不得不判断自己要做什么－安全是棘手的话题，有不同的处理方法。
这儿有一些你可能考虑存放在LDAP目录的数据对象的比较广泛的指导方针。根据你的需要，每个都可以分成单独的OU。
员工信息
顾客信息，新老顾客
当地饭店的电话号码和描述，taxi服务，等等
会议室，办公场所信息，等等
LCD放映机,flip chars,和其它便携式“会议室”设备
计算机：桌面电脑,便携电脑,服务器,打印机,网络设备
邮件列表
NIS group map
NIS netgroup map
看起来很简单吧？但是不要忽略了下面这些：
NIS password map。这个map保存了个别员工的信息。你能够分析这个文件和保存每个用户login name，password，uid和gid numbers，login shell，和home directories作为在ou＝employees和ou＝Itaccounts下的个别的LDAP条目的用户特定的属性。
Organizational charts。Org charts本质上来说反映了每一个员工的job title，manager，department，和（或者）business unit。通过你的org chart和每个员工单独记录的相关信息的分析。你总可以从保存在目录里的一系列managers来得出公司的org chart。
NIS aliases map。Aliases map保护了许多不同类型的信息，个人的mail routing信息和交替的email地址都要作为每个员工的LDAP条目的部分来保存。Mailing list 信息能被保存在自己的OU里，如cetera。我有一整篇文章来描述在LDAP中存放email，所以请耐心等待。
最后，我希望你觉得这篇文章对你有用。如果你有任何意见或者问题，请发email: [email protected]
Michael Donnelly
9 may 2000