跨域authentication如何在防火墙环境中工作?

这是一个简化,名称已经改变,以保护无辜。

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中的服务器login

dc.corp.lan和dc.saas.lan之间没有防火墙

server.saas.lan位于防火墙区域,存在一组规则,因此可以与dc.saas.lan

我可以用[email protected]到server.saas.lan – 但我不明白它是如何工作的。 如果我看防火墙日志,我会在server.saas.lan和dc.saas.lan之间看到一堆login信息

我也看到server.saas.lan和dc.corp.lan之间的一堆DROPPED喋喋不休。 据推测,这是因为server.saas.lan试图[email protected]但是没有允许这些主机之间通信的防火墙规则。

但是,[email protected]可以成功login到server.saas.lan – 一旦login,我可以“echo%logonserver%”并获得\ dc.corp.lan。

所以….我有点困惑如何帐户实际得到authentication。 在server.saas.lan无法与dc.corp.lan通信之后,dc.saas.lan是否最终会与dc.corp.lan进行通信?

试图找出需要更改/修改/更改的内容。

你确实没有给我们足够的细节来肯定地回答这个问题。 例如,您不会提供任何有关被阻止的stream量的确切性质,stream量是什么样的stream量,森林或外部信任,每个域的成员之间允许哪些端口,您如何尝试连接到服务器,(远程桌面?驱动器映射?)等等

无论如何,我会采取刺的。 假设我正在尝试使用远程桌面客户端连接到其他林中的服务器。 所以我们知道在客户端和服务器之间必须至less允许TCP端口3389。

(作为参考, 本文档基本上是Active Directory如何使用Kerberos的圣经,是networking上最好的TechNet文章之一,恕我直言, 这里是另一个非常相关的TechNet关于AD信任的文章。

在使用Kerberos进行身份validation的过程中,最后一个步骤是客户端将其服务票据和身份validation器直接发送到正在尝试访问的远程服务。 (KRB_AP_REQ,然后从服务器返回到客户端的可选KRB_AP_REP)。 如果由于端口被阻塞而导致无法进行,则Kerberos身份validation不会发生。 如果我从我的DC得到一个TGS引​​用,将我引导到您的DC,并且我无法直接查询您的DC,我不能使用Kerberos。

也许这是你看到的一些stream量被丢弃。

那么,当Kerberos失败时会发生什么? 客户通常会回到下一个安全提供者,例如NTLM。 您可以通过相同的端口3389将NTLM保护的凭据传递给服务器。此时服务器只需validation您的凭据。 请参阅我链接的第二篇文章中名为“NTLM引用处理”的部分。

NTLM推荐处理

如果客户端使用NTLM进行身份validation,则初始身份validation请求会直接从客户端传输到目标域中的资源服务器。 该服务器创build一个客户端响应的挑战。 服务器然后将用户的响应发送到其计算机帐户域中的域控制器。 此域控制器会根据其安全帐户数据库检查用户帐户。 如果帐户不存在于数据库中,则域控制器将使用以下逻辑来确定是执行传递身份validation,转发请求还是拒绝请求:

  • 当前域与用户域有直接的信任关系吗?

    ◦如果是,则域控制器将客户端的凭据发送到用户域中的域控制器以进行传递身份validation。

    ◦如果否,请转至下一步。

  • 目前的域名是否与用户的域名具有可传递的信任关系?

    如果是,请将身份validation请求传递到信任path中的下一个域。 该域控制器通过检查用户的凭据来对其自己的安全帐户数据库重复该过程。

◦如果否,则向客户端发送login拒绝消息。

因此,最终,鉴于您提供给我们的信息有限,那么我认为您在对其他域中的服务进行身份validation时正在见证这一过程。