4.2. 设计目录树
在规划目录树时，您可以做出以下主要决策：
- 您可以选择包含数据的后缀。
- 您可以通过创建目录树结构来确定数据条目之间的分级关系。
- 您可以命名目录树层次结构中的条目。
4.2.1. 选择后缀
后缀是目录树根目录下的条目名称，目录数据存储在其中。目录可以包含多个后缀。如果有两个或者多个没有自然常见的 root 信息树，您可以使用多个后缀。默认情况下，标准目录服务器部署包含多个后缀，一个用于存储数据，另一个用于存储内部目录操作所需的数据，如配置信息和目录模式。
命名后缀的惯例
您应该在常用基础条目( 根后缀 )中找到 目录中的所有条目。当您为根目录后缀选择名称时，要使名称有效，必须为：
- 全局唯一
- Static
- 短，以便您可以轻松读取其下的条目
- 便于人键入和记住
在单一企业环境中，您可以选择与企业 DNS 名称或互联网域名一致的目录后缀。例如，如果企业拥有 example.com 的域名，则目录后缀为 dc=example,dc=com。dc 属性通过将域名拆分到其组件部分来代表后缀。通常，您可以使用任何属性来命名根后缀。但是，对于托管机构，您必须将 root 后缀限制为以下属性：
dc- 定义域名的组件。
c- 包含代表国家名称的双位代码，由 ISO 定义。
l- 标识该条目所在的计数、城市或其他地理位置，或者与该条目相关联。
st- 标识条目所在的状态或省去。
o- 标识条目所属机构的名称。
这些属性提供与订阅者应用程序的互操作性。例如，托管组织可以使用这些属性来创建根后缀 o=example_a, st=Washington,c=US 用于其其中一个客户端 example_a。
根据后缀的 X.500 命名约定，通常使用机构名称以及国家设计。
命名多个后缀
目录中的每个后缀都是唯一的目录树。您可以创建存储在单独的数据库目录服务器中的多个目录树。
例如，您可以创建单独的后缀，如 example_a 和 example_b，并将它们存储在单独的数据库中。
您可以根据资源限制在单一服务器或多个服务器上存储数据库。
4.2.2. 创建目录树结构
决定是否使用平面或分级树结构。尝试尽可能使目录树变为扁平。但是，以后在多个数据库间分区信息、准备复制或设置访问控制时，一定程度的层次结构非常重要。
树的结构涉及以下步骤和注意事项：
- 分支目录
- 识别分支点
- 复制注意事项
- 访问控制注意事项
4.2.2.1. 分支目录
命名空间必须尽量扁平，以避免有问题的名称更改。更容易对目录树、名称中的更多组件以及名称更有可能更改的等级。
使用以下准则来设计目录树层次结构：
- 将树分支，仅代表企业中最大的组织子部门。您应该限制分支指向部门，如公司信息服务、客户支持、销售和工程等。确保用于分支目录树的划分是稳定的。如果企业频繁重组，则不要执行此类分支。
-
对分支点使用功能或通用名称而不是实际的机构名称。当您重命名子树时，如果后缀有许多子项，则名称更改进程是资源密集型和长。例如，使用
Engineering而不是Widget Research 和 Development。 -
如果您有多个执行类似功能的组织，请尝试为该功能创建单个分支点。例如，即使有多个营销机构（每个机构都负责特定的产品行），创建一个
ou=Marketing子树。然后，所有 marketing 条目都属于该树。
企业环境中的分支
如果您根据可能更改的信息规划目录树结构，可以避免名称更改。例如，如果您将结构基于树中的对象类型，而不是机构。
使用以下通用对象来定义结构：
-
ou=people -
ou=groups -
ou=contracts -
ou=services
下图显示了使用这些对象组织的目录树：
托管环境中的分支
对于托管环境，创建一个树，其中包含对象类 组织的 两个条目(o)，并在 root 后缀下包含对象类 organizationalUnit (ou)的条目。例如，名为 Example ISP 的互联网服务提供商按以下方式对目录进行分支：
4.2.2.2. 识别分支点
在规划目录树中的分支时，决定使用什么属性来识别分支点。分支点是一个属性数据对，如 ou=people,l=Japan,cn=Barbara Jansen。请记住，DN 是由这些属性数据对组成的唯一字符串。例如，Barbara Jensen 条目的 DN 是 Example Company 的员工，如下所示：
uid=bjensen,ou=people,dc=example,dc=com.
请参阅下图中带有 ou=people,ou=groups,cn=Barbara Jensen,cn=Billie Holiday 分支点的示例。
请参阅下图中的互联网供应商 示例 ISP 的目录树示例：
在 root 后缀条目 o=example,c=US 下，树被分成三个分支。o=ISP 分支包含客户数据和 ISP 示例内部信息。o=internet 分支是域树。ou=groups 分支包含有关管理组的信息。
在为分支点选择属性时请考虑以下建议：
保持一致。
如果 DN 格式在目录树中不一致，一些 LDAP 客户端应用程序可能无法找到可分辨的名称(DN)。如果目录树的一个部分的
ou下为oou在目录服务的所有其他部分下。尝试只使用传统属性。
当您使用传统属性时，它会增加目录服务器与第三方 LDAP 客户端应用程序兼容的的可能性。使用传统属性还意味着默认目录架构知道它们。
| 传统属性 | 描述 |
|---|---|
|
|
域名的一个元素，如 |
|
| 国家/地区名称。 |
|
| 机构名称。使用此属性代表大型部门分支，如公司部门、教育部门（人类、科学）、子公司或其他主要分支。您可以使用此属性代表域名。 |
|
| 机构单元。使用此属性代表比机构较小的部门分支。组织单元通常属于上述组织。 |
|
| 状态或省名称。 |
|
| 本地性，如城市、国家、办公室或设施名称。 |
常见错误是假定根据可分辨名称中使用的属性搜索目录。区分名称只是目录条目的唯一标识符，不能用作搜索键。相反，请根据条目本身中存储的属性对搜索条目。因此，如果条目的可分辨名称为 uid=bjensen,ou=People,dc=example,dc=com，则搜索 dc=example 不匹配那个条目，除非在该条目中明确添加了 dc:example 作为属性。
4.2.2.3. 复制注意事项
规划您要复制的条目。您可以在子树顶部指定 DN，并复制其下的所有条目。此子树也与数据库对应，一个目录部分包含目录数据。
例如，在企业环境中，您可以组织目录树，使其与企业中的网络名称对应。网络名称往往 不会改变，因此目录树结构稳定。
例如，Example Company 有三个主要网络，称为 flightdeck.example.com、ticket.example.com 以及 hangar.example.com。公司最初将其目录树分到其主要组织部门的三个主要组中。参阅下图中目录树的初始分支：
创建树的初始结构后，公司创建额外的分支。请参阅以下图像中的扩展分支：
在另一个示例中，互联网供应商示例 ISP 有以下初始分支来满足供应商需求：
之后，示例 ISP 为逻辑子组创建额外的分支。请参阅以下图像中的扩展分支：
企业示例 Company 和托管组织都根据不经常更改的信息设计其数据层次结构。
4.2.2.4. 访问控制注意事项
您可以使用目录树中的层次结构来启用某些类型的访问控制。与复制一样，可以更轻松地对类似的条目进行分组，然后从单个分支进行管理。
您可以通过分级目录树进行管理。例如，为管理员授予营销部门对营销条目的访问权限，以及来自销售部门对销售条目的管理员访问，根据这些部门对目录树进行设计。
另外，您可以根据目录内容而不是目录树设置访问控制。使用访问控制指令(ACI)机制，您可以允许特定条目访问包含特定属性值的所有条目。例如，设置一个 ACI，为 sales 管理员授予对包含属性值 ou=Sales 的所有条目的访问权限。
但是，ACI 可能很难管理。决定访问控制的最佳方法：组织树层次结构中的分支、ACI 或两者的组合。
4.2.3. 命名条目
在设计目录树的层次结构后，您需要决定在命名结构中的条目时使用哪些属性。当您选择一个或多个属性值时，您可以形成一个 相对可分辨名称 (RDN)。RDN 是 DN 的最左侧部分，您选择的 属性是 naming 属性。naming 属性为条目设置唯一名称。例如，DN uid=bjensen,ou=people,dc=example,dc=com 具有 RDN uid=bjensen。
您选择的属性取决于您命名的条目类型。
在命名条目时请考虑以下几点：
- 您不应更改为命名选择的属性。
- 名称在目录中必须是唯一的。唯一名称可确保 DN 只引用目录中的一个条目。
当您创建条目时，在条目中定义 RDN。通过条目内定义的 RDN，该条目可以更轻松地找到该条目。这是因为，根据条目本身中存储的属性值搜索条目，而不基于实际的 DN。
属性名称具有含义，因此尝试使用与它所代表的输入类型匹配的属性名称。例如，不要使用 l （位置）代表机构，或使用 c (country)代表机构单元。
4.2.3.1. 命名目录树中的 person 条目
个人条目名称必须是唯一的。通常，要命名人员条目，您可以使用 commonName 或 cn、属性组成一个相对可分辨名称(RDN)。例如，名为 Babs Jensen 的人员的条目可能具有可分辨名称(DN)，作为 cn=Babs Jensen,dc=example,dc=com。
请注意，在 RDN 中使用通用名称可能不足使条目名称唯一，并可能会创建几个相同的条目，从而导致 DN 名称冲突。
通过在通用名称中添加唯一标识符来避免常见名称冲突，如 cn=Babs Jensen+employeeNumber=23,dc=example,dc=com。但是，这可能会导致大型目录的通用名称，很难维护。
更好的方法是，使用 cn 以外的某些属性来识别 person 条目。考虑使用以下属性之一：
- uid
-
使用
uid属性指定个人的一些唯一值，如用户登录 ID 或员工号码。通过uid属性识别托管环境中的订阅者。 -
mail属性包含始终唯一的个人电子邮件地址。此属性可能会导致包含重复属性值的 DN，如mail=bjensen@example.com,dc=example,dc=com。只有在您找不到uid属性的一些唯一值时，才使用这个选项。例如，如果企业没有为临时或合同员工分配员工号码或用户 ID，则使用mail属性而不是uid属性。 - employeeNumber
-
对于
inetOrgPerson对象类的员工，请使用employeeNumber属性。
无论您用于个人条目 RDN 的属性数据对，请确保它们是唯一的永久值。人员条目 RDN 应该也是可读的。例如，DN uid=bjensen,dc=example,dc=com 比 uid=b12r56A,dc=example,dc=com 更首选，它简化了一些目录任务，如根据其可分辨名称更改目录条目。另外，一些目录客户端应用程序假设 uid 和 cn 属性使用人类可读的名称。
托管环境中个人条目的注意事项
如果个人是服务的订阅者，该条目应具有 inetUser 对象类，并且包含 uid 属性。此属性在客户子树中必须是唯一的。
如果个人是托管机构的一部分，请将 inetOrgPerson 属性与 nsManagedPerson 对象类一起使用。
将 person 条目放在目录树中
使用以下准则将 person 条目放置到目录树中：
- 在目录树中的组织条目下，找到企业中的人员。
-
为托管组织的
ou=people分支找到下的托管组织的订阅者。
4.2.3.2. 目录树中的命名组条目
您可以使用以下方法代表组：
静态组 明确定义其成员。
groupOfNames或groupOfUniqueNames对象类包含命名组成员的值。静态组适用于几个成员的组，如目录管理员组，不适用于具有数千个成员的组。静态组条目必须包含
uniqueMember属性值，因为uniqueMember是groupOfUniqueNames对象的强制属性。此对象类需要cn属性，您可以使用它来组成组条目的 DN。- 动态组 指定过滤器，与过滤器匹配的所有条目都是此组的成员。
- 角色 统一静态和动态组概念。
在托管环境中，请考虑使用 groupOfUniqueNames 对象类来包含命名目录管理中使用的组成员的值。
另外，在 ou=Groups 分支下查找用于目录管理的组条目。
其他资源
4.2.3.3. 命名机构条目
组织条目名称必须是唯一的。当您将机构的法律名称与其他属性值一起使用时，有助于确保名称是唯一的，如 o=example_a+st=Washington,o=ISP,c=US。
您还可以使用商标，但它们可能不唯一。
在托管环境中，在机构条目中包含以下属性：
-
o(organizationName) -
带有top,organization, 和nsManagedDomain的值
4.2.3.4. 命名其他条目
该目录包含代表不同信息的条目，如本地城市、州、国家、设备、服务器、网络信息和其他数据类型。对于这些类型的条目，使用 RDN 中的 cn 属性。您还可以将组条目命名为 cn=administrators,dc=example,dc=com。
有时，条目对象类不支持 commonName 属性。反之，使用条目对象类支持的属性。naming 属性不必与您在条目中实际使用的属性对应。但是，如果您在条目中使用的 DN 属性和属性之间存在一些关联，则更轻松地管理目录树。
4.2.4. 重命名条目和子树
条目名称定义目录树结构。每个分支点在层次结构中创建一个新链接。
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 属性时，条目 RDN，您执行 modrdn 操作。此修改操作会将条目移到目录树中。对于叶条目（无子项的项），modrdn 操作只更改 RDN 部分，父条目保持不变。
对于子树条目，modrdn 操作重命名子树条目本身，并更改子树下所有子条目的 DN 组件。
子树 modrdn 操作也会移动和重命名子树条目下的所有子条目。对于大型子树，这可能是时间和资源密集型进程。以层次结构来规划对目录数的命名结构，使其不需要频繁对子树进行重命名操作。
重命名子树的类似操作是将条目从一个子树移到另一个子树。这种扩展类型的 modrdn 操作同时重命名条目，即使它相同名称，并且设置一个新的s uperior 属性，将条目从一个父项移到另一个父项。
目录服务器使用 entryrdn.db 索引执行新的高级和子树重命名操作。目录服务器通过自链接、父目录链接和任何子项链接来识别每个条目。entryrdn.db 索引将父项和子项作为条目的属性呈现给条目，并通过唯一 ID 及其 RDN 而不是完整的 DN 描述每个条目。
entryrdn.db 索引的格式如下：
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 子条目。entryrdn.db 索引包含以下内容：
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"
执行 rename 操作时请考虑以下几点：
- 您无法重命名根后缀。
- 您不需要重新配置复制协议。目录服务器将复制协议应用到整个数据库，而不是数据库中的子树。
- 您可能需要在子树重命名操作后重新配置所有同步协议。同步协议在后缀或子树级别上设置，因此重命名子树可能会破坏同步。
- 您需要重新配置为子树设置的所有子树级 ACI，并为子树的子条目设置所有条目级 ACI。
- 您可以使用子项重命名子树，但您无法使用子项删除子树。
-
当您尝试更改子树的组件时，如从
ou移到dc时，它可能会失败，并显示 schema 冲突。例如，organizationalUnit对象类需要ou属性。如果操作尝试从organizationalUnit对象类中删除ou属性，则子树操作会失败。
