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