第 8 章 目录设计示例


目录服务的设计取决于企业的大小和性质。以下示例是开发实时目录服务部署计划的起点。

8.1. 本地企业设计示例

小公司 ExampleCom 是一个汽车部分制造商,有 500 名员工。ExampleCom 决定部署红帽目录服务器,以支持其使用的启用了目录的应用程序。

8.1.1. 本地企业的数据设计

为了决定目录要存储的数据类型,ExampleCom 会创建一个执行站点调查的部署团队。部署团队决定以下关键点:

  • 消息传递服务器、Web 服务器、日历服务器、人工资源应用程序和白页应用将使用该目录。
  • 消息传递服务器对 uidmailServerNamemailAddress 等属性执行 精确 搜索。为提高数据库性能,ExampleCom 将维护这些属性的索引。

    有关使用索引的更多信息,请参阅使用索引提高数据库性能

  • 白页应用程序搜索用户名和电话号码。因此,目录必须处理大量频繁子字符串、通配符和返回大量结果集的模糊搜索。ExampleCom 公司决定维护以下索引:

    • cn,sn, 和 givenName 属性 的存在,equality,approximate, 和 substring 索引。
    • telephoneNumber 属性 的存在,equality, 和 substring 索引。
  • 目录必须维护用户和组信息,以支持组织中部署的基于 LDAP 服务器的内部网。目录管理员组将管理大多数 ExampleCom 用户和组信息。但是,ExampleCom 需要一组单独的邮件管理员来管理电子邮件信息。
  • 目录必须存储用户公钥证书,以支持公钥基础架构(PKI)应用,如 S/MIME 电子邮件。

8.1.2. 本地企业的架构设计

ExampleCom 目录支持的应用程序需要 userCertificateuid (userID)属性。因此,ExampleCom 部署团队决定使用 inetOrgPerson 对象类代表目录中的条目,因为它允许这两个属性。

此外,ExampleCom 希望通过创建 examplePerson 对象类来代表员工来自定义默认目录模式。这个对象类来自 inetOrgPerson 对象类。examplePerson 允许一个 exampleID 属性。此属性包含分配给每个员工的特殊员工号码。以后,ExampleCom 可以在 examplePerson 对象类中添加新属性。

8.1.3. 本地企业目录树设计

根据准备的数据和模式设计,ExampleCom 会创建以下目录树:

图 8.1. ExampleCom 的目录树

  • 目录树的根目录为 dc=example,dc=com,它是公司互联网域名。
  • 目录树有四个分支点:

    • ou=people
    • ou=groups
    • ou=resources
    • ou=roles
  • 所有 ExampleCom people 条目都是在 ou=people 分支下创建的。

    people 条目是 个人、OrganizationPerson、inetOrgPersonexamplePerson 对象类的所有成员。uid 属性唯一标识每个条目的可分辨名称(DN)。例如,公司包含 Babs Jensen 的条目(uid=bjensen)和 Emily Stanton (uid=estanton)。

  • 对于 ExampleCom 中的每个部门,将创建 销售营销和 会计 角色。

    每个个人条目都包含一个 role 属性,用于标识个人所属的部门。现在,公司可以根据这些角色创建访问控制指令(ACI)。

    有关角色的更多信息,请参阅 第 4.3.2 节 “关于目录服务器中的角色”

  • 以下组分支在 ou=groups 分支下创建:

    • cn=administrators 组包含管理目录内容的目录管理员的条目。
    • cn=messaging admins 组包含仅管理邮件帐户的邮件管理员。此组对应于消息传递服务器使用的管理员组。
  • ou=resources 分支下的以下分支被创建:

    • 会议室的 ou=conference rooms 分支。
    • 办公室的 ou= offices 分支。
  • 创建类服务(CoS),根据条目是否属于管理组,为 mailquota 属性提供值。此 CoS 为管理员提供 100GB 邮件配额,而普通 ExampleCom 员工则具有 5GB 邮件配额。

8.1.4. 本地企业拓扑设计

ExampleCom 部署团队开始设计目录数据库和服务器拓扑。

examleCom 设计以下数据库拓扑:

图 8.2. 本地企业数据库拓扑

  • 数据库 1 存储 ou=people 分支。
  • 数据库 2 存储 ou=groups 分支。
  • 数据库 3 存储 ou=resourcesou=roles 分支,以及 dc=example,dc=com root 后缀。

examleCom 设计以下服务器拓扑:

图 8.3. 本地企业服务器拓扑

ExampleCom 决定具有两个供应商服务器和三个消费者服务器的服务器拓扑。两个供应商各自更新在目录服务器部署中所有三个用户。

消费者向一个消息传递服务器和其他服务器提供数据。修改来自兼容服务器的请求会路由到适当的消费者服务器。消费者服务器使用智能引用将请求路由到负责修改数据的主副本的供应商服务器。

8.1.5. 本地企业复制设计

ExampleCom 决定使用多层次复制设计来确保其目录数据的高可用性。有关多层次复制的更多信息,请参阅 多层次复制

multi-supplier 架构

ExampleCom 在多层次复制架构中使用两个供应商服务器。供应商更新另一个目录数据,以便目录数据保持一致。下图显示了 ExampleCom 的供应商层次架构。

图 8.4. ExampleCom multi-supplier 架构

provider-consumer 架构

下图显示了供应商服务器如何在目录的 ExampleCom 部署中复制到每个消费者。

图 8.5. ExampleCom provider-consumer 架构

两个供应商服务器都会更新三个消费者服务器。这样可确保当其中一个供应商服务器失败时,消费者不会受到影响。

8.1.6. 本地企业安全设计

为了保护目录数据,ExampleCom 会创建以下访问控制指令(ACI):

  • ACI,允许员工修改其条目。用户可以修改除 uid管理器 和部门属性 之外的所有 属性。
  • 一个 ACI,只允许员工和员工经理查看员工主页地址和电话号码来保护员工数据的隐私。
  • 目录树的根目录中的 ACI,为两个管理员组授予适当的目录权限:

    • 目录 administrator 组需要对 目录具有完全访问权限。
    • 消息传递管理员组需要 写入 和删除mailRecipientmailGroup 对象类的访问,以及这些对象类允许的属性,包括 mail 属性。ExampleCom 还授予消息传递管理员组、删除,以及向组 子目录添加权限以创建邮件组。
  • 目录树根目录下的常规 ACI,允许匿名访问 读取搜索 和比较 访问。另外,这个 ACI 拒绝匿名用户访问密码信息。
  • 一个 ACI,为 accounting 角色授予所有 payroll 信息的访问权限。

另外,ExampleCom 决定以下安全措施:

  • 为了防止服务器拒绝服务攻击和不当使用,ExampleCom 根据目录客户端用来绑定的 DN 设置资源限值:

    • 匿名用户可以一次接收 100 个条目,以响应搜索请求。
    • 消息传递管理员可以接收 1,000 个条目。
    • 目录管理员可以收到无限数量的条目。
  • ExampleCom 创建一个密码策略,其中密码必须至少为八个字符,并在 90 天后过期。

    有关密码策略的更多信息,请参阅指定密码策略

8.1.7. 本地企业的操作决策

公司就其目录的日常操作做出以下决策:

  • 每晚备份数据库。
  • 使用 SNMP 监控服务器状态。
  • 自动轮转访问和错误日志。
  • 监控错误日志,以确保服务器按预期执行。
  • 监控访问日志,以指示可以索引的搜索。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat