.NET 6调用WCF服务遇NTLM认证错误，求排查建议

• 切换客户端认证类型为Negotiate
  服务器返回的认证头包含NTLM, Negotiate，说明服务器支持两种协商方式。.NET 6中对NTLM的处理逻辑与.NET Framework 4.x存在差异，将HttpClientCredentialType.Ntlm改为HttpClientCredentialType.Negotiate，让客户端自动与服务器协商合适的认证方案：

  Transport = new HttpTransportSecurity
  {
      ClientCredentialType = HttpClientCredentialType.Negotiate
  }
  

• 显式指定Windows凭据
  .NET 6中可能需要明确传递Windows身份凭据，在创建客户端实例后添加以下代码（根据实际情况选择使用当前用户身份或指定账号）：

  // 使用当前运行用户的身份
  client.ClientCredentials.Windows.ClientCredential = CredentialCache.DefaultNetworkCredentials;
  // 或指定特定账号
  client.ClientCredentials.Windows.ClientCredential = new NetworkCredential("username", "password", "domain");
  

  同时可设置 impersonation 级别：

  client.ClientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
  

• 启用NTLM兼容性开关
  .NET Core及后续版本默认对NTLM有更严格的限制，可通过配置启用NTLM支持：

  • 在代码启动时添加：

    AppContext.SetSwitch("System.ServiceModel.AllowNtlm", true);
    

  • 或在appsettings.json中添加：

    {
      "System.ServiceModel": {
        "AllowNtlm": true
      }
    }
    

• 检查服务器端认证配置
  确认服务器端（如IIS）的Windows身份验证设置：

  • 确保已启用Windows身份验证
  • 检查是否允许NTLM认证（部分环境可能默认仅启用Negotiate）
  • 确认服务器的身份验证策略未拒绝NTLM请求

• 排查Kerberos相关问题
  如果服务器优先使用Negotiate（Kerberos），需检查：

  • 服务的SPN（服务主体名称）是否正确注册
  • 客户端与服务器是否在同一域，或客户端能否获取有效的Kerberos票证
  • 若无需Kerberos，可在服务器端调整身份验证顺序，将NTLM设为优先

• 抓包分析认证交互流程
  用Fiddler或Wireshark抓取HTTP请求包，查看：

  • 客户端发送的Authorization头是否包含正确的NTLM凭证
  • 服务器返回的WWW-Authenticate头具体内容
  • 认证过程中是否存在401响应的细节，定位具体拒绝原因

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