我知道，由于 Kerberos 和 SPN 问题，在 Windows 域控制器上进行 LDAP 的负载平衡或故障转移通常不是一个好主意。
但是，我有许多非 Windows 应用程序使用 LDAP 进行身份验证和授权。它们现在只指向一个域控制器，最好有一个 VIP 和一个池，所有 DC 都位于其后面。
那么当我看到这个时，这是怎么回事？：
https://devcentral.f5.com/questions/ad-dcs-behind-f5
F5 有什么特别的功能吗？它只是回退到 NTLM 吗？还是它只是使用简单的 LDAP 绑定到 AD？（或 SLDAP 绑定）。
非 Windows 客户端利用 LDAP 的最佳方式是什么？它们是否应该开箱即用地设计为使用 DNS 定位器 SRV 记录？是否应该部署 AD-LDS 并对其进行负载平衡？
我是否遗漏了什么？
答案1
是的，想要与 Active Directory 交互的应用程序确实应该设计时应使用适当的 DC 定位程序（这些程序都有详尽的文档记录）；不幸的是，很多时候事实并非如此。
通常，您可以通过将 LDAP 应用程序指向 Active Directory 域名而不是特定的 DC 来解决此问题，因为每个 DC 都会自动为指向其 IP 地址的域名注册一个 A 记录，因此这将作为 DNS 循环工作；但是，这可能会导致两个重大问题：
- 如果 DC 关闭，它仍将包含在 DNS 答复中；如果应用程序不够智能而无法尝试另一个，这可能会导致 LDAP 失败。
- 这不会考虑任何 Active Directory 站点拓扑；如果您拥有地理分散的环境，您最终可能会使用位于伦敦的应用程序通过缓慢和/或不可靠的 WAN 链接向位于澳大利亚的 DC 进行身份验证。
一个稍微好一点的解决方案是为 LDAP 应用程序创建自己的 DNS 记录作为指向特定 DC 的 CNAME 记录，例如ldap.example.com指向dc1.example.com，并在其上设置慢速 TTL（例如 60 秒）；然后，您可以配置应用程序以满足ldap.example.com其所有 LDAP 需求。如果/当 DC1 发生故障时，您可以重新映射ldap.example.com到dc2.example.com，慢速 TTL 将确保应用程序尽快意识到更改，从而最大限度地减少停机时间。
无论如何，最好避免负载平衡解决方案，因为 LDAP 根本不是设计用于与它们一起工作的，并且它们可能会加载到任何类型的问题。
答案2
我见过的几乎所有非 Windows LDAP 身份验证产品都能够使用 DNS 条目。您可以指向域的根目录，而不是指向特定服务器。这在绝大多数情况下都应该有效。
之所以如此，是因为如果您在域的根目录（例如 example.com）进行查找，它应该返回所有域控制器的 IP。这允许标准循环 DNS 接管，而无需任何类型的专门设置。
答案3
使用负载平衡器的一个挑战是，根据活动，某些应用程序可能会请求 DirectoryEntry 的句柄。DirectoryEntry 包含服务器名称。这在更新中更常见，但也可能出现在读取/查询中。显然，在这种情况下您不会通过负载平衡器。它是否足以进行身份验证？也许。
我了解到，如果你提供一项服务，人们可能会将其用于你不希望的用途。那么你设置的“仅身份验证”VIP 呢？也许有人决定将其用于其他用途。这真的很重要。如果它崩溃了会发生什么？
另一个问题是健康检查是什么？域控制器在端口 389/636 上启动但无法正常运行的情况并不少见。因此，直接进行端口检查可能不够好。
传统上，Active Directory 连接弹性（DC 定位器进程）被下推到客户端。当您开始对其进行调整以使其“高度可用”时，您就承担了问题的所有权。其中一些问题可能难以诊断和解决。谁会为您提供支持？F5？微软？祝你好运。
答案4
为了应对这种情况，我在 VIP 中配备了 3 台服务器。
此外，使用域名通常也不好，因为如果应用程序不具备站点感知能力（大多数应用程序都具备站点感知能力），它将命中返回列表中的第一个 DC。该 DC 可能位于该国的任何地方，这对 WAN 负载和延迟来说都是不利的。