AD FS 实现 SSO 需部署联合服务器、配置信赖方信任与声明规则、启用 Windows 集成身份验证，并可与 Microsoft Entra ID 集成；非开箱即用，须按角色部署、准备证书并细化策略。
在 windows server 中使用 ad fs 实现单点登录（sso），核心是建立信任关系、配置声明规则，并确保客户端与服务端身份验证流程无缝衔接。它不是开箱即用的功能，需要按角色部署、证书准备和策略细化。
部署联合服务器并完成基础配置
AD FS 作为联合身份提供者，需安装在加入域的 Windows Server（2012 R2 及以上）上。推荐使用“联合服务器阵列”拓扑（支持最多 5 台服务器+ WID 数据库），而非单机独立模式（仅限测试）。
- 通过“添加角色和功能向导”安装 Active Directory 联合身份验证服务 角色
- 运行“配置联合身份验证服务”向导：指定 TLS/SSL 证书（必须绑定到公网可解析的 FQDN，如 sts.contoso.com）、联合服务名称（即元数据 URL 基础地址）及显示名称
- 确保 DNS 中已为该 FQDN 创建 A 或 CNAME 记录，且客户端能正常解析
- 安装完成后，访问 https://sts.contoso.com/federationmetadata/2007-06/federationmetadata.xml 验证元数据是否可公开获取、无证书警告
建立信赖方信任并发布应用
目标应用（如 Dynamics 365、自定义 Web 应用、Microsoft Entra ID）需被注册为“信赖方”，AD FS 才能为其签发安全令牌。
- 在 AD FS 管理控制台中，右键“信赖方信任” → “添加信赖方信任”，选择“导入数据源”或“手动输入数据”
- 填写应用标识符（Identifier，通常为应用的回调 URL 或 URI，如 https://app.contoso.com）
- 配置签名证书（若应用要求 SAML 签名验证）、加密证书（若需加密断言）
- 设置声明规则：例如将 AD 用户的 UPN 映射为 Name ID，或从 AD DS 属性（如 department、manager）发出自定义声明供应用做授权判断
启用并优化 Windows 集成身份验证（WIA）体验
真正实现“无感 SSO”的关键，在于让域内用户访问受保护应用时，不弹出登录框——这依赖浏览器与 AD FS 协同完成 Windows 集成身份验证。
- 检查客户端 IE/Edge：启用“启用集成 Windows 身份验证”，并将 AD FS 地址加入“本地 Intranet”区域；Chrome/Firefox 需配置 AuthServerWhitelist 或 AuthNegotiateDelegateWhitelist 策略
- 在 AD FS 服务器上确认策略：PowerShell 运行 Get-ADFSGlobalAuthenticationPolicy | fl WindowsIntegratedFallbackEnabled，值应为 False；再运行 Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents，确保客户端浏览器 UA 字符串在列表中（如缺失，用 Set-ADFSProperties -WIASupportedUserAgents @(...) 补充）
- 避免混合使用相同域名：不要让 AD FS 服务名（如 sts.contoso.com）与后端应用 URL（如 app.contoso.com）共用同一通配符证书或 DNS 解析路径，否则可能触发循环重定向
与 Microsoft Entra ID 集成实现混合云 SSO
若组织已使用 Microsoft Entra ID（原 Azure AD），AD FS 可作为其联合身份提供者，支撑 Office 365、Azure 门户等云服务的本地 AD 登录。
- 通过 Microsoft Entra admin center → “Azure Active Directory” → “Custom domain names” → 选择域名 → “Manage federation”，填入 AD FS 元数据 URL 或手动配置终结点
- 本地需部署 Microsoft Entra Connect，并启用“联合身份验证”模式（非密码哈希同步），同时配置“无缝 SSO”作为备用或增强方案
- 注意微软官方建议：新部署优先选用 Microsoft Entra ID 的原生联合能力，现有 AD FS 系统仍受支持，但不再推荐升级至新版 AD FS
