☰

有关多宿主服务器 Active Directory 设计的建议

tag-icon • tag-icon networking domain-name-system active-directory domain-controller
有关多宿主服务器 Active Directory 设计的建议

我受客户委托，针对具有以下要求的场景设计一个可行的 Active Directory（简化后，实际上要糟糕得多）：

  • 有一个用于客户端系统的子网。
  • 有一个用于服务器系统的子网。
  • 两个网络没有连通。
  • 每个服务器应该有两块网卡，一块在服务器网络上，另一块在客户端网络上。
  • 客户端和服务器之间的流量应该仅在客户端的网络上流动。
  • 服务器之间的流量应该仅在服务器的网络上流动。
  • 这也适用于域控制器。

不用说，这与 Active Directory 使用 DNS 定位域控制器的方式不太相符；任何可能的方法都可能导致以下情况之一：

  • DC 在域 DNS 中注册其“客户端”IP 地址；客户端将使用该地址与他们通信，服务器和 AD 复制流量也将如此。
  • DC 在域 DNS 中注册其“服务器端”IP 地址；服务器将使用该地址与它们通信，并且复制流量将在该网络上流动，但客户端将无法访问它们。
  • DC 将注册两个都域 DNS 中的 IP 地址；任何人都无法猜测任何系统将如何访问这些地址。

当然，这些要求完全是疯狂的，不可能同时满足所有要求，除非使用疯狂的解决方案，例如在两个网络上拆分 DNS 服务并手动填充其 SRV 记录（argh）或让服务器使用 DNS 定位 DC，客户端使用 WINS 定位 DC（double-argh）。

我想到的解决方案是在“服务器”网络上安装两个 DC，在“客户端”网络上安装两个 DC，定义两个 AD 站点，并仅使用 DC 复制流量跨越两个网络之间的边界。这将仍然需要一些 DNS 调整，因为每个服务器都会仍然有两张网卡（除了两个服务器端 DC 和纯后端服务器），但它至少有一些工作的机会。

除了尽快逃离之外，还有什么建议吗？

答案1

首先我要说的是，我同意其他许多人的意见——要么说服客户，要么逃跑。

但是，考虑到您列出的要求（还有许多未列出的要求），我至少可以想到（并部分测试）实现这一目标的基础。

有几个具体方面需要考虑。

  1. Active Directory 域服务复制
  2. 客户端/成员服务器的 DC 定位器进程
  3. 非 AD DS 服务的名称解析和流量

第一点和第二点有很多共同之处 —— 总的来说，我们在这方面都听从微软的安排，并且必须在微软的 AD DS 流程范围内工作。

第三，我们还有一点发挥空间。我们可以选择用于访问服务的标签（文件、数据库实例等）。

以下是我的建议：

构建您的域控制器 (DC)

  • 可能至少有两个。
  • 每个 DC 将有两个 NIC，每个 IP 网络/AD DS 站点一个 - 暂时称为 clt 和 srv。
  • 仅有的现在在 srv 网络中的每个 DC 中配置一个 NIC。

正确配置 AD 站点和服务

  • srv 站点和子网
  • clt 站点和子网
  • 取消选中从站点 -> 站点间传输 -> 右键单击​​“IP”中的“桥接所有站点链接”
  • 如果 DEFAULTIPSITELINK 存在（或者您已重命名），则删除它，这样就不会配置站点链接。请注意，这对我来说是未知的——KCC 可能会将错误转储到目录服务事件日志中，指出两个站点（srv 和 clt）在不同时间间隔内未连接。但是，两个 DC 之间的复制仍将继续，因为它们可以使用同一站点中的 IP 相互联系。

在 AD DS 集成 DNS 中配置附加区域

  • 如果您的 AD DS 域是acme.本地，创建第二个启用动态更新的主 AD 集成区域，名为本地。

在 DC 上配置第二个 NIC

  • 这些 NIC 将是 clt 网络/站点中的 NIC。
  • 设置他们的 IP
  • 这是神奇的部分-- 适配器属性 -> IPv4 属性 -> 高级 -> DNS 选项卡 -> 将此连接的 DNS 后缀设置为本地-> 勾选注册此连接... -> 勾选使用此连接的 DNS 后缀... -> 一路确定。
  • ipconfig /registerdns
  • 这将在 clt.acme.local 区域中注册 clt NIC IP——为我们提供一种方法来控制稍后使用哪个 IP/网络。

配置成员服务器 NIC

  • clt 站点中的成员服务器 NIC 也必须具有其 DNS 后缀和复选框，如上所示。
  • 这些设置可以与静态和 DHCP 一起使用，没关系。

在站点中配置 DNS [stub] 解析器行为

  • DC -> 配置 DC srv NIC 以使用其自身和其他 DC srv NIC IP。将 DC clt NIC DNS 留空（但需要静态 IP）。（DC DNS 服务器仍将听在所有 IP 上默认启用）。
  • 成员服务器 -> 配置成员服务器 srv NIC 以使用 DC srv 站点 IP。将成员服务器 clt NIC DNS 留空（可以使用静态 IP）。
  • 客户端/工作站 -> 配置 DNS（通过 DHCP 或静态）以使用 DC 的 clt NIC IP。

适当配置映射/资源

  • 当服务器互相通信时，请务必使用 .acme.local-> 将解析为 srv 网络 IP。
  • 当客户端与服务器通信时，请务必使用 .clt.acme.local -> 将解析为 clt 网络 IP。

