我之前也踩过这个一模一样的坑！咱们来拆解问题，一步步搞定：

核心冲突点：HttpSys自托管配置与IIS的矛盾 #

你代码里的UseHttpSys是给自托管场景用的——自托管时需要直接绑定Http.sys驱动来处理请求。但部署到IIS时，IIS本身就是基于Http.sys运行的，这时候你再在代码里强行配置Http.sys的身份验证规则，就会导致重复绑定冲突，直接引发崩溃。所以第一步必须：

• 部署到IIS时，完全移除代码中的.UseHttpSys(...)配置块，让IIS接管Http.sys的所有设置。

IIS侧的正确配置步骤 #

接下来把IIS的设置拉满，确保NTLM身份验证正常工作：

1. 站点身份验证设置

   • 打开站点的“身份验证”面板，禁用“匿名身份验证”
   • 启用“Windows身份验证”（NTLM是Windows身份验证的默认Scheme之一，会自动包含在内）

2. 应用程序池配置

   • 确保应用池的托管管道模式为“集成”
   • .NET CLR版本选择“无托管代码”（因为这是.NET Core应用，不需要传统的.NET Framework CLR环境）

3. 服务器角色功能检查

   • 打开服务器管理器，确认已经安装了“Web服务器（IIS）->安全性->Windows身份验证”功能，如果没装就赶紧补上

代码侧的必要配置（不能少！） #

光靠IIS设置还不够，.NET Core应用本身需要启用身份验证中间件：

1. 首先确保项目引用了Microsoft.AspNetCore.Authentication.Negotiate NuGet包（.NET Core 3.1及以上版本需要这个包来支持Windows身份验证）

2. 在Startup.cs（或者.NET 6+的Program.cs）里配置身份验证：

   // ConfigureServices 方法中
   services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
           .AddNegotiate();
   
   // Configure 方法中（.NET 6+则在builder.Build()之前）
   app.UseAuthentication(); // 要放在UseRouting之后，UseEndpoints之前
   app.UseAuthorization();
   

常见坑排查 #

如果还是有问题，检查这几点：

• 如果你在域环境中，确保目标服务器的SPN（服务主体名称）配置正确——Kerberos认证失败会 fallback到NTLM，但SPN配置错误可能导致整个身份验证流程卡死
• 检查站点的高级设置，确认“启用Windows身份验证扩展”选项是勾选状态
• 确保客户端和服务器在同一个域，或者是可信的工作组环境，否则NTLM身份验证会被拒绝

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