4.2. 设计目录树

在目录树设计中计划有几个主要决策:
  • 选择包含数据的后缀。
  • 确定数据条目之间的分层关系。
  • 命名目录树层次结构中的条目。

4.2.1. 选择 Suffix

后缀是目录树根目录下的条目名称,并且目录数据存储在其中。目录可以包含多个后缀。如果有两个或者多个目录树没有自然常见的根,则可以使用多个后缀。
默认情况下,标准目录服务器部署包含多个后缀,一个用于存储数据,另一个用于存储内部目录操作(如配置信息和目录模式)所需的数据。有关这些标准目录后缀的更多信息,请参阅 红帽目录服务器管理指南

4.2.1.1. 后缀命名

目录中的所有条目都应位于一个通用的基础条目下,根后缀。当为根目录后缀选择名称时,请考虑这四个点以使名称有效:
  • 全局唯一。
  • 静态,因此很少会在发生改变的情况下。
  • 简而言之,这样,在屏幕上更轻松地阅读条目。
  • 易于输入并记住。
在单一企业环境中,选择一个与企业 DNS 名称或互联网域名一致的目录后缀。例如,如果企业拥有 example.com 的域名,则目录后缀在逻辑上是 dc=example,dc=com
dc 属性通过将域名拆分到其组件部分来代表后缀。
通常,任何属性都可用于命名根后缀。但是,对于托管机构,将 root 后缀限制为以下属性:
  • dc 定义域名的组件。
  • c 包含代表国家名称的双位代码,由 ISO 定义。
  • l 标识条目所在的数目、城市或其他地理位置,或者与该条目相关联。
  • st 识别条目所在的状态或省去。
  • o 标识条目所属组织的名称。
这些属性的存在允许与订阅者应用程序进行互操作性。例如,托管机构可能会使用这些属性为其其中一个客户端创建根后缀,如 o= example_a、st=Washington,c=US
使用机构名称后加上国家设计是后缀的典型 X.500 命名约定。

4.2.1.2. 命名多个 Suffixes

与目录搭配使用的每个后缀都是唯一的目录树。可以通过多种方式在目录服务中包含多个树。第一种方法是创建存储在由 Directory Server 提供的独立数据库中的多个目录树。
例如,为 example_aexample_b 创建单独的后缀,并将它们存储在单独的数据库中。

图 4.1. 在数据库中包含多个目录树

在数据库中包含多个目录树
根据资源限制,数据库可以存储在单一服务器或多个服务器上。

4.2.2. 创建目录树结构

决定是否使用平面或分级树结构。作为常规规则,尝试尽可能使目录树变为扁平。但是,以后在多个数据库间分区信息、准备复制或设置访问控制时,一定程度的层次结构非常重要。
树结构涉及以下步骤和注意事项:

4.2.2.1. 对目录进行分支

设计层次结构以避免有问题的名称更改。命名空间扁平化,名称不太可能改变。名称更改的可能性与名称中可能更改的组件数量大致成比例。更容易对目录树、名称中的更多组件以及名称更有可能更改的等级。
以下是设计目录树层次结构的一些准则:
  • 将树分支,仅代表企业中最大的组织细分。
    所有这些分支点应限制在部门(如公司信息服务、客户支持、销售与工程)。确保用于分支目录树的部门具有稳定的;如果企业经常重新组织,则不执行此类分支。
  • 对分支点使用功能或通用名称而不是实际的机构名称。
    名称更改。虽然子树可以重命名,但它是具有许多子条目的大型后缀的很长和资源密集型过程。使用代表机构功能的通用名称(例如,使用 Engineering 而不是 Widget Research 和 Development)使得在机构或项目更改后需要重命名子树的几率要小。
  • 如果有多个机构执行类似的功能,请尝试为该功能创建单个分支点,而不是基于划分行进行分支。
    例如,即使有多个营销机构,每个营销机构都负责特定的产品行,请创建一个 ou=Marketing 子树。然后,所有营销条目都属于该树。

Enterprise 环境中的分支

如果目录树结构基于可能更改的信息,可以避免名称更改。例如,对树中的对象类型而非组织,对对象类型的结构为基础。这有助于避免在组织单元之间影响一个条目,这需要修改可分辨名称 (DN),这是代价昂贵的操作。

有几种通用对象可用于定义结构:
  • ou=people
  • ou=groups
  • ou=services
使用这些对象组织组织的目录树可能如下所示。

图 4.2. Environment Directory 树示例

Environment Directory 树示例

主机环境中的分支

对于托管环境,创建一个树,其中包含对象类 组织 (o)的两个条目,以及对象类 organizationalUnit (ou)下的一个条目。例如,ISP 分支其目录示例,如下所示。

图 4.3. 主机目录树示例

主机目录树示例

4.2.2.2. 识别分支点

在规划目录树中的分支时,决定使用什么属性来识别分支点。请记住,DN 是由属性数据对组成的唯一字符串。例如: Barbara Jensen ( Example Corp. 的员工)条目的 DN 是 uid=bjensen,ou=people,dc=example,dc=com
每个属性对代表目录树中的一个分支点,如企业 Example Corp 的目录树中所示。图 4.4 “示例 Corp 的 Directory 树。”

图 4.4. 示例 Corp 的 Directory 树。

示例 Corp 的 Directory 树。
图 4.5 “示例 ISP 的目录树” 显示 ISP (互联网主机)的目录树。

图 4.5. 示例 ISP 的目录树

示例 ISP 的目录树
在后缀条目 c=US,o=example 下,树被分成三个分支。ISP 分支包含客户数据和 ISP 示例内部信息。互联网分支是域树。groups 分支包含有关管理组的信息。
在为分支点选择属性时请考虑以下几点:
  • 保持一致。
    如果区分名称 (DN) 格式在目录树中不一致,则一些 LDAP 客户端应用程序可能会混淆。也就是说,如果 l 属于目录树的一个部分的 ou,请确保在目录服务的所有其他部分的 l 从属为 ou
  • 尝试只使用传统属性(在 第 4.2.2.2 节 “识别分支点”中显示)。
    使用传统属性会增加保留与第三方 LDAP 客户端应用程序的兼容性的可能性。使用传统属性还意味着它们对默认目录架构所知,这有助于为分支 DN 构建条目。

表 4.1. 传统 DN 分支点属性

属性 定义
dc 域名的一个元素,如 dc=example ;这经常在对中指定,甚至更长,具体取决于域,如 dc=example,dc=comdc=mtv,dc=example,dc=com
c 国家/地区名称。
o 机构名称。此属性通常用于代表一个大的分部分支,如公司部门、学术线(人类、科学)、子公司,或者企业内的其他主要分支,如 第 4.2.1.1 节 “后缀命名”
ou 组织单元。此属性通常用来代表比组织较小的部门分支。组织单元一般与上述机构从属。
st 状态或省名称。
llocality 本地性,如城市、国家、办公室或设备名称。
注意
常见错误是假定根据可分辨名称中使用的属性搜索目录。区分名称只是目录条目的唯一标识符,不能用作搜索键。相反,请根据条目本身中存储的属性对搜索条目。因此,如果条目的可分辨名称为 uid=bjensen,ou=People,dc=example,dc=com,则搜索 dc=example 不匹配该条目,除非在该条目中明确添加了 dc:example 作为属性。

4.2.2.3. 复制注意事项

在目录树设计过程中,请考虑要复制哪些条目。描述要复制的一组条目的自然方法是指定子树顶部的 DN,并复制其下面的所有条目。此子树也与数据库对应,它是包含部分目录数据的目录分区。
例如,在企业环境中,一种方法是组织目录树,使其与企业中的网络名称对应。网络名称不会更改,因此目录树结构是稳定的。此外,使用网络名称创建目录树的顶层分支很有用,在使用复制来将复制绑定到不同的目录服务器时很有用。
例如,Example Corp. 有三个主要网络,称为 flightdeck.example.comtickets.example.comhangar.example.com。它们最初将其目录树分到其主要组织部门的三个主要组中。

图 4.6. 示例公司的 Directory 树的初始分支。

示例公司的 Directory 树的初始分支。
在创建了树的初始结构后,他们会创建额外的分支来显示每个机构组的分类。

图 4.7. 为示例公司扩展分支.

为示例公司扩展分支.
示例 ISP 在非对称树中对目录进行镜像,以镜像其组织的非对称树进行分支。

图 4.8. 示例 ISP 的目录分支

示例 ISP 的目录分支
在创建了其目录树的初始结构后,会为逻辑子组创建额外的分支。

图 4.9. 用于示例 ISP 的扩展分支

用于示例 ISP 的扩展分支
企业和托管组织均基于可能经常更改的信息设计其数据层次结构。

4.2.2.4. 访问控制注意事项

在目录树中引入层次结构,以启用某些类型的访问控制。与复制一样,可以更轻松地对类似的条目进行分组,然后从单个分支进行管理。
也可以通过分级目录树启用管理分布。例如,为管理员授予营销部门对营销条目的访问权限,以及来自销售部门对销售条目的管理员访问,根据这些部门对目录树进行设计。
访问控制可以基于目录的内容而不是目录树。过滤的机制可以定义一个访问控制规则,说明目录条目可以访问包含特定属性值的所有条目。例如,设置一个 ACI 过滤器,向 sales 管理员提供对包含属性值 ou=Sales 的所有条目的访问权限。
但是 ACI 过滤器难以管理。确定哪个访问控制方法最适合于 目录:组织树层次结构中的分支、ACI 过滤器或两者的组合。

4.2.3. 命名条目

在设计目录树的层次结构后,决定在命名结构中的条目时要使用的属性。通常,通过选择一个或多个属性值来形成名称,以形成 相对可分名称(RDN)。RDN 是 DN 中的单个组件。这是显示的第一个组件,因此该组件的 属性是 naming 属性,因为它为该条目设置唯一名称。要使用的属性取决于被命名的条目类型。
条目名称应遵循以下规则:
  • 为命名选择的属性应不太可能改变。
  • 该名称在目录中必须是唯一的。
    唯一名称可确保 DN 在 目录中最多可以看到一个条目。
在创建条目时,在条目中定义 RDN。通过在该条目中定义至少 RDN,该条目可以更轻松地找到该条目。这是因为搜索不会针对实际 DN 执行,而是在条目本身中存储的属性值。
属性名称具有含义,因此尝试使用与它所代表的输入类型匹配的属性名称。例如,不要使用 l 来代表一个机构,或者 c 代表组织单元。

4.2.3.1. 命名角色条目

该用户条目的名称( DN)必须是唯一的。通常,区分名称使用 commonNamecn 属性来命名其个人条目。也就是说,名为 Babs Jensen 的个人可能具有可区分名称 cn=Babs Jensen,dc=example,dc=com 的条目。
虽然使用通用名称可以更容易地将人与条目相关联,但可能不足以排除具有相同名称的人。这很快会导致一个称为 DN 名称冲突 的问题,多个条目具有相同的可辨识名称。
通过在通用名称中添加唯一标识符来避免常见的名称冲突,如 cn=Babs Jensen+employeeNumber=23,dc=example,dc=com
但是,这可以导致大型目录的通用名称被放大,并且难以维护。
更好的方法是识别带有 cn 以外的某些属性的 person 条目。考虑使用以下属性之一:
  • uid
    使用 uid 属性指定个人的一些唯一值。可能包括用户登录 ID 或员工号码。托管环境中的订阅者应该由 uid 属性识别。
  • mail
    mail 属性包含个人的电子邮件地址,该地址始终是唯一的。这个选项可能会导致包含重复属性值(如 mail=bjensen@example.com,dc=example,dc=com)的 awkward DNs,因此仅在没有与 uid 属性一起使用的其他唯一值时才使用这个选项。例如,如果企业没有为临时或合同员工分配员工数量或用户 ID,则使用 mail 属性而不是 uid 属性。
  • employeeNumber
    对于 inetOrgPerson 对象类的员工,请考虑使用人员分配的属性值,如 employeeNumber
任何用于个人条目 RDN 的属性数据对,请确保它们是唯一的永久值。人员条目还应是可读的。例如,uid=bjensen,dc=example,dc=com 可用于 uid=b12r56A,dc=example,dc=com,因为可识别的 DN 简化了某些目录任务,如根据可分辨的名称更改目录条目。另外,一些目录客户端应用程序假定 uidcn 属性使用人类可读的名称。

在托管环境中为 Person 条目的注意事项

如果一个人是服务的订阅者,则条目应该是对象类 inetUser,条目应包含 uid 属性。在客户子树中,属性必须是唯一的。

如果个人是托管机构的一部分,请将它们表示为带有 nsManagedPerson 对象类的 inetOrgPerson

将 Person Entries 放置到 DIT 中

以下是将人员条目放入目录树的一些准则:

  • 企业中的人员应位于组织条目下的目录树中。
  • 对托管机构的订阅者需要低于托管机构的 ou=people 分支。

4.2.3.2. 命名组条目

有四个主要代表组的方法:
  • 静态组 显式定义是成员。groupOfNamesgroupOfUniqueNames 对象类包含命名组成员的值。静态组适合具有几个成员的组,如目录管理员组。静态组不适用于具有数千个成员的组。
    静态组条目必须包含 uniqueMember 属性值,因为 uniqueMembergroupOfUniqueNames 对象的强制属性。此对象类需要 cn 属性,它可用于组成组条目的 DN。
  • 动态组 使用一个代表搜索过滤器和子树的组的条目。与过滤器匹配的条目是组的成员。
  • 角色 统一了静态和动态组概念。如需更多信息,请参阅 第 4.3 节 “分组目录条目”
在包含托管机构的部署中,请考虑使用 groupOfUniqueNames 对象类包含命名目录管理中使用的组成员的值。在托管机构中,我们还建议用于目录管理的组条目位于 ou=Groups 分支下。

4.2.3.3. 命名机构条目

与其他条目名称一样,组织条目名称必须是唯一的。将机构的法律名称与其他属性值一起使用有助于确保名称是唯一的,如 o=example_a+st=Washington,o=ISP,c=US
也可以使用商标,但不能保证其唯一。
在托管环境中,使用 organization (o)属性作为 naming 属性。

4.2.3.4. 命名其他 Entries 的 Kind

该目录包含包括许多内容的条目,如本地城市、州、国家、设备、服务器、网络信息和其他种类的数据。
对于这些类型的条目,请在 RDN 中使用 cn 属性(如果可能)。然后,为命名组条目,将其命名为 cn=administrators,dc=example,dc=com 等内容。
但是,有时条目的对象类不支持 commonName 属性。反之,使用条目对象类支持的属性。
用于条目 DN 的属性不必与条目中实际使用的属性对应。但是,在 DN 属性与条目使用的 DN 属性之间有一些关联,可以简化目录树的管理。

4.2.4. 重命名条目和子树

第 4.2.3 节 “命名条目” 讨论红帽目录服务器中命名条目的重要性。条目名称在某种意义上定义目录树结构。每个分支点(其下方具有条目的每个条目)会在层次结构中创建新链接。

例 4.1. building Entry DNs

                                                                  dc=example,dc=com  =>  root suffix
                                                        ou=People,dc=example,dc=com  =>  org unit
                                          st=California,ou=People,dc=example,dc=com  =>  state/province
                          l=Mountain View,st=California,ou=People,dc=example,dc=com  =>  city
           ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com  =>  org unit
uid=jsmith,ou=Engineering,l=Mountain View,st=California,ou=People,dc=example,dc=com  =>  leaf entry
当条目的 naming 属性时,DN 的左边元素已更改,这是 modrdn 操作。这是一种特殊的修改操作,因为在某种意义上,它会将条目移到目录树中。对于叶条目(没有子项的项),modrdn 操作是侧向移动的;条目具有相同的父项,只需一个新名称。

图 4.10. Leaf Entry 的 modrdn Operations

Leaf Entry 的 modrdn Operations
对于子树条目,modrdn 操作不仅重命名子树条目本身,还会更改子树 下所有子条目的 DN 组件。

图 4.11. 子树条目的 modrdn 操作

子树条目的 modrdn 操作
重要
子树 modrdn 操作也会移动并重命名 subtree 条目下的所有子条目。对于大型子树,这可以是一个时间和资源密集型进程。以层次结构来规划对目录数的命名结构,使其不需要频繁对子树进行重命名操作。
重命名子树的类似操作是将条目从一个子树移到另一个子树。这是一个扩展的 modrdn 操作类型,它同时重命名条目(即使是相同的名称),并且设置 newsuperior 属性,它将条目从一个父项移到另一个父项。

图 4.12. 对一个新父项的 modrdn 操作

对一个新父项的 modrdn 操作
新的 superior 和 subtree rename 操作都是可能的,因为条目如何存储在 entryrdn.db 索引中。每个条目都由其自己的键(一个 self-link)标识,然后是一个子键来标识其父项( 父链接)和任何子项。这是一个层次结构目录树的格式,它将父项和子项视为条目的属性,每个条目都由唯一 ID 及其 RDN 描述,而不是完整的 DN 进行标识。
numeric_id:RDN => self link  
     ID: #; RDN: "rdn"; NRDN: normalized_rdn
P#:RDN => parent link
     ID: #; RDN: "rdn"; NRDN: normalized_rdn
C#:RDN => child link
     ID: #; RDN: "rdn"; NRDN: normalized_rdn
例如,ou=people 子树的父项为 dc=example,dc=com,子是 uid=jsmith
4:ou=people
   ID: 4; RDN: "ou=People"; NRDN: "ou=people"
P4:ou=people
   ID: 1; RDN: "dc=example,dc=com"; NRDN: "dc=example,dc=com"
C4:ou=people
   ID: 10; RDN: "uid=jsmith"; NRDN: "uid=jsmith"
在执行重命名操作时需要记住以下一些事项:
  • 您无法重命名 root 后缀。
  • 子树重命名操作对复制的影响最少。复制协议会应用于整个数据库,而不是数据库中的子树,因此子树重命名操作不需要重新配置复制协议。子树重命名操作之后的所有名称都会正常进行复制。
  • 重命名子树 可能需要 重新配置任何同步协议。同步协议在后缀或子树级别上设置,因此重命名子树可能会破坏同步。
  • 重命名子树 要求 手动重新配置子树级 ACI,以及为子树子条目设置的任何条目级 ACI。
  • 您可以将子树重命名为子树,但您无法删除子树。
  • 尝试更改子树的组件,如从 ou 移到 dc,可能会因为 schema 违反而失败。例如,organizationalUnit 对象类需要 ou 属性。如果该属性作为重命名子树的一部分被删除,则操作将失败。