Windows Authentication仅在PowerShell可用，curl调用报401未授权的原因

核心原因分析 #

• Kerberos环境配置缺失
  curl的--negotiate参数依赖完整的Kerberos认证环境，而Windows原生工具（PowerShell的Invoke-WebRequest、C# HttpClient）会直接调用系统凭证管理器和Kerberos服务，自动处理票据获取与SPN校验。如果是在非Windows bash环境（如Linux/macOS），默认没有配置Kerberos的krb5.conf文件，也未通过kinit获取域用户的Kerberos票据，自然无法完成认证。即使是Windows下的WSL bash，也不会自动加载当前Windows登录用户的Kerberos凭证。

• SPN配置错误
  IIS的Windows Authentication依赖Kerberos时，必须为Web服务器的运行账号注册正确的服务主体名称（SPN），格式为HTTP/<服务器FQDN>和HTTP/<服务器NetBIOS名>。如果SPN未注册或注册错误，curl的Kerberos认证会直接失败，而Windows原生工具可能会自动 fallback到NTLM完成认证，所以能正常访问。

• curl的Negotiate协议行为差异
  Windows原生工具在Kerberos认证失败时，会自动切换到NTLM协议重试，但curl的--negotiate参数仅优先处理Kerberos，部分版本不会自动 fallback到NTLM。如果你的IIS服务器被配置为仅允许Kerberos（而非默认的Kerberos+NTLM），curl就会因无法使用NTLM而返回401。

排查与解决方向 #

• 检查IIS服务器的SPN：执行setspn -L <服务器运行账号>，确认存在HTTP/<服务器完整域名>和HTTP/<服务器短名>的SPN记录，缺失则用setspn -A命令补充。
• 配置客户端Kerberos环境：非Windows bash环境下，修改krb5.conf指向域控制器，执行kinit <域用户名>获取Kerberos票据后再重试curl命令。
• 尝试NTLM认证：如果IIS允许NTLM，改用命令curl --ntlm -u <域\用户名>:<密码> {url}；Windows WSL环境下，可尝试传递Windows凭证（部分版本需额外配置）。
• 检查IIS认证设置：确认Windows Authentication的提供商中同时启用了Negotiate和NTLM（默认配置），避免仅开启Kerberos限制。

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