我在说什么？

  • 由于 DC 可以相互解析并相互连接，因此 AD DS 复制仍将发生。acme.local 和 _msdcs.acme.local 区域将仅包含 DC srv NIC IP 的 AD DS 复制将仅在 srv 网络上发生。
  • 成员服务器和工作站的 DC 定位器进程将正常运行——尽管在站点未知的情况下，各种 AD DS 进程的各个部分可能会出现延迟，但如果返回多个 DC IP，它们将不断尝试、失败并继续运行，直到其中一个能正常工作。对 DFS-N 的影响也尚未完全评估——但仍将正常运行。
  • 如果您按照前面所述使用 .acme.local 和 .clt.acme.local 标签，非 AD DS 服务将正常运行。

我还没有完全测试过这一点，因为它相当荒谬。 然而，这个（哇，很长的）答案的重点是开始评估它是否可能 - 而不是是否应该这样做。

@评论

@Massimo 1/2 不要混淆 acme.local 区域中的多个 AD DS 站点，因此不要混淆 acme.local 区域中这些站点中的 DC 填充的 SRV 记录与 clt.acme.local 区域中所需的 SRV 记录。客户端的主 DNS 后缀（以及它们加入的 Windows 域）仍将是 acme.local。客户端/工作站只有一个 NIC，主 DNS 后缀可能来自 DHCP，设置为 acme.local。

clt.acme.local 区域不需要 SRV 记录，因为它不会用于 DC 定位器进程。它仅供客户端/工作站使用 clt 网络中的成员服务器 IP 连接到成员服务器的非 AD DS 服务。AD DS 相关进程（DC 定位器）不会使用 clt.acme.local 区域，而是使用 acme.local 区域中的 AD DS 站点（和子网）。

@马西莫 3

clt 和 srv AD DS 站点都会有 SRV 记录 - 只是它们会存在于 acme.local 区域中 - 请参阅上面的注释。clt.acme.local 区域不需要 DC 相关的 SRV 记录。

客户端将能够很好地找到 DC。客户端 DNS 服务器指向 DC 的 clt IP。

当客户端上的 DC 定位器进程启动时

  • 如果客户端知道其站点，则 DNS 问题将是 _ldap._tcp.[site]._sites.dc._msdcs.acme.local SRV。这将返回已注册 SRV 记录的站点特定 DC。
  • 如果客户不是知道其站点，DNS 问题将是 _ldap._tcp.dc._msdcs.acme.local SRV。这将返回所有 DC。客户端将尝试绑定到 DC 的 LDAP，直到找到一个响应的 LDAP。当客户端找到一个时，它会执行站点查找以确定客户端的站点，并将该站点缓存在注册表中，以便将来的 DC 定位器实例更快地发生。

@马西莫4

呃，好主意。我认为有两种方法可以解决这个问题。

  1. 影响较小的（与下面的 2 相比）是在 hosts 文件中创建一个条目在客户端/工作站上对于 dc1.acme.local 和 dc2.acme.local 指向 DC 的 clt NIC IP。

或者

  1. 在每个 DC 上的 netlogon.dns 文件中手动创建必要的 SRV 记录。这可能会对服务器网络产生一些影响。如果配置了此功能，成员服务器有时可能会与 clt 网络上的 DC 进行通信。

总而言之，这一切都不尽如人意，但这不一定是最终目标。也许客户只是在测试你的技术能力。把它放在他们的会议桌上，告诉他们“这样就可以了，但我要向您收取 4 倍于我正常费用的配置和支持费用。您可以通过执行 [正确的解决方案] 将其降低到 1.5 倍于我正常费用 - 0.5 倍的 PITA 费用。”

如前所述，我的建议是说服别人或逃跑。但这确实是一个有趣的小练习。:)

答案2

最后我选择了两个站点的解决方案：

  • 两个 DC 用于“服务器”网络，两个 DC 用于“客户端”网络。
  • 两个 AD 站点，一个用于“服务器”网络，一个用于“客户端”网络。
  • “服务器”网络中的 DC 只会有一个 NIC（客户端根本不会与它们对话），所以这很容易。
  • “客户端”区域中的 DC 将有两个，但只会在 DNS 中注册其客户端的 DC。
  • 服务器将与他们的 DC 对话，客户端将与他们的 DC 对话。

当然，这意味着在两个网络之间启用复制流量；“客户端”网络中的 DC 将仍然在“服务器”网络上有一个 NIC，但由于它不会在 DNS 中注册，该网络中的 DC 将使用其客户端 IP 地址联系它们；因此该 NIC 实际上完全无用，并且需要打开一些防火墙端口。唯一的其他选择是破坏 DC 的hosts文件，但我们希望可以避免这种情况。

好吧，我认为这是可以做的最好的事情，可以满足尽可能多的（疯狂的）要求。

谢谢大家的建议:-)

答案3

首先，当我们为客户提供服务时，我们应该问他们的需求是什么。让客户明白他们的复杂程度是不必要的。

  • 客户数量是多少？
  • 这都是内部流量吗？
  • 域的功能级别是什么？
  • 是否正在使用 TLS 协议？

使用吻方法 - 将创建两个 VLAN“SVR”和“CLT”，启用 SSL/TLS 并称之为一天......

相关内容