我遇到的问题是，如果我将两个可写域控制器之一脱机，似乎没有人会像他们应该的那样“故障转移”使用另一个域控制器 - 我们在网络中运行的应用程序使用 AD 进行身份验证只是不断询问用户名和密码，而从未真正对您进行身份验证，并且依赖于另一个网段上的只读 DC 的外部用户也无法对我们的远程访问网站进行身份验证。
我的域中目前有三个域控制器：DC1、DC2 和 RO1。DC1 和 RO1 是 Server 2019，DC2 是 Server 2012R2。两个可写 DC 都是集成了 AD 的 DNS 服务器，它们的网络适配器配置为相互指向。
DC1 和 DC2 位于同一子网上。RO1 是位于不同网段的只读控制器，以支持由我上方的组织（管理我连接到的通用网络）管理的远程访问解决方案。
过去，如果我让一个或其他本地 DC 脱机，本地用户将故障转移到实际仍在运行的任何一个（如预期的那样），远程用户也会如此，因为 RODC 会获取活动的 DC 进行身份验证。
当前的 DC1 是一个相对较新的添加，取代了一个称为 DC 的。DC1 上线并与 DC 和 DC2 一起加入，一切似乎都很好。我将 DC 拥有的所有 FSMO 角色转移到其替代品 DC1 - netdom 查询 fsmo 显示所有角色都在新的 DC1 上。我们将 DC 降级并使其下线以使其退役，因为它是一台 Server 2012 机器，我们正在从这些机器迁移。清理了一些错误的 DNS 记录，这些记录声称旧的 DC 仍然存在，但除此之外，一切都照常进行。虽然上个补丁周期，我们让 DC2 离线，而 DC1 和 RO1 仍然处于活动状态，但发现了上述与身份验证相关的问题。外部用户根本无法进行身份验证，
不幸的是，我不确定这是为什么。DC1，新的控制器，肯定被域所识别。复制正常 - Repadmin /showrepl 成功，并且 /replsum 没有报告错误。所有涉及的内部机器都可以解析它们的主机名并相互ping通。如果我 ping 域，我可以获得任何一个可写 DC，就像我跟踪域一样。我可以在 DC1 上进行编辑并在 DC2 上查看它们，反之亦然（在 DC1 上进行的组策略等更改肯定存在于更大的网络中）。我可以使用 RODC 并告诉它从 DC1 和 DC2 加载记录而不会出现问题。
但是，如果我让 DC2 脱机，那就是事情横向发展的时候。对我们域的 Ping 或 Tracert 失败，外部用户被拒绝访问，内部用户看到我们的 AD 身份验证应用程序失败，并不断要求输入用户名和密码。然而，相反的情况不会发生 - 如果我让新的 DC1 脱机，本地用户有时会有轻微的延迟，就好像他们的机器在故障转移到 DC2 并成功验证之前试图联系 DC1，而外部用户进来就好了。
事件日志中没有什么特别明显的，而且我能想到的所有内容都显示正确配置。我不知道从哪里开始 - 有没有人有类似的症状，他们已经能够纠正？
该问题最终与管理我们连接的网络的组织专门管理的防火墙设置有关。一些入站/出站规则未正确应用，导致主机在旧域控制器脱机的情况下无法正确故障转移到新域控制器。