在工作中，我们正处于身份管理项目的早期阶段。这一切都是在高等教育背景下进行的，我们有几千名教职员工和大约两万名学生。
有人使用过 Sun LDAP 服务器和 AD 域 (kerberos 领域) 来存储密码吗？有人运行过包含 25 万个条目的 AD 域吗？
我们的身份管理的一个选择是将活跃员工推送到 AD，并将另一份密码/身份信息推送到 LDAP。如果我们这样做，我们需要有一个中心位置来更改密码，这样如果您更改 AD（或 ldap）密码，更改会同步到另一个（或允许它们分开）
另一种选择是让 AD 成为密码的唯一权威机构，然后我们必须拥有所有附属机构（以及所有旧附属机构）十年或二十年的主体，因此我们可能在 AD 中拥有 25 万个实体，其中只有 2 万到 3 万个实体会以任何频率被访问。
AD 会在负载下崩溃吗？还有其他方法可以让 Sun 的 LDAP 和 AD 之间的密码保持同步吗？其他人的经验是什么？
答案1
这是一个很好的起点：http://technet.microsoft.com/en-us/library/cc756101(WS.10).aspx。
此工具已经过时了（它是为 Windows 2000 开发的，只支持 < 1 Ghz 的 CPU），但仍然表示 3-4 个 DC 足以满足 500,000 个用户的需求，其中 50,000 个用户每天都在活动。我认为使用当今的硬件管理这样的数据库不会有任何问题。
答案2
我一直与高等教育客户合作讨论您正在调查的情况。
AD 处理这么多对象不会有问题。我曾经在客户环境中工作过，那里的对象数量是这个数字的几倍。
在您的场景中，我与之合作的许多客户最终都通过 AD 禁用了本地密码更改，并强制人们通过某种门户与某种工具对话，该工具将密码输入到所有需要独立副本的系统中。除非它出现故障并且不同步，否则这很好。我也曾使用过 Kerb 场景，虽然它可以工作，但很多人并不知道如何运行或支持它，因此您可能在运营人员配备方面遇到了麻烦。
您还可以查看 Microsoft 的 ILM 之类的产品，它可以捕获 AD 中的密码更改并允许您将其转发到其他系统（例如 Sun LDAP 等）。这允许人们通过自己开发的应用程序使用 AD 中的本机密码更改功能。
拥有校友、申请、社区等附属机构的人是可以的。我在这里提醒大家的一件事是，请记住，像每个人/经过身份验证的用户这样的默认权限会覆盖更广泛的范围，因此您需要使用代表附属机构的组来设置 ACL，这些附属机构代表了您想要允许访问的实际用户（例如活跃学生、教师、员工等）。我还试图让人们定期清理与申请机构有关联的人的帐户。
总的来说，我极力主张不要使用并行 LDAP 目录。一般来说，让两个（或更多）服务做同样的事情只是浪费时间和金钱。
答案3
AD 会在负载下爆炸吗？
我曾是 80 多家在线/地面职业学校的 ASP.NET 门户开发人员，这些学校大多位于美国，拥有超过 250,000 个 AD 对象，并且可能拥有积极的60k 区域的账户使用情况（据我所知)。我从未见过 AD 出现任何生产问题。请记住，我们当时还拥有世界上第二大 Exchange/AD 对象。如果设计和配置正确，AD 可以承受负载。我曾经对 Microsoft 的 AD 持怀疑态度，或者我曾经认为它是 M$LDAP，但如果根据您的用例/环境进行配置，它似乎相当稳定、可靠。
还有其他方法可以保持 Sun 的 LDAP 和 AD 之间的密码同步吗？
我不能代表 Sun LDAP 或同步发言。AD 复制（本身）可靠且及时。思考我们总共有 4 到 6 台 AD 服务器，但我记不起出现过任何问题。
您是否已经实施了 AD 并希望附加 Sun LDAP，还是反过来？也许坚持使用一种解决方案（Sun 或 Microsoft，我没有偏好）会更好，因为管理大量帐户可能会成为一个问题。我经常发现，在创建混合解决方案时，我可能有也可能没有使事情易于管理的工具。我绝不是 LDAP/AD 大师，但即使编程 AD 帐户并使用 AD MMC 管理单元工具查找帐户也相当繁琐。
答案4
每种方法都有其优点和缺点。
使用 Sun LDAP 进行应用程序身份验证和授权的优点在于，它易于跨网络和 DMZ 提供支持。在存在大量孤岛的大学环境中，这可能是一个真正的优势，因为您可以设置灵活的标准，而这些标准很可能会被真正遵守……LDAP 易于跨防火墙管理，灵活，并且您可以通过多种方式保护您的应用程序，从简单的 LDAP 绑定到 Siteminder 等 SSO 解决方案。
最大的缺点是您要购买很多软件，而现在您需要 Unix/LDAP 人员。
如果您确实想要单密码集成，则可以使用 ILM 之类的元目录或 Ping 之类的联合工具来保持活跃的 AD 用户与 LDAP 同步。Microsoft 解决方案的优点是更容易“毕业”MCSE 类型，并且当夜间出现意外时，您可以获得“一劳永逸”的能力。
采用 AD 模型是可行的——AD 可以扩展到那么高。在我看来，最大的问题是你需要更多服务器和更多资源，而在 DMZ 中支持中央 AD 可能是一种不太愉快的体验。在我看来，考虑到我们所采用的网络设计理念和安全策略，在客户端计算环境之外提供 AD 服务是一场噩梦。
如果我处于您的位置，考虑到您问题中的信息，我会考虑混合 LDAP/AD 方法。让 AD 为 20-30k 活跃用户提供服务，并将其他 250k 纳入 Sun 系统。最好的答案可能在很大程度上取决于您的配置方式...