IIS中Kerberos认证异常：仅使用NTLM而非Kerberos求助

针对你遇到的IIS站点使用NTLM而非Kerberos认证的问题，结合已完成的配置，按以下步骤逐一排查：

1. 补充注册HTTP服务专属SPN #

你当前注册的是HOST/前缀的SPN，虽然HOST是通用服务标识，但IIS的HTTP服务优先匹配HTTP/前缀的SPN，这是Kerberos不生效的常见原因：

• 在VM1（AD服务器）上执行以下命令注册SPN（替换占位符为实际值）：

  setspn -A HTTP/<hostname-of-VM1> DOMAIN\<VM1计算机名>$
  setspn -A HTTP/<FQDN-of-VM1> DOMAIN\<VM1计算机名>$
  

• 执行setspn -L <VM1计算机名>确认输出中存在上述两条HTTP/开头的SPN记录。

2. 验证SPN绑定的账号正确性 #

确认SPN绑定的是VM1的计算机账号（格式为DOMAIN\VM1$，带美元符号表示计算机账号），而非普通域用户账号：

• 执行setspn -L <VM1计算机名>，检查每条SPN对应的账号是否为VM1的计算机账号。若绑定错误，用setspn -D删除错误记录后重新绑定。

3. 配置浏览器本地Intranet区域 #

Windows浏览器仅对本地Intranet区域的站点自动发送Kerberos票据，需确保目标FQDN被加入该区域：

1. 在VM2上打开Internet Explorer（Edge可通过设置同步IE区域配置）
2. 依次进入：Internet选项 → 安全 → 本地Intranet → 站点 → 高级
3. 添加http://<FQDN-of-VM1>到站点列表，点击确定保存。

4. 检查DNS正向/反向解析一致性 #

Kerberos要求目标服务器的正向DNS（A记录）和反向DNS（PTR记录）完全匹配：

• 在VM2上执行nslookup <FQDN-of-VM1>，确认返回的IP是VM1的正确地址
• 执行nslookup <VM1的IP地址>，确认返回的主机名是VM1的FQDN，若反向记录缺失，需在DNS服务器上添加对应PTR记录。

5. 清空现有票据并重新测试 #

在VM2上清空Kerberos缓存后重新请求站点，排除旧票据干扰：

• 执行命令：

  klist purge
  

• 重新访问http://<FQDN-of-VM1>，再执行klist查看是否生成对应服务票据。

6. 检查应用池身份对应的SPN（若使用自定义账号） #

若IIS应用池未使用默认的ApplicationPoolIdentity或Network Service，而是自定义域账号：

• 需为该自定义账号注册HTTP/<hostname>和HTTP/<FQDN>的SPN，而非VM1的计算机账号。

7. 验证Kerberos加密类型兼容性 #

确保VM1和VM2支持相同的Kerberos加密类型：

• 在VM1和VM2上打开本地安全策略 → 本地策略 → 安全选项 → 网络安全: Kerberos客户端支持的加密类型
• 确认双方都启用了相同的加密类型（如AES-256-HMAC-SHA1），避免因加密类型不匹配导致Kerberos协商失败。

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