IIS中启用Kerberos认证的Web应用生成非Kerberos令牌问题解决

核心问题分析 #

从请求头可见，QA服务器的Authorization令牌以TlR开头，这说明Negotiate协商后最终使用了NTLM而非Kerberos，而开发服务器正常启用Kerberos（令牌以oXcw开头）。

排查与修复步骤 #

• 检查SPN注册情况
  确保QA服务器的IIS应用池账户已正确注册SPN（服务主体名称）。以域管理员身份打开命令提示符，执行：

  setspn -L <应用池账户名>
  

  需确认存在HTTP/<服务器FQDN>和HTTP/<服务器NetBIOS名>格式的SPN。若缺失，执行：

  setspn -S HTTP/<服务器FQDN> <应用池账户名>
  setspn -S HTTP/<服务器NetBIOS名> <应用池账户名>
  

• 调整Windows认证提供程序顺序
  在IIS管理器中进入站点的Windows认证设置，确保Negotiate排在NTLM之前。顺序颠倒会导致客户端优先尝试NTLM，触发协商降级。

• 验证客户端访问方式
  确保客户端机器已加入域，且访问站点时使用服务器FQDN而非IP或NetBIOS名——Kerberos依赖FQDN匹配SPN，非FQDN访问会强制切换到NTLM。

• 检查应用池身份配置
  确认QA服务器的应用池使用域账户而非本地系统账户。本地系统账户无法注册跨域SPN，会直接强制使用NTLM认证。

• 清除Kerberos缓存
  在QA服务器和客户端分别执行klist purge命令清除Kerberos缓存，之后重新发起请求测试。

• 检查组策略限制
  打开组策略编辑器，定位到计算机配置>Windows设置>安全设置>本地策略>安全选项，确保网络安全: LAN管理器身份验证级别设置为兼容Kerberos的级别（如发送NTLMv2响应\拒绝LM和NTLM），避免强制使用NTLM。

额外验证方式 #

可使用Fiddler抓包查看协商流程：Kerberos会经历AS-REQ、AS-REP、TGS-REQ、TGS-REP四个步骤，而NTLM仅包含三个握手阶段。

内容的提问来源于stack exchange，提问作者RGS