这是一种简化，并且为了保护无辜者，名称已被更改。
The assets:
Active Directory Domains
corp.lan
saas.lan
User accounts
[email protected]
[email protected]
Servers
dc.corp.lan (domain controller)
dc.saas.lan (domain controller)
server.saas.lan
域之间存在单向信任，因此 corp.lan 中的用户帐户可以登录 saas.lan 中的服务器
dc.corp.lan 和 dc.saas.lan 之间没有防火墙
server.saas.lan 位于防火墙区域，并且存在一组规则，因此它可以与 dc.saas.lan 通信
我可以使用以下方式登录 server.saas.lan[电子邮件保护]- 但我不明白它是如何工作的。如果我查看防火墙日志，我会看到 server.saas.lan 和 dc.saas.lan 之间有大量的登录聊天
我还看到 server.saas.lan 和 dc.corp.lan 之间有大量 DROPPED 聊天。据推测，这是因为 server.saas.lan 正在尝试进行身份验证[电子邮件保护]但是不存在允许这些主机之间通信的防火墙规则。
然而，[电子邮件保护]可以成功登录到 server.saas.lan — 一旦登录，我可以“echo %logonserver%”并获取 \dc.corp.lan。
所以……我有点困惑帐户实际上是如何进行身份验证的。当 server.saas.lan 无法与 dc.corp.lan 通信后，dc.saas.lan 最终会与 dc.corp.lan 通信吗？
只是想弄清楚需要更改/修复/修改什么。
答案1
您并没有向我们提供足够的细节来肯定地回答这个问题。例如，您没有向我们提供任何有关被阻止流量的确切性质、流量类型、林或外部信任、每个域的成员之间允许使用哪些端口、您究竟如何尝试连接到服务器（远程桌面？驱动器映射？）等信息。
无论如何我都会尝试一下。假设我尝试使用远程桌面客户端连接到另一个林中的服务器。因此我们知道客户端和服务器之间至少必须允许 TCP 端口 3389。
（以供参考，这个文件基本上是 Active Directory 如何使用 Kerberos 的圣经。在我看来，这是网络上最好的 TechNet 文章之一。这是另一个有关 AD 信任的极其相关的 TechNet 文章，值得您收藏。
在使用 Kerberos 进行身份验证期间，最后一步是客户端将其服务票证和身份验证器直接发送到它试图访问的远程服务。（KRB_AP_REQ，然后从服务器向客户端发送可选的 KRB_AP_REP）。如果由于端口被阻止而无法发生这种情况，则无法进行 Kerberos 身份验证。如果我从我的 DC 收到 TGS 引用，将我定向到您的 DC，并且我无法直接查询您的 DC，那么我就无法使用 Kerberos。
这或许就是您所看到的被丢弃的部分流量。
那么，当 Kerberos 失败时会发生什么？客户端通常会回退到下一个安全提供程序，例如 NTLM。您可以通过同一端口 3389 将受 NTLM 保护的凭据直接传递给服务器。此时，服务器只需验证您的凭据。请参阅我链接的第二篇文章中名为“NTLM 引用处理”的部分。
NTLM 转介处理
如果客户端使用 NTLM 进行身份验证，则初始身份验证请求将直接从客户端发送到目标域中的资源服务器。此服务器创建一个质询，客户端将对此作出响应。然后，服务器将用户的响应发送到其计算机帐户域中的域控制器。此域控制器根据其安全帐户数据库检查用户帐户。如果数据库中不存在该帐户，则域控制器将使用以下逻辑确定是执行传递身份验证、转发请求还是拒绝请求：
当前域是否与用户的域具有直接信任关系？
◦ 如果是，域控制器会将客户端的凭据发送到用户域中的域控制器进行直通身份验证。
◦ 如果没有，请转至下一步。
当前域是否与用户域具有传递信任关系？
◦ 如果是，则将身份验证请求传递到信任路径中的下一个域。此域控制器将重复该过程，根据其自己的安全帐户数据库检查用户的凭据。
◦ 如果不是，则向客户端发送登录被拒绝的消息。
因此，最终，鉴于您向我们提供的有限信息，我相信这就是您在向其他域中的服务进行身份验证时所见证的过程。