部署于IIS的.NET应用：远程用户Windows身份验证弹窗无限循环求助

1. 重点排查Kerberos认证配置 #

远程访问时Windows身份验证优先使用Kerberos，若协商失败才会 fallback到NTLM，反复弹窗大概率是Kerberos无法正常工作：

• 确认服务主体名称（SPN）已正确注册：
  以管理员身份打开命令提示符，执行：

  setspn -L 应用池标识账号（例：DOMAIN\AppPoolUser）
  

  检查是否存在HTTP/myapp.eti.domain.net和HTTP/服务器主机名两条SPN记录。若缺失，执行以下命令注册：

  setspn -A HTTP/myapp.eti.domain.net DOMAIN\AppPoolUser
  setspn -A HTTP/服务器主机名 DOMAIN\AppPoolUser
  

• 验证客户端SPN解析：
  客户端执行nslookup myapp.eti.domain.net确认服务器IP解析正确；再执行setspn -Q HTTP/myapp.eti.domain.net，确保能查到对应SPN记录。

2. 核对IIS身份验证细节设置 #

• 打开IIS管理器，进入站点身份验证功能，确保仅启用Windows身份验证，其余验证方式（匿名、表单等）全部禁用。
• 双击Windows身份验证，点击提供程序，确认NTLM排序在Negotiate之前（避免Kerberos协商失败后无法快速 fallback）。
• 检查站点高级设置，确认启用内核模式身份验证处于勾选状态（Windows身份验证依赖该选项处理协商流程）。

3. 检查域策略与客户端配置 #

• 排查域组策略限制：
  查看计算机配置 > 管理模板 > 系统 > 身份验证下的策略，比如“限制NTLM: 传入NTLM流量”是否设为拒绝，若有需调整为允许或添加站点例外。
• 完善客户端Intranet区域设置：
  除添加目标URL外，进入Intranet区域的自定义级别，将“用户身份验证 > 登录”选项设置为“自动使用当前用户名和密码登录”（默认的“提示输入”会导致反复弹窗）。

4. 验证应用池与文件权限 #

• 确认应用池标识账号对网站根目录及子目录拥有读取和执行权限，对web.config拥有读取权限。
• 若应用池使用内置账号（如ApplicationPoolIdentity），需给IIS AppPool\应用池名称账号分配对应权限，而非IUSR或其他通用账号。

5. 排查网络与中间设备因素 #

• 确认服务器防火墙允许80/443端口的入站流量；若使用HTTPS，检查SSL证书是否在客户端机器上被信任（证书不合法会中断身份验证流程）。
• 若存在代理或负载均衡设备，确保其完整传递Kerberos/NTLM协商的HTTP头，未对身份验证字段做拦截或修改。

6. 通过IIS日志定位具体错误 #

打开站点日志记录，设置日志格式为W3C，确保记录sc-substatus字段。访问失败后查看日志，401子状态码可精准定位问题：

• 401.1：登录失败（Kerberos票据无效或域信任问题）
• 401.2：身份验证方案配置错误
• 401.3：资源权限不足
• 401.4：筛选器拦截访问
• 401.5：ISAPI/CGI程序阻止访问

根据子状态码针对性排查效率更高。

内容的提问来源于stack exchange，提问作者Zine eddine Bahloul