我们有一个2域环境。 我们遇到连接速度慢，身份validation失败以及仅在用户login很less的OFF-PEAK时间内挂起资源的问题。
当来自DOMAIN A的用户正在访问位于DOMAIN B上的资源并正在使用ntlm身份validation时，就会出现该问题。 DOMAIN A的用户访问DOMAIN A中的资源，或者DOMAIN B的用户访问DOMAIN B中的资源，则不存在任何问题。
我们能够将问题追踪到用于netlogonstream量的安全通道。 当来自域B的资源有一个特定的DC（我将它称为DC-B1）的安全通道，那么一切工作正常。 我们可以从客户端（A） – >资源（B） – > DC-B1（B） – > DC-A1（A）（用于authentication），然后再返回。 但是，如果B中的资源服务器与域B中的任何其他DC具有安全通道，则authentication将挂起并且从不完成。
所以看起来除DC-B1之外，域B中的每个DC都在通过域A创build域信任安全通道时遇到困难。为了testing，我们在域B中的每个DC上运行了nltest / sc_verify：DOMAINA。
当从DC-B1运行时，响应是瞬时的。 当从域B上的任何其他DC运行时，在显示成功之前挂起大约40秒（从未显示错误，只花了很长时间）。
任何想法，为什么一些DC将难以build立和使用域信任安全通道和另一个DC在同一个域中从来没有问题？
为什么值得工作的是服务器2008，不工作的是服务器2012 R2，但是在迁移到2012 R2之前，在某些域控制器上存在问题，我们只是没有指出问题直到在我们完成迁移之后。
谢谢您的帮助。
编辑：其他信息…
比较每个域控制器的一个周末值NetLogon.log文件…
一切
[LOGON] SamLogon: Transitive Network logon of DOMAINA\testuser Entered logging在DC-B1日志（这是好的DC）有一个相应的
[LOGON] SamLogon: Transitive Network logon of DOMAINA\testuser Returns 0x0
然而在域B的其他区域中，每个区域都有以下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与没有find可能导致RPC问题的DC之间的所有安全设置。 任何build议，我们可以看看下一个？ 我们很困惑，为什么2008年的“B”域控制器与2012年的“A”中的DC没有任何关系，但是“B”中的2012Dcs不能使用通过“A”的身份validation。
编辑：其他请求的信息…
从DC-B2和DC-B3进行testing（相同的结果） （通过身份validation的传递不起作用）
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的PortQry的结果 – >域A（GC DC）
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
在听取了Greg的build议并专注于防火墙之后，我们find了解决scheme。 在过去的某个时候，防火墙规则已经改变，dynamic端口范围（49152-65535）被过滤。 一旦networking人员添加规则，允许dynamic端口从域B到域A，问题就完全解决了。
出于某种原因，在服务器2008年，这只会导致安全通道创build时的问题。 这将需要21秒（或21秒的几倍）来创build安全通道。 安全通道build立后，authentication工作正常。 由于TCP通信的性质，21秒的延迟是有意义的。
在Server 2012 R2中，行为是不同的。 无论安全通道是否通过域build立，都将无法validation并破坏安全通道以寻找另一个可用的域控制器。
我不知道为什么这在所有Server 2008的工作…可能是默认的另一个端口的地方，当它无法build立连接在短暂的端口？
无论如何，我们已经吸取了宝贵的教训：“这（过滤的端口）应该是检查是否存在RPC连接问题的第一项” – Greg Askew