AD FS 故障排除 - 集成的 Windows 身份验证
集成的 Windows 身份验证允许用户使用其 Windows 凭据登录，并使用 Kerberos 或 NTLM 体验单一登录 (SSO)。
集成的 Windows 身份验证失败的原因
集成的 Windows 身份验证失败有三个主要原因。 它们是：- 服务主体名称 (SPN) 错误配置 - 通道绑定令牌 - Internet Explorer 配置
SPN 错误配置
服务主体名称 (SPN) 是服务实例的唯一标识符。 Kerberos 身份验证使用 SPN 将服务实例与服务登录帐户相关联。 这允许客户端应用程序请求服务对帐户进行身份验证，即使客户端没有帐户名称，也是如此。
下面是将 SPN 与 AD FS 配合使用的示例：
- Web 浏览器查询 Active Directory 来确定哪个服务帐户正在运行 sts.contoso.com
- Active Directory 告知浏览器它是 AD FS 服务帐户。
- 浏览器将获取 AD FS 服务帐户的 Kerberos 票证。
如果 AD FS 服务帐户具有错误配置的或错误的 SPN，则可能会导致问题。 查看网络跟踪时，可能会看到诸如 KRB 错误：KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN 之类的错误。
使用网络跟踪（例如 Wireshark）时，你可以确定浏览器正在尝试解析的 SPN，然后你可以使用命令行工具 setspn - Q <spn> 来查询该 SPN。 它可能找不到，也可能被分配给了 AD FS 服务帐户以外的其他帐户。
你可以通过查看 AD FS 服务帐户的属性来验证 SPN。
通道绑定令牌
目前，当客户端应用程序通过 HTTPS 使用 Kerberos、Digest 或 NTLM 向服务器验证自身的身份时，首先会建立一个传输层安全 (TLS) 通道，然后使用此通道进行身份验证。
通道绑定令牌是受 TLS 保护的外部通道的属性，并且用于通过对客户端进行身份验证的内部通道将外部通道绑定到对话。
如果发生“中间人”攻击，并且它们正在解密和重新加密 SSL 流量，则密钥将不匹配。 AD FS 将确定 Web 浏览器与其自身之间存在一些障碍。 这将导致 Kerberos 身份验证失败，并且系统将使用 401 对话框而非 SSO 体验来提示用户。
这可能是由于：
- 浏览器与 AD FS 之间存在的任何障碍
- Fiddler
- 执行 SSL 桥接的反向代理
默认情况下，AD FS 将此项设置为“允许”。 可以使用 PowerShell cmdlet Set-ADFSProperties -ExtendedProtectionTokenCheck None 更改此设置
有关此内容的详细信息，请参阅 AD FS 的安全规划和部署最佳做法。
Internet Explorer 配置
注意
如果使用的是 Chrome，请将其添加到 WIA 支持的用户代理列表中。
默认情况下，Internet Explorer 将按以下方式运行：
- Internet Explorer 将收到来自 AD FS 的 401 响应，其中标头中包含 NEGOTIATE 一词。
- 这会告知 Web 浏览器获取 Kerberos 或 NTLM 票证以发送回 AD FS。
- 默认情况下，如果 NEGOTIATE 一词位于标头中，则 IE 将尝试执行此操作 (SPNEGO)，而无需用户交互。 它仅适用于 Intranet 站点。
有两件主要的事情可以防止这种情况发生。
在 IE 的属性中未选中“启用集成 Windows 身份验证”。 这位于“Internet 选项”->“高级”->“安全性”下。
未正确配置安全区域
FQDN 不在 Intranet 区域中
AD FS URL 不在 Intranet 区域中。
