使用 NGINX Plus 实现 Microsoft Active Directory 联合身份验证服务的高可用性

通过 Microsoft Active Directory 联合身份验证服务(AD FS)，在 Windows Server 上托管应用的组织可以将单点登录 (SSO) 访问权限扩展到外部网络上受信任的业务合作伙伴的员工。 商业伙伴之间共享身份信息称为“联盟” 。

实际上，使用 AD FS 意味着联合体中的公司员工只需登录到他们的本地环境。 当他们访问属于受信任业务合作伙伴的 Web应用时，本地 AD FS 服务器会以安全令牌的形式将其身份信息传递给合作伙伴的 AD FS 服务器。 令牌由多个声明组成，这些声明是存储在本地 Active Directory 中的员工的单独属性（用户名、业务角色、员工 ID 等）。 合作伙伴的 AD FS 服务器将令牌中的声明映射到合作伙伴应用可以理解的声明，然后确定员工是否有权进行所请求的访问类型。

对于AD FS 2.0及更高版本，您可以启用高可用性(HA)，为应用的身份验证服务增加弹性和规模。 在 AD FS HA 群集（也称为 AD FS场）中，多个 AD FS 服务器部署在单个数据中心内或分布在多个数据中心。 为全活动 HA 配置的集群需要负载均衡器在 AD FS 服务器之间均匀分配流量。 在主动-被动 HA 部署中，当主服务器发生故障时，负载均衡器可以提供到备份 AD FS 服务器的故障转移。

这篇文章解释了如何配置 NGINX Plus 以在分别运行AD FS 3.0和AD FS 4.0 Server 2012 R2 和 Windows Server 2016 的环境中提供 HA。

AD FS 的标准 HA 拓扑

为了便于说明，本文使用标准 AD FS 场拓扑。 它并非旨在作为建议或涵盖所有可能的部署场景。 对于本地部署，标准场由企业内联网上的一个或多个 AD FS 服务器以及 DMZ 网络上的一个或多个Web应用代理(WAP) 服务器组成。 WAP 服务器充当反向代理，允许外部用户访问企业内部网中托管的 Web应用。

然而，WAP 没有内置方法来配置服务器集群或支持 HA，因此必须在 WAP 服务器前面部署负载平衡器。 负载均衡器也放置在 DMZ 和内联网之间的边界，以启用 AD FS 的 HA。 在标准 AD FS 场中，Windows Server 2012 和 2016 的网络负载平衡(NLB) 功能充当负载平衡器。 最后，防火墙通常在负载均衡器的外部 IP 地址前面和网络区域之间实现。

在标准 HA 拓扑中使用 NGINX Plus

如上所述，NLB 可以为 AD FS 场执行负载均衡。 但是，它的功能集非常基础（仅仅是基本的健康检查和有限的监控功能）。 NGINX Plus 具有许多对于生产 AD FS 环境中的 HA 至关重要的功能，而且重量轻。

在这里描述的标准拓扑部署中，NGINX Plus 取代 NLB 来平衡所有 WAP 和 AD FS 场的流量负载。 但请注意，我们没有让 NGINX Plus 终止 AD FS 服务器的 SSL 连接，因为正确的 AD FS 操作需要它查看来自 WAP 服务器的实际 SSL 证书（有关详细信息，请参阅此Microsoft TechNet 文章）。

我们建议您在生产环境中也为 NGINX Plus 本身实现 HA，但这里不展示；有关说明，请参阅 NGINX Plus 管理指南中的本地部署中对 NGINX Plus 的高可用性支持。

配置 NGINX Plus 以平衡 AD FS 服务器的负载

用于平衡 AD FS 服务器负载的 NGINX Plus 配置非常简单。 如上所述，AD FS 服务器必须看到来自 WAP 服务器的实际 SSL 证书，因此我们在 DMZ 内联网边界上配置 NGINX Plus 实例，以将 SSL 加密流量传递到 AD FS 服务器，而无需终止或以其他方式处理它。

除了强制指令之外，我们还在配置中包含这些指令：

• zone在共享内存中分配一个区域，所有 NGINX Plus 工作进程都可以访问上游组中服务器的配置和运行时状态信息。
• hash根据源 IP 地址（客户端的）在客户端和 AD FS 服务器之间建立会话持久性。 即使客户端与 AD FS 服务器建立单个 TCP 连接，这也是必要的，因为在某些情况下，如果未启用会话持久性，某些应用可能会遭受多次登录重定向。
• status_zone表示 NGINX Plus API 收集此服务器的指标，这些指标可显示在内置的实时活动监控仪表板上（ API 和仪表板是单独配置的）。

流 { 上游 adfs_ssl {区域 adfs_ssl 64k ; 服务器 10.11.0.5:443; # AD FS 服务器 1 服务器 10.11.0.6:443; # AD FS 服务器 2哈希 $remote_addr ; } 服务器 { status_zone adfs_ssl ; 监听 10.0.5.15:443; proxy_pass adfs_ssl; } }

　
为了使来自 WAP 服务器的流量通过 NGINX Plus 流到 AD FS 服务器，我们还需要将联合服务名称（在我们的示例中为fs.example.com ）映射到 NGINX Plus 正在监听的 IP 地址。 对于生产部署，在 DMZ 中添加 DNS 主机A记录。 对于测试部署，在每个 WAP 服务器上的hosts文件中创建一个条目就足够了；这就是我们在这里所做的，在hosts文件中将fs.example.com绑定到 10.0.5.15：

为了测试来自 WAP 服务器的流量是否到达 AD FS 服务器，我们运行ipconfig /flushdns命令来刷新 DNS，然后在浏览器中登录到 AD FS 的 SSO 页面https://fs.example.com/adfs/ls/idpinitiatedsignon.htm ：

配置 NGINX Plus 以平衡 WAP 服务器负载

我们现在配置 NGINX Plus 来平衡从外部客户端到 WAP 服务器的 HTTPS 连接的负载。 最佳实践规定，流量到达 AD FS 服务器时仍是 SSL 加密的，因此我们使用以下两种方法之一来配置 NGINX Plus 以将 HTTPS 流量传递到 WAP 服务器： SSL 直通或 SSL 重新加密。

配置 SSL 直通

更简单的配置是让 NGINX Plus 不加改变地将 SSL 加密的 TCP 流量转发到 WAP 服务器。 为此，我们在流上下文中配置一个与前一个类似的虚拟服务器，用于对 AD FS 服务器进行负载均衡。

这里 NGINX Plus 在另一个唯一 IP 地址 10.0.5.100 上监听外部流量。 对于生产环境，已发布的应用的外部 FQDN 必须以公共区域中的 DNS 主机A记录的形式指向该地址。 为了进行测试，客户端机器的hosts文件中的条目就足够了。

笔记： 如果您要在流上下文中配置其他 HTTPS 服务以监听与此服务器相同的 IP 地址，则必须使用ssl_preread指令和映射启用服务器名称指示 (SNI)，以将流量正确地路由到不同的上游。 这超出了本博客的范围，但 NGINX 参考文档中包含示例。

流 { 上游 wap {
区域 wap 64k;
服务器 10.11.0.5:443; #WAP 服务器 1
服务器 10.11.0.6:443; #WAP 服务器 2
最少时间连接;
}

服务器 {
状态区域 wap_adfs;
监听 10.0.5.100:443;
代理密码 wap;
}
}

配置 HTTPS 重新加密

作为 SSL 直通的替代方案，我们可以通过在http上下文中配置虚拟服务器来接受 HTTPS 流量，从而利用 NGINX Plus 的完整第 7 层功能。 NGINX Plus 终止来自客户端的 HTTPS 连接并创建到 WAP 服务器的新 HTTPS 连接。

证书和密钥文件example.com.crt和example.com.key在通用名称 ( CN ) 或主题备用名称 ( SAN ) 属性中包含已发布应用的外部 FQDN；在此示例中，FQDN 为fs.example.com 。

proxy_ssl_server_name和proxy_ssl_name指令启用所需的服务器名称指示 (SNI) 标头，指定要在 SSL 客户端 Hello 中发送的远程主机名。 标头必须与已发布应用的外部 FQDN 匹配，此示例中为fs.example.com 。

我们使用proxy_set_header指令将相关信息传递给 WAP 服务器，并且也可以将其捕获到日志中：

• X-Real-IP标头包含$remote_addr变量中捕获的源（客户端）IP 地址。
• X-Forwarded-For传达来自客户端请求的标头，并将客户端的 IP 地址附加到该标头（如果客户端请求没有标头，则只附加该地址）。
• x-ms-proxy标头指示用户通过代理服务器路由，并将 NGINX Plus 实例标识为该服务器。

除了这里显示的指令之外，NGINX 和 NGINX Plus 还提供了许多可以提高 SSL/TLS 性能和安全性的功能。 欲了解更多信息，请参阅我们的博客。

http { 上游 wap { 区域 wap 64k; 服务器 10.0.5.11:443; 服务器 10.0.5.10:443; least_time 标头; } 服务器 { 监听 10.0.5.100:443 ssl; status_zone fs.example.com; 服务器名称 fs.example.com; ssl_certificate /etc/ssl/example.com/example.com.crt; ssl_certificate_key /etc/ssl/example.com/example.com.key; 位置 / { proxy_pass https://wap; # 'https' 启用重新加密proxy_ssl_server_name ; proxy_ssl_name $host ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header x-ms-proxy $server_name; } } }

在没有 WAP 服务器的拓扑中配置 NGINX Plus

当允许外部客户端访问您的 AD FS 服务器时，最佳做法是在 DMZ 和公司内联网之间的边界终止外部流量，并通过插入x-ms-proxy标头来识别外部身份验证尝试。 WAP 服务器执行这两种功能，但如上一节中配置的那样，NGINX Plus 也执行这两种功能。

某些用例不需要 WAP 服务器 - 例如，当您不使用 IP 网络和信任级别等高级声明规则时。 在这种情况下，您可以消除 WAP 服务器并将 NGINX Plus 放置在 DMZ 和内联网之间的边界，以对内部 AD FS 服务器的请求进行身份验证。 这降低了您的硬件、软件和运营成本。

此配置取代了标准 HA 拓扑的配置。 它几乎与用于负载均衡 WAP 服务器的HTTPS 重新加密配置相同，但这里 NGINX Plus 将外部请求直接负载均衡到内部网络中的 AD FS 服务器。

上游 adfs { 区域 adfs 64k;
服务器 192.168.5.5:443; # AD FS 服务器 1
服务器 192.168.5.6:443; # AD FS 服务器 2
least_time 标头;
}

服务器 {
监听 10.0.5.110:443 ssl;
status_zone adfs_proxy;
服务器名称 fs.example.com;
ssl_certificate /etc/ssl/example.com/example.com.crt;
ssl_certificate_key /etc/ssl/example.com/example.com.key;

位置 / {
proxy_pass https://adfs;
proxy_ssl_server_name on;
proxy_ssl_name $host;
proxy_set_header 主机 $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header x-ms-proxy $server_name;
}
}

在您的 AD FS 部署中试用 NGINX Plus – 立即开始30 天免费试用或联系我们讨论您的用例。