ADFS 2.0 代理服务器与向公众开放 ADFS 服务器

ADFS 2.0 代理服务器与向公众开放 ADFS 服务器

我们正在致力于使用 o365 部署 ADFS 以实现 SSO。

我们有一家咨询公司负责我们的防火墙配置。

今天,当我试图让他们为我设置 DMZ 以安装 ADFS 代理服务器时,顾问试图说服我让他们直接向 ADFS 服务器开放端口 443,而根本不使用代理。他告诉我,这种配置现在是标准做法。

由于我们业务的性质,我们对安全有非常严格的要求,包括不得将内部服务器向外部开放。

我的问题是,他是不是因为懒惰而不想配置 DMZ,只是在吹牛,还是他有合理的观点?

答案1

哦,该死的!

请勿将主要 ADFS 服务器放在互联网上!

代理角色的发明是有特定原因的,将主 ADFS 框放在互联网上并不是一个明智的想法。主要是因为主服务器默认配置为仅允许基于 Windows 的身份验证,这意味着任何人都可以提交请求并尝试强行进入。更糟糕的是,如果他们获得了密码,他们现在就拥有了您域上的有效用户名和密码,这是最痛苦的。

但是,代理使用基于 Web 表单的方法来减少威胁,方法是强制公司防火墙之外的用户通过 Web 表单登录。如果他们通过,它将返回受信任服务(参见 O365)使用的 Cookie 或重定向令牌。

无论如何,这直接违反了 Microsoft 推荐的设置,并且肯定不会通过安全审计验证。此外,由于您只向代理公开端口 80 和 443 流量,因此只需通过特定 IP 将这两个端口转发到您的代理(或负载平衡代理)并不难。无论如何,DMZ 是明智之举,特别是如果您有其他面向公众的服务。

答案2

不过,这取决于这位顾问在做什么。如果他们使用 TMG 之类的东西来处理 ADFS 服务器前面的防火墙,那么它就可以充当代理的角色,并向外部客户端提供 Web 表单身份验证,而不是直接在内部 ADFS 2.0 服务器上打开一个到 443 的漏洞。

我和你一样,绝对不将内部 ADFS 服务器直接暴露在互联网上。无论有人试图告诉我这有多安全,你仍然在谈论将加入域的服务器直接暴露在公共互联网上。

代理服务器不需要加入域。使用它们的另一个优点。

-E

相关内容