Active Directory身份验证负载平衡和故障转移

对于针对Active Directory DC进行身份验证的应用程序，显然最好将它们指向主域DNS记录，而不是将特定DC用于故障转移，负载平衡等。

那些迫使您对DC的IP进行硬编码的应用程序的最佳实践是什么？我们可以对负载均衡器的IP地址进行硬编码，因此，如果一个DC断开，该应用程序仍将能够进行身份验证。有更好的选择吗？

Active Directory已经内置了负载平衡技术。Windows客户端知道如何在其自己的站点中找到冗余域控制器，以及在第一个不可用时如何使用另一个域控制器。只要您有冗余DC，就无需执行额外的负载平衡，例如“群集” DC。

在某种程度上，您可以将Active Directory站点视为“负载平衡器”，因为该站点中的客户端将随机选择同一站点中的DC。如果站点中的所有DC均发生故障，或者该站点中没有DC，则客户端将选择另一个站点（下一个站点或随机选择）。

您可以通过将VIP放置在硬件负载平衡器上，并使VIP负载平衡在多个域控制器之间，来为加入域的客户端平衡Active Directory提供的DNS服务。然后在您的客户端上，将该VIP用作TCP / IP配置中的首选DNS服务器。

我现在正在为全球基础架构进行此操作，并且效果很好。

但这仅适用于DNS服务。

不要尝试对您的域控制器进行负载平衡以进行身份​​验证。它自找麻烦。至少您必须做很多复杂的自定义SPN工作，并且将自己排除在Microsoft支持范围之外。从您应该阅读的博客中，我将引用他的话：

回到供应商那里，告诉他们您不认为它们是AD集成的，您将找到其他解决方案。

现在，对于要求您键入域控制器的IP地址的应用程序？好吧，我只想重申一下我的评论：

谁编写了一个强迫您将域控制器的IP地址硬编码到其中的应用程序，都不知道他或她在做什么。

从来没有充分的理由对IP进行硬编码或使用IP来解决AD查询。没有针对不良实践的最佳实践。

该问题的其他几个答案似乎都假定除了Microsoft知道的应用程序之外没有其他世界。不幸的是，事实并非如此，作为原始问题的证据：

那些迫使您对 DC的IP 进行硬编码的应用程序的最佳实践是什么？

尽管Microsoft不支持或不建议在Active Directory前面使用NLB解决方案，但确实存在一些用于验证非Microsoft AD感知应用程序的选项。

• 了解AD LDS中的代理身份验证
• F5认证的iApp用于负载均衡LDAP
• 通过SASL的通过认证

外部“负载平衡” AD的实际需求很少，并且很难正确执行。需要典型查询可能会正常工作，但是典型的Windows客户端和应用程序需要执行更新。Windows客户端尝试与特定的dc建立亲缘关系，因此，如果它更新某些内容并立即尝试后续操作，它将命中相同的dc。应用程序开发人员做同样的事情。如果编写用于创建用户帐户的代码，然后尝试在1毫秒后更改该帐户的密码，则需要输入相同的DC。

如果您要使用某些负载均衡器解决方案来进行前端AD，则必须确保这些方法和关联性不会中断。

如果需要可用性，而不是平衡负载，则群集可能更合适（除了蠕虫的群集外）。

在大型AD实施中，一种更传统的方法是识别多数消费者，并将他们放置在具有自己DC的站点中。例如，如果您有五台Exchange服务器，则为这些服务器的子网创建一个站点，然后在该站点中放置专用的GC。同样适用于其他服务器，例如SharePoint。