启用Windows Authentication的ASP.NET Web Form页面每次访问均弹出密码框

IIS相关设置 #

• 禁用匿名身份验证：确认站点的匿名身份验证已完全禁用。如果同时开启匿名和Windows验证，IIS会先尝试匿名访问，失败后才触发Windows验证，直接导致弹窗。
• Windows验证提供程序顺序：检查站点的Windows验证提供程序，确保Negotiate排在NTLM前面（优先使用Kerberos）。如果Kerberos配置异常，会回落到NTLM但触发弹窗。
• 应用程序池身份权限：确认应用池的运行身份有访问站点文件系统的权限，且能向域控制器验证身份。池身份权限不足会导致验证流程异常。
• 站点主机名与SPN配置：如果使用自定义主机名，需给应用池身份注册正确的服务主体名称（SPN）。Kerberos依赖SPN匹配，缺失或错误会导致无法自动协商身份，触发NTLM弹窗。
• 内核模式验证开关：在Windows验证的高级设置里，确认勾选了"启用内核模式验证"。内核模式能让IIS在用户进程外处理验证，避免权限问题导致的弹窗。

Windows系统相关设置 #

• 本地Intranet区域站点映射：就算开启了自动登录，若访问的域名未被识别为本地Intranet区域，浏览器仍会要求输入凭据。前往Internet选项→安全→本地Intranet→站点→高级，把站点域名添加到区域列表中。
• Kerberos约束委派配置：如果应用需要访问后端资源（比如数据库），需确认服务器和应用池身份的Kerberos约束委派配置正确。委派配置错误会打断验证链，触发弹窗。
• 客户端Kerberos票据清理：客户端用户的Kerberos票据可能过期或损坏，在客户端执行klist purge清空票据后再尝试访问。
• NTLMv2强制设置：检查组策略计算机配置→Windows设置→安全设置→本地策略→安全选项中的"网络安全: LAN管理器身份验证级别"，若设置为"仅发送NTLMv2响应\拒绝LM和NTLM"，而客户端不支持NTLMv2，会导致验证失败弹窗。
• 防火墙/代理拦截：服务器或客户端的防火墙、代理可能拦截了Kerberos协商的数据包（如UDP 88端口），导致无法自动完成验证，回落到手动输入凭据的NTLM模式。

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