Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

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

4.2.2.3. 复制注意事项
复制链接

在目录树设计过程中，请考虑要复制哪些条目。描述要复制的一组条目的自然方法是指定子树顶部的 DN，并复制其下面的所有条目。此子树也与数据库对应，它是包含部分目录数据的目录分区。
例如，在企业环境中，一种方法是组织目录树，使其与企业中的网络名称对应。网络名称不会更改，因此目录树结构是稳定的。此外，使用网络名称创建目录树的顶层分支很有用，在使用复制来将复制绑定到不同的目录服务器时很有用。
例如，Example Corp. 有三个主要网络，称为 flightdeck.example.com、tickets.example.com 和 hangar.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)必须是唯一的。通常，区分名称使用 commonName 或 cn 属性来命名其个人条目。也就是说，名为 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 简化了某些目录任务，如根据可分辨的名称更改目录条目。另外，一些目录客户端应用程序假定 uid 和 cn 属性使用人类可读的名称。

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

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

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

将 Person Entries 放置到 DIT 中

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

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

4.2.3.2. 命名组条目
复制链接

有四个主要代表组的方法：
  • 静态组 显式定义是成员。groupOfNames 或 groupOfUniqueNames 对象类包含命名组成员的值。静态组适合具有几个成员的组，如目录管理员组。静态组不适用于具有数千个成员的组。
    静态组条目必须包含 uniqueMember 属性值，因为 uniqueMember 是 groupOfUniqueNames 对象的强制属性。此对象类需要 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 属性。如果该属性作为重命名子树的一部分被删除，则操作将失败。
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat返回顶部