.NET 4.5.2站点单客户端访问Windows认证XML文件报401错误排查

可能的原因 #

• 浏览器自动凭据传递配置异常：该客户端的浏览器未配置为向当前站点自动发送Windows凭据。例如IE/Edge中，站点未加入「本地Intranet」区域，或「本地Intranet」区域的「自动登录」选项未勾选，导致浏览器不会主动传递当前登录用户的凭据，直接返回401（若禁用登录弹窗）。
• Kerberos/NTLM认证流程失败：
  • 若服务器支持Negotiate（Kerberos），但客户端无法获取有效Kerberos票据（比如客户端不在域内、域信任异常、服务器SPN配置错误），降级到NTLM后仍失败；
  • 客户端使用本地账户而非域账户，而服务器仅允许域用户访问该XML文件。
• IIS与文件权限配置问题：
  • 虽已启用Windows认证，但connectivity_check.xml的NTFS权限未授予该客户端用户读取权限；
  • IIS中Windows认证的提供程序顺序异常（比如Negotiate优先但无法正常工作，NTLM也未正确处理）。
• JavaScript请求的凭据传递缺失：
  • 若存在跨域场景（含同域名不同端口），XMLHttpRequest未设置withCredentials = true，导致凭据未发送；
  • ActiveXObject的XMLHTTP对象未正确配置凭据传递属性，或IE的「增强保护模式」阻止了凭据传递。
• 客户端凭据缓存错误：客户端系统缓存了之前输入的无效凭据，后续请求持续使用该错误凭据导致认证失败。
• 网络层干扰：客户端防火墙或代理服务器篡改了认证请求头部，导致凭据丢失或被修改；代理自身的认证流程干扰了原站点的Windows认证。

查看无效凭据的方法 #

• Fiddler追踪认证报文：开启Fiddler的「Decode」选项，查看请求的Authorization头。NTLM的Base64编码报文可通过解码工具解析出尝试传递的用户名；Kerberos的Negotiate票据也可通过Kerberos工具集解码查看用户主体信息。
• 分析IIS站点日志：IIS日志中401错误对应的记录包含cs-username字段，会显示客户端尝试使用的用户名（匿名为空，认证失败则显示具体账户），可确认是否为预期用户。
• 服务器安全事件日志：在服务器上启用「登录事件」审核，认证失败时事件查看器的「安全」日志会生成事件ID 4625的记录，其中包含详细的用户名、失败原因（如凭据无效、账户锁定等）。

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