☰

Netlogon - 域信任安全通道问题 - 仅在某些 DC 上

tag-icon • tag-icon domain-controller netlogon trust-relationship
Netlogon - 域信任安全通道问题 - 仅在某些 DC 上

我们有一个 2 域环境。只有在非高峰时段（登录用户很少）才会出现连接缓慢、身份验证失败和资源挂起的问题。

当域 A 中的用户访问域 B 上的资源并使用 ntlm 身份验证时，就会出现此问题。域 A 中的用户访问域 A 中的资源时不会出现问题，域 B 中的用户访问域 B 中的资源时也不会出现问题。

我们能够将问题追溯到用于 netlogon 流量的安全通道。当域 B 中的资源与一个特定 DC（我将其称为 DC-B1）有安全通道时，一切正常。我们可以跟踪从客户端 (A)->资源 (B)->DC-B1(B)->DC-A1(A)（用于身份验证）然后再返回的流量链。但是，如果 B 中的资源服务器与域 B 中的任何其他 DC 有安全通道，则身份验证将挂起并且永远不会完成。

因此看起来除了 DC-B1 之外，域 B 中的每个 DC 在与域 A 创建域信任安全通道时都遇到了问题。为了进行测试，我们从域 B 中的每个 DC 运行了 nltest /sc_verify:DOMAINA。

从 DC-B1 运行时，响应是即时的。从域 B 上的任何其他 DC 运行时，它会挂起大约 40 秒，然后才显示成功（从未显示错误，只是花了很长时间）。

为什么某些 DC 难以建立和使用域信任安全通道，而同一域中的另一个 DC 却从未出现问题？

值得一提的是，可以正常工作的 DC 是服务器 2008，而不能正常工作的是服务器 2012 R2，但是在迁移到 2012 R2 之前，一些域控制器上就存在该问题，我们只是在迁移完成后才查明问题所在。

谢谢您的帮助。

编辑：附加信息...

比较了每个域控制器一个周末的 NetLogon.log 文件的值……

每一个

[LOGON] SamLogon: Transitive Network logon of DOMAINA\testuser Entered

DC-B1 日志中的记录（这是好的 DC）有相应的

[LOGON] SamLogon: Transitive Network logon of DOMAINA\testuser Returns 0x0

但是在域 B 中的其他 DC 上，每次返回都出现以下 3 个错误之一：

[LOGON] ... DOMAINA\testuser ... Returns 0xC0020017
[LOGON] ... DOMAINA\testuser ... Returns 0xC0020050
[LOGON] ... DOMAINA\testuser ... Returns 0xC000005E

以下是各种错误发生的频率：

77% of errors were: 0xC0020017 RPC SERVER UNAVAILABLE
21% of errors were: 0xC0020050 RPC CALL CANCELED
 1% of errors were: 0xC000005E NO LOGON SERVERS AVAILABLE
 0% of returns were: 0x0 (no error)

我们比较了不起作用的 DC 和起作用的 DC 之间的所有安全设置，但没有发现任何会导致 RPC 问题的原因。对我们下一步该去哪里找有什么建议吗？我们很困惑，为什么“B”中的 2008 域控制器可以毫无问题地与“A”中的 2012 DC 通信，但“B”中的 2012 DC 却无法使用直通身份验证与“A”通信。

编辑：额外请求的信息...

从 DC-B2 和 DC-B3 进行测试运行（结果相同） （此处发起的通过身份验证不起作用）

C:\>nltest /dsgetdc:DOMAINA.local
           DC: \\DC-A3.DOMAINA.local
      Address: \\555.555.555.127
     Dom Guid: 9f3a0668-c245-4493-be03-0f7edf534d27
     Dom Name: DOMAINA.local
  Forest Name: DOMAINA.local
 Dc Site Name: Company
Our Site Name: Company
        Flags: GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9
The command completed successfully

编辑：附加信息...

域 B -> 域 A (GC DC) 的 PortQry 结果

TCP port 135  (epmap service):      LISTENING
TCP port 389  (ldap service):       LISTENING
UDP port 389  (unknown service):    LISTENING or FILTERED
TCP port 636  (ldaps service):      LISTENING
TCP port 3268 (msft-gc service):    FILTERED
TCP port 3269 (msft-gc-ssl service):    FILTERED
TCP port 53   (domain service):     NOT LISTENING
UDP port 53   (domain service):     NOT LISTENING
TCP port 88   (kerberos service):   LISTENING
UDP port 88   (kerberos service):   LISTENING or FILTERED
TCP port 445  (microsoft-ds service):   LISTENING
UDP port 137  (netbios-ns service):     LISTENING or FILTERED
UDP port 138  (netbios-dgm service):    LISTENING or FILTERED
TCP port 139  (netbios-ssn service):    LISTENING
TCP port 42   (nameserver service):     FILTERED

答案1

在听取 Greg 的建议并专注于防火墙之后，我们找到了解决方案。在过去的某个时候，防火墙规则发生了变化，动态端口范围 (49152-65535) 被过滤。一旦网络人员添加规则以允许从域 B 到域 A 的动态端口，问题就完全解决了。

由于某种原因，在服务器 2008 中，这只会在创建安全通道时导致问题。创建安全通道需要 21 秒（或 21 秒的倍数）。建立安全通道后，身份验证工作正常。由于 TCP 通信的性质，21 秒的延迟是有意义的。

在 Server 2012 R2 中，行为有所不同。无论安全通道是否跨域建立，它都会验证失败并破坏安全通道以寻找另一个可用的域控制器。

我不确定为什么这在 Server 2008 中起作用...也许当它无法在临时端口建立连接时，它默认在某个地方的另一个端口？

无论如何，我们都学到了一个宝贵的教训：“如果存在 RPC 连接问题，这（过滤端口）应该是第一个要检查的项目” - Greg Askew

相关内容