如何在防火墙环境中进行跨域身份验证？
这是一种简单化的做法，为了保护无辜者而改变了名称。
The assets:
Active Directory Domains
corp.lan
saas.lan
User accounts
user01@corp.lan
user02@corp.lan
Servers
dc.corp.lan (domain controller)
dc.saas.lan (domain controller)
server.saas.lancorp.lan中的用户帐户和saas.lan中的服务器之间存在单向信任。
dc.corp.lan和dc.saas.lan之间没有防火墙
server.saas.lan位于防火墙区域，并且存在一组规则，因此它可以与dc.saas.lan对话。
我可以用server.saas.lan登录user01@corp.lan，但我不明白它是如何工作的。如果我查看防火墙日志，就会看到server.saas.lan和dc.saas.lan之间的大量登录聊天。
我还看到了server.saas.lan和dc.corp.lan之间的一些空话。这大概是因为server.saas.lan试图对user01@corp.lan进行身份验证，但不存在允许这些主机之间通信的防火墙规则。
但是，user01@corp.lan可以成功地登录到server.saas.lan --一旦登录，我就可以"echo %logonserver%“并获得\dc.corp.lan。
所以..。我有点搞不懂这个帐户是如何被认证的。在dc.saas.lan不能和dc.corp.lan交谈之后，server.saas.lan最终会和dc.corp.lan通话吗？
只是想弄清楚什么是需要改变/修正/改变的。
回答 1
Server Fault用户
发布于 2013-12-12 16:28:06
你没有给我们足够的细节来肯定地回答这个问题。例如，您没有向我们提供任何信息，说明被阻塞的流量的确切性质、它是什么样的流量、森林或外部信任、每个域的成员之间允许哪些端口、您如何试图连接到服务器(远程桌面)？(驱动映射？)等等。
反正我也要试试。让我们假设我试图使用远程桌面客户端连接到另一个林中的服务器。因此，我们知道至少必须允许在客户端和服务器之间使用TCP端口3389。
(作为参考，本文件基本上是Active Directory如何使用Kerberos的圣经。网络上最好的TechNet文章之一，IMHO。( 这是另一个与AD有关的TechNet文章非常相关，供您使用书签。)
在使用Kerberos进行身份验证期间，最后一个步骤是客户端将其服务票证和身份验证器直接发送到它试图访问的远程服务。(KRB_AP_REQ，然后从服务器返回到客户机的可选KRB_AP_REP )。如果由于端口被阻塞而不能这样做，那么Kerberos身份验证就不会发生。如果我从我的DC得到一个TGS推荐，它将我指向你的DC，而我不能直接查询你的DC，我就不能使用Kerberos。
也许这就是你看到的交通被掉落的一部分。
那么，当Kerberos失败时会发生什么呢？客户端通常返回到下一个安全提供程序，例如NTLM。您可以通过同一个端口3389将NTLM保护的凭据传递给服务器。此时，服务器只需验证凭据即可。请参阅我链接的第二篇文章中名为"NTLM参考处理“的部分。
如果客户端使用NTLM进行身份验证，则初始身份验证请求将直接从客户端传递到目标域中的资源服务器。此服务器创建客户端响应的挑战。然后，服务器将用户的响应发送到其计算机帐户域中的域控制器。此域控制器根据其安全帐户数据库检查用户帐户。如果数据库中不存在帐户，域控制器将使用以下逻辑确定是否执行传递身份验证、转发请求或拒绝请求：
- 当前域是否与用户的域有直接信任关系?如果是，则域控制器将客户端的凭据发送到用户域中的域控制器以进行传递身份验证。如果不是◦，请转到下一步。
- 当前域是否与用户的域具有传递信任关系?如果是，请将身份验证请求传递到信任路径中的下一个域。此域控制器通过根据自己的安全帐户数据库检查用户凭据来重复此过程。
如果◦为否，则向客户端发送一条拒绝登录的消息.
因此，最终，考虑到您向我们提供的有限信息，我相信您在对另一个域中的服务进行身份验证时所见证的过程。
https://serverfault.com/questions/476491
复制相似问题
腾讯云开发者
