ADFS（Active Directory Federation Services）联合身份认证是Windows Server环境下实现跨组织、跨应用单点登录（SSO）的核心组件，但它同时也是攻击者眼中的高价值目标。ADFS一旦被攻破，攻击者可以伪造身份令牌、横向渗透整个域环境，甚至绕过多因素认证。要真正做好ADFS安全，核心思路就是三件事：严格限制令牌签发策略、加固ADFS服务器本身、持续监控异常行为。下面我会从架构层面到具体配置，把ADFS安全的每一个关键点讲透。

一、ADFS联合身份认证的基本工作原理

ADFS本质上是一个基于声明（Claims-Based）的身份联邦服务。用户在本地AD域认证成功后，ADFS会签发一个SAML令牌或JWT令牌，交给外部应用或合作伙伴的服务。整个流程涉及三个角色：身份提供方（IdP，通常就是你的ADFS服务器）、服务提供方（SP，即目标应用）、用户。ADFS作为IdP，负责验证用户身份并签发令牌。令牌一旦签发，SP就信任这个令牌并允许用户访问。问题在于，如果ADFS本身被入侵或者配置不当，攻击者就能伪造任意令牌，等于拿到了通往所有信任应用的万能钥匙。

二、ADFS面临的主要安全威胁

第一类是令牌伪造攻击。攻击者通过获取ADFS的签名证书私钥，或者利用配置漏洞签发高权限令牌。历史上最著名的案例就是利用MS14-068等漏洞伪造Kerberos票据，再通过ADFS签发令牌。第二类是中间人攻击。如果ADFS通信未强制使用TLS 1.2以上协议，攻击者可以截获令牌。第三类是凭据填充和暴力破解。ADFS的Web登录页面如果没有锁定策略，很容易被撞库。第四类是内部威胁。域管理员权限过大，一旦账号被盗用，ADFS配置可以被随意篡改。

三、ADFS服务器本身的加固措施

ADFS服务器不应该同时承担其他角色。最佳实践是部署专用的ADFS服务器，不要在上面安装IIS、SQL Server或其他无关服务。操作系统层面，只开放必要端口：443（HTTPS）、49443（ADFS管理端口，仅限内部访问）。关闭所有不需要的入站规则。定期打补丁，特别是与身份验证相关的安全更新，必须第一时间部署。建议将ADFS服务器放在独立的OU中，应用更严格的组策略。

具体到证书管理，ADFS使用的令牌签名证书和令牌解密证书必须妥善保管。签名证书私钥应存储在硬件安全模块（HSM）中，或者至少使用Windows证书存储中的强保护选项。证书过期前要提前规划轮换，避免因证书过期导致服务中断或被迫使用弱配置临时过渡。可以用以下PowerShell命令检查证书状态：

Get-AdfsCertificate -CertificateType Token-Signing | Select-Object FriendlyName, NotAfter, NotBefore, IsSelfSigned

四、严格配置令牌签发策略

这是ADFS安全最核心的部分。默认配置下，ADFS可能会签发包含过多声明的令牌，甚至允许外部应用请求任意声明。必须通过声明规则（Claim Rules）严格限制每个信赖方信任（Relying Party Trust）能获取哪些声明。原则是最小权限——应用需要什么声明就给什么，绝不多给。

具体操作步骤：打开ADFS管理控制台，进入"信赖方信任"，选择对应的应用，编辑"签发授权规则"。只保留必要的声明，比如用户名、邮箱、组信息。对于敏感应用，还要添加额外的授权规则，比如要求用户必须属于特定安全组才能获取令牌。示例配置如下：

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-xxxx-xxxx-xxxx-512"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role", Value = "SensitiveAppUser");

同时，必须禁用不必要的协议。如果你的应用只需要SAML 2.0，就不要同时启用WS-Federation。在ADFS属性中，明确指定支持的协议类型，关闭WS-Trust等老旧协议，因为这些协议更容易被利用进行令牌请求攻击。

