新建.NET Core项目启用Windows认证出现HTTP 400错误的解决技巧

Hey there, let's troubleshoot that HTTP 400 error you're seeing after setting up Windows Authentication in your .NET Core 2.1 Web API. This issue typically stems from misconfigured auth settings or hosting setup—here's how to get your app running smoothly:

1. Verify Launch & Project Configurations #

First, double-check your launchSettings.json to ensure Windows Auth is enabled for IIS Express (if that's how you're testing):

"iisSettings": {
  "windowsAuthentication": true,
  "anonymousAuthentication": false,
  "iisExpress": {
    "applicationUrl": "http://localhost:5000",
    "sslPort": 0
  }
}

Make sure anonymousAuthentication is set to false—leaving it enabled can cause conflicts with Windows Auth.

For the core auth setup in Startup.cs:

• In ConfigureServices, add the Windows Authentication scheme:

  services.AddAuthentication(IISDefaults.AuthenticationScheme);
  

• In Configure, place UseAuthentication() before UseMvc() to ensure auth runs before routing:

  public void Configure(IApplicationBuilder app, IHostingEnvironment env)
  {
      // Other middleware (like error handling) here
  
      app.UseAuthentication();
      app.UseMvc();
  }
  

2. Ensure Controllers Require Authorization #

Add the [Authorize] attribute to your controller or individual actions to enforce Windows Auth checks. Without this, the auth flow might not trigger correctly, leading to unexpected errors:

[Authorize]
[ApiController]
[Route("api/[controller]")]
public class ValuesController : ControllerBase
{
    // Your API actions here
}

3. Configure Kestrel for Windows Authentication (If Not Using IIS Express) #

If you're running directly with Kestrel (not IIS Express), you need to explicitly enable Windows Auth in your web host setup. In Program.cs:

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .UseKestrel(options =>
        {
            options.Listen(IPAddress.Loopback, 5000, listenOptions =>
            {
                listenOptions.UseWindowsAuthentication();
            });
        })
        .Build();

This tells Kestrel to accept Windows Auth requests on the specified port.

4. Diagnose the Exact HTTP 400 Cause #

A 400 "Bad Request" can be vague—enable debug logging to get more details. Update appsettings.json to increase log verbosity:

"Logging": {
  "LogLevel": {
    "Default": "Debug",
    "System": "Information",
    "Microsoft": "Information"
  }
}

Check the output window in Visual Studio or your log files for specific errors (like issues with Negotiate authentication headers or missing request data).

5. IIS Deployment Prep (If Planning to Deploy) #

If you'll eventually host on IIS:

• In the IIS site's Authentication settings, enable Windows Authentication and disable Anonymous Authentication.
• Ensure your web.config includes the correct auth configuration:

  <system.webServer>
    <security>
      <authentication>
        <anonymousAuthentication enabled="false" />
        <windowsAuthentication enabled="true" />
      </authentication>
    </security>
    <aspNetCore processPath="dotnet" arguments=".\YourApi.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />
  </system.webServer>
  

Give these steps a shot—most of the time, the issue is a missing middleware line or incorrect auth toggle. If you still run into problems, share the debug log details, and we can dig deeper.

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