I have a .NET Core application using OWIN and windows authentication with AuthenticationSchemes.Negotiate, hosted on Weblistener rather than IIS.
In some setups, this just works, whereas in others, a login prompt is shown, and the user cannot be authenticated. However, I never know why it works or why it doesn't.
How would I debug such a problem in a production environment, and what could I change in the application to make it debuggable in production? What logs can I look at, where can I enable additional logging, etc.? Are there any built-in ways of changing application settings related to authentication in production (other than changing the code, or adding custom code to make it configurable, or hosting it on IIS?)
NOTE: I'm not interested in how to "fix" the problem, as it can have many different causes and pops up here and there on many different servers.
More details:
The problem is easier to debug by eliminating unknowns, such as the .NET Core application. Integrated Windows Authentication (IWA) in WebListener (or HttpSysServer or Kestrel) is not much different from IWA in IIS. So a first step is to replicate the issue by setting up an empty IIS website, application or virtual directory with IWA enabled and anonymous authentication disabled and a binding to the same host name as the real application.
If the issue can be replicated, then IIS offers better ways to debug the problem (such as failed request tracing - which is totally not helpful, or using NTLM instead of Negotiate as the preferred provider, or disabling kernel mode, etc.).
If Kerberos is used (which is highly likely in production), then Kerberos logging can be enabled on the client machine by creating a registry value in Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters with name LogLevel, type DWORD and value 0x1, according to https://support.microsoft.com/en-us/help/262177/how-to-enable-kerberos-event-logging. Kerberos events can then be seen in the System log with Event Viewer.
If the issue can not be replicated in IIS, then there is a problem with the .NET Core application, but this is unlikely, because setting up IWA in the application code is straightforward and almost impossible to do wrong. If it works on one system and not on another, it probably has to do with Kerberos, AD, host names, etc.