五、强制多因素认证（MFA）和条件访问

ADFS本身支持集成Azure MFA或第三方MFA提供商。在ADFS 2019及更高版本中，可以配置额外的身份验证提供方。对于外部用户访问，必须强制MFA。配置方法是在ADFS中创建身份验证策略，要求所有外部访问触发额外验证。可以通过PowerShell配置：

Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider "AzureMfaAuthentication"

对于内部访问，建议结合设备合规性检查。虽然ADFS本身不具备完整的条件访问能力，但可以通过与Azure AD Conditional Access联动（混合部署场景）来实现基于风险的访问控制。比如检测到异常登录位置、异常设备时，自动要求MFA或拒绝访问。

六、网络层面的安全隔离

ADFS服务器的Web应用代理（WAP）角色应该部署在DMZ区域，与内部ADFS联合服务器之间通过防火墙严格隔离。WAP只负责代理HTTPS请求，不存储任何敏感数据。内部联合服务器不直接暴露在公网，所有外部流量必须经过WAP。WAP与联合服务器之间的通信使用特定端口（默认443），并配置IPsec或TLS双向认证。

DNS配置也很关键。ADFS依赖的federation metadata端点（如/federationmetadata/2007-06/federationmetadata.xml）不应该被外部随意访问，虽然这个端点本身是公开的，但要确保它不会泄露内部网络架构信息。可以通过自定义metadata过滤不必要的信息。

七、日志监控与异常检测

ADFS会生成详细的审计日志，包括登录成功/失败、令牌签发、策略触发等事件。这些日志默认存储在Event Viewer的"Applications and Services Logs > AD FS > Admin"和"Operational"中。必须将这些日志集中收集到SIEM系统中，设置告警规则。

重点监控的异常行为包括：短时间内大量令牌签发请求、来自异常IP的登录尝试、非工作时间的管理员登录、令牌签名证书访问事件、信赖方信任被修改的事件。可以用以下PowerShell查询近期登录失败事件：

Get-WinEvent -LogName "AD FS/Admin" -MaxEvents 100 | Where-Object {$_.Id -eq 364} | Format-List TimeCreated, Message

建议设置自动化告警，当检测到连续5次以上登录失败或单次令牌签发量超过阈值时，立即通知安全团队。同时开启ADFS的登录页面自定义，添加公司安全提示，这本身也是一种社会工程防护。

八、定期安全评估与渗透测试

ADFS配置不是一劳永逸的。每季度至少进行一次配置审计，检查所有信赖方信任的声明规则是否仍然合理、证书是否即将过期、是否有未使用的信赖方信任残留。每年进行一次针对ADFS的专项渗透测试，重点测试令牌伪造、协议降级攻击、证书私钥提取等场景。可以使用开源工具如ADFSpoof进行模拟测试，验证你的防御措施是否有效。

另外，关注微软的安全公告，ADFS相关的漏洞历史上不少，包括但不限于CVE-2021-34473（签名验证绕过）、CVE-2023-36834等。一旦有新漏洞发布，必须在48小时内评估影响并制定修复计划。

九、备份与灾难恢复

ADFS的配置数据存储在Windows Internal Database（WID）或SQL Server中。必须定期备份ADFS配置，包括联合服务器的系统状态和WID数据库。备份频率建议每周一次，保留至少30天。同时保存好令牌签名证书的备份（包含私钥），存放在离线安全介质中。一旦发生安全事件需要重建，有完整备份可以大幅缩短恢复时间。

十、总结与最佳实践清单

ADFS联合身份认证安全不是单一配置能解决的，它需要从架构设计、证书管理、策略配置、网络隔离、监控告警、定期审计多个维度形成纵深防御。核心原则记住三点：最小权限签发令牌、多因素认证覆盖所有入口、持续监控快速响应。把这三点落实到位，ADFS就能在提供便捷联合认证的同时，把安全风险控制在可接受范围内。Windows Server环境下的身份安全，ADFS是关键一环，值得投入足够的资源去维护和加固。