第 10 章 目录设计示例
目录服务的设计取决于企业的大小和性质。本章提供了几个示例，它演示了如何在各种不同的设置中应用目录。这些示例是开发实时目录服务部署计划的起点。
10.1. 设计示例：本地企业
企业(Amobileile parts manufacturer)是由 500 名员工组成的小公司。示例 Corp. 决定部署红帽目录服务器来支持其所使用的目录应用程序。
10.1.1. 本地企业数据设计
示例。首先确定其将存储在 目录中的数据类型。为此，example Corp. 创建一个部署团队，它将执行站点调查来确定如何使用该目录。部署团队决定以下内容：
- Corp. 的 目录将由消息传递服务器、Web 服务器、日历服务器、人工资源应用程序和白页应用程序使用。
- 消息传递服务器对
uid、mailServerName和mailAddress等属性执行精确搜索。为提高数据库性能，example Corp. 将维护这些属性的索引，以支持通过消息传递服务器搜索。有关使用索引的详情请参考 第 6.4 节 “使用索引来提升数据库性能”。 - 空白页面应用程序会频繁搜索用户名和电话号码。因此，该目录需要能够频繁地子字符串、通配符和 fuzzy 搜索，后者返回大量结果。示例 Corp. 决定维护
cn,sn, 和givenName属性的存在、相等、大约和子字符串索引，以及telephoneNumber属性的 presence, equality, 和 substring 索引。 - 示例 Corp. 的目录维护用户和组信息，以支持整个组织内部署的基于 LDAP 服务器的 Intranet。大多数 Example Corp. 的用户和组信息将由一组目录管理员集中管理。但是，Example Corp. 还希望电子邮件信息由独立的邮件管理员组管理。
- 企业计划将来支持公钥基础架构(PKI)应用程序，如 S/MIME 电子邮件，因此需要准备好将用户的公钥证书存储在目录中。
10.1.2. 本地企业架构设计
Corp. 的部署团队决定使用 inetOrgPerson 对象类来代表目录中的条目。这个对象类是 appealing，因为它允许
userCertificate 和 uid (userID)属性，这两个属性都由 Example Corp. 目录支持。
Corp. 也希望自定义默认目录模式。示例 Corp. 创建 examplePerson 对象类来代表 Example Corp 的员工。它从 inetOrgPerson 对象类派生此对象类。
examplePerson 对象类允许一个属性
exampleID 属性。此属性包含分配给每个 Example Corp. staff 的特殊员工号码。
未来，Example Corp. 可以根据需要向 examplePerson 对象类添加新属性。
10.1.3. 本地目录树设计
根据前面部分描述的数据和模式设计，Example Corp. 创建以下目录树：
- 目录树的根是 Example Corp.'s Internet 域名：
dc=example,dc=com。 - 目录树有四个分支点：
ou=people,ou=groups,ou=roles,和ou=resources。 - 所有 Example Corp. 的人条目都在
ou=people分支下创建。人员条目是个人、organizationalPerson、inetOrgPerson 和 examplePerson 对象类的所有成员。uid属性唯一标识每个条目的 DN。例如，Example Corp. 包含 Babs Jensen (uid=bjensen)和 Emily Stanton (uid=estanton)的条目。 - 他们创建了三个角色，为示例企业中的每个部门创建一个角色：销售、营销和会计。每个人条目都包含一个 role 属性，用于标识该人员所属的部门。example Corp. 现在可以根据这些角色创建 ACI。有关角色的更多信息，请参阅 第 4.3.2 节 “关于角色”。
- 它们在
ou=groups分支下创建两个组分支。第一个组cn=administrators包含管理目录内容的目录管理员的条目。第二个组cn=messaging admin含有管理邮件帐户的邮件管理员的条目。此组对应于 messaging 服务器使用的管理员组。示例 Corp. 确保它为消息传递服务器配置的组与为 Directory 服务器创建的组不同。 - 它们在
ou=resources分支下创建两个分支，一个用于会议房间(ou=conference rooms)，另一个用于办公室(ou=offices)。 - 它们创建 类服务(CoS)，根据条目是否属于管理组，为
mailquota属性提供值。这个 CoS 为管理员提供了 100GB 的邮件配额，而普通示例公司。员工拥有 5GB 邮件配额。有关服务类的更多信息，请参阅 第 5.3 节 “关于服务类”。
下图显示了从上面列出的设计步骤生成的目录树：
图 10.1. 示例公司的目录树.
10.1.4. 本地 Enterprise Topology 设计
此时，Example Corp. 需要设计其数据库和服务器拓扑。以下小节详细介绍了每个拓扑。
10.1.4.1. 数据库拓扑
公司设计了一个数据库拓扑，其中人员分支存储在一个数据库(DB1)中，组分支存储在另一个数据库(DB2)中，资源分支、角色分支和
根后缀 信息存储在第三个数据库(DB3)中。图 10.2 “Corp 的数据库拓扑.” 中演示了这一点。
图 10.2. Corp 的数据库拓扑.
每个供应商服务器都会更新 Example Corp. 部署 Directory Server 中的所有三个消费者服务器。这些消费者向一个消息传递服务器以及其它统一的用户管理产品提供数据。
图 10.3. 示例公司的服务器拓扑.
修改 来自兼容服务器的请求将路由到适当的消费者服务器。使用者服务器使用智能引用将请求路由到负责修改数据的主副本的供应商服务器。
10.1.5. 本地企业复制设计
示例. 决定使用多层次复制设计来确保其目录数据的高可用性。有关多倍复制的更多信息，请参阅 第 7.2.2 节 “Multi-Supplier Replication”。
以下小节提供有关供应商服务器架构和 Vendor-consumer 服务器拓扑的更多详细信息。
10.1.5.1. 供应商架构
示例公司在多路复制架构中使用两个供应商服务器。供应商更新另一个目录数据，以便目录数据保持一致。示例 Corp. 的供应商架构如下所述：
图 10.4. 企业供应商架构示例.
10.1.5.2. 供应商消费者架构
下图显示了供应商服务器如何将供应商服务器复制到 Example Corp. 部署 目录中的每个消费者。三个消费者服务器各自由两个供应商服务器更新。这样可确保在供应商服务器中有故障时用户不会受到这个安全漏洞的影响。
图 10.5. 企业示例供应商和消费者架构.
10.1.6. 本地企业安全设计
Corp. 示例决定以下安全设计来保护其目录数据：
- 它们创建一个 ACI，使员工能够修改自己的条目。用户可以修改除
uid、管理器和部门属性以外的所有属性。 - 为了保护员工数据的隐私，他们会创建一个 ACI，仅允许员工及其经理查看员工的主页地址和电话号码。
- 它们在目录树的根目录处创建一个 ACI，允许两个管理员对适当的目录权限进行分组。目录管理员组需要对该目录具有完全访问权限。消息传递管理员组需要对 mailRecipient 和 mailGroup 对象类以及 mailGroup 对象类以及
mail属性的访问。示例 Corp. 还授予消息传递管理员组write、delete，并将权限添加到组子目录以创建邮件组。 - 它们在目录树的根目录处创建常规 ACI，允许匿名访问读取、搜索和比较访问。这个 ACI 拒绝对密码信息进行匿名写入访问。
- 为了防止服务器拒绝服务攻击和不当使用，它们会根据要绑定的目录客户端的
DN设置资源限值。示例 Corp. 允许匿名用户在响应搜索请求时收到 100 个条目，以响应搜索请求、消息管理用户接收 1,000 个条目，以及目录管理员获得无限个条目。有关根据绑定 DN 设置资源限值的更多信息，请参阅 红帽目录服务器管理员指南中的"用户帐户管理"一章。 - 它们会创建一个密码策略，指定密码必须至少为 8 个字符，并在 90 天后过期。有关密码策略的更多信息，请参阅 第 9.6 节 “设计密码策略”。
- 它们创建一个 ACI，为财务角色成员提供对所有付费信息的访问权限。
10.1.7. 本地企业操作决策
公司对其目录的日常运作做出以下决策：
- 每晚备份数据库。
- 使用 SNMP 监控服务器状态。有关 SNMP 的更多信息，请参阅 红帽目录服务器管理员指南。
- 自动轮转访问和错误日志。
- 监控错误日志，以确保服务器按预期执行。
- 监控访问日志到屏幕，以查看应索引的搜索。
有关访问、错误和审计日志的更多信息，请参阅 红帽目录服务器管理员指南中的"监控服务器和数据库活动"一章。
