.NET Core and IIS Intermittent 403 Access Denied

Question

Alright Stackoverflow, after much fruitless research I've ended up here!

I am attempting to get a .NET Core 2.0 site hosted out of IIS with Windows Authentication and SSL, and no matter what I try I continue to get inconsistent/intermittent 403 Access Denied errors.

If there was something dead-wrong, I would expect it never to work. However, it works maybe ~3/10 times if I restart the site and the app pool. There is nothing useful that I can find in the Event Viewer, Application Logs, or IIS trace logs.

Things I have done in no particular order:

1. The app pool is running as a gmsa account with rights to my database (prod.service$)
2. Granted log on as a service, and log on as batch to the gmsa account.
3. Granted IIS_IUSRS, prod.service$, and Domain Users permissions on the web root folder. Currently at full-control out of despair.
4. Granted IIS_IUSRS, prod.service$, and Domain Users permissions to the certificate.
5. Enabled Windows Auth, Disabled Anonymous Auth
6. Set default document pointing to the front-page.
7. Set the app pool to "Load Profile"
8. Set the .NET CLR version to "No Managed Code"
9. Set ForwardWindowsAuthToken to true in the web.config
10. NTLM has been moved to the top of the list as the first auth provider under Site > Authentication > Right-Click Windows Authentication > Providers

One more detail is that I am trying to authenticate with users from a different domain, where a one-way trust is set up. I am remoting into the host with credentials from the 'other' domain, so it has visibility.

Here is my web.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="dotnet" arguments=".\MCP.MVP.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="true" startupTimeLimit="3600" requestTimeout="23:00:00" />
    <defaultDocument>
        <files>
            <add value="/home/index" />
        </files>
    </defaultDocument>
  </system.webServer>
</configuration>

<!--ProjectGuid: [REDACTED] -->

From Startup.cs:

services.AddAuthentication(IISDefaults.AuthenticationScheme);    
services.Configure<IISOptions>(options => 
    {
        options.AutomaticAuthentication = true;
    });

From Program.cs

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
    .UseIISIntegration()
    .UseStartup<Startup>()
    .Build();

Using Authorize attributes everywhere:

[Authorize(Policy = "RequireViewerRole")]

Authorization Glue, where Configuration["RequireViewerRoles"] is a comma delimited list of domain groups:

services.AddAuthorization(options =>
        {
            options.AddPolicy("RequireViewerRole", policy => policy.RequireRole(Configuration["RequireViewerRoles"].Split(',')));
        });

Have I entered .NET Core 2.0 bug territory, or am I missing something?

Answer 1

It turned out to be a massive red herring!

It was a 401.2 "invalid server configuration" error. I finally noticed a pattern where the application would work if I opened up the folder security permissions dialogue, which would forcibly hit the domain-controller and cache the group names from the user domain. The application would work fine for about 5 minutes, before refusing to authenticate again with no other changes made.

The issue was solved by configuring the domain name on the group, which is obvious in retrospect. (DomainName\\Domain Users). The fact that it worked at all without the domain name led to a lot of confusion. There was nothing to indicate this error from the IIS logs, and ultimately it was solved by trial and error.