设计挑战设计一个 LDAP 用户管理解决方案应满足以下要求：
- 服务一个集群环境：该环境严重依赖于一个一致的注册表视图；所有集群成员必须在任何时候都能访问相同的注册表信息。
- 包括所有用户和组特权：典型的 LDAP 解决方案把登录凭证和实际组成员分离开来。该解决方案必须能够管理上述两项。
- 管理一个注册表：典型的 LDAP 解决方案把系统用户和普通用户分开。这就确保当 LDAP 不可访问时，root 用户和其他功能用户仍然能进行系统维护。该设计的初始目标是使所有用户都在一个注册表中。
- 高可用性和 LDAP 故障可恢复性：因为设计的目标是要在一个 LDAP 注册表中配置所有用户，所以该设计应包括能够保证 root 用户和其他系统用户始终可用。
- 最终目标是在中央 LDAP 服务器群中建立 AIX 注册表。
环境和产品限制在这之前，我们的集群用户环境是用普通文件和 rsync 机制进行管理。对于定期发生的批量更改，基于普通文件的解决方案也能运行得很好。由于会进行毫无规则的更改（如密码更改），所以问题也随之产生。在主机上设置密码和将密码分发给所有集群成员之间总是存在时间差。在此期间，当进行（集群的）身份验证时，集群应用程序会失败。
我们的安全性基础架构严重依赖于使用组分配所提供的特权。由于历史遗产和易用性，这些普通用户组也被用于向系统用户提供相似的组特权。将普通用户和系统用户分开是可行的。但是，用于保持两个注册表同步的管理基础架构就变得复杂了，而且可能不如预期可靠。
这也适用于将系统用户和普通用户分开。总是有一定程度的重叠情况出现，而导致难于管理。
当将 LDAP 视为一个可行的网络化用户管理注册表时，便可以清晰地看到 LDAP 有一些可用性选项，但缺乏基本的选项。LDAP 提供的最重要的特性是对等域设置的概念。这就允许配置两个或多个 LDAP 服务器，每个服务器都可以更新其相邻服务器的 LDAP 更改。但是，如果 LDAP 出现问题（处于维护模式或无法访问），备用可用性特性将不可用。
考虑 AIX 时，这个 SYSTEM（身份验证方法）参数能提供支持多种验证方法的选项，但是 registry 参数只支持一个注册表。因此，并没提供相应的参数告诉 AIX 要使用的那个注册表（也就是确实可用的那个）。
AIX 提供了内置的可用性框架，该框架能填补系统和子系统特性中的空缺：RSCT。
设计概述下图描述了 LDAP 的配置原理。
图 1. LDAP 配置 - 至少两个 LDAP 服务器，进行对等配置
- 为 AIX 用户管理配置的 LDAP
- 包括所有 root 用户在内的所有系统帐户
- 使用 memberfulldn=yes 选项
- 用于密码 lastupdate 标记的用户秒数
- RSCT 监控和程序，以设置用户管理环境
- 从 LDAP 中定期提取，在普通文件注册表 (/etc/passwd) 中应用最新
- 添加一个 inittab 入口，设置注册表选项为文件
- 在启用 RSCT 之后，RSCT 监控就开始检测 LDAP 的可用性并配置返回到 LDAP 的注册表参数。
需求本小节将介绍可用性需求和产品需求，以及系统所处的用户管理状态。
可用性需求
保证注册表始终可用：
- 启动进程中
- LDAP 服务器发生故障的情况下
- LDAP 可用性问题或模式错误的情况下
产品需求
- AIX V6.1
- IBM Tivoli® Directory Server V6.3
- IBM AIX RSCT V1.7
- IBM DB2® V9.5
用户管理状态
下图描述了系统所处的两种状态。
图 2. 用户管理状态 如果 LDAP 正常工作（在这个配置中，如果 root 用户密码可从 LDAP 中检索的话），那么注册表就定义为 LDAP。
注意：您可以定义自己的规则来决定 LDAP 是否可用。root 用户是可供使用的最重要的用户，该概念中的监控可用性就是专注于在 LDAP 中查找 root 用户信息。
系统刚刚启动时，如果网络停止运行，或者如果无法获取 LDAP，那么注册表参数会切换到文件（files）。 |
