HttpBinding HttpClientCredentialType.Windows IIS10 - Core 2.0

[cgountanis]

Trying to connect to SSRS Execution. Works fine on my development machine, soon as I move to IIS I get errors with the same exact remote SSRS server. Any tips tricks, most of the help from Google is the old way of doing it with XML file configurations. What really gets me is that it works from my development machine using IISExpress, why not on a TEST Server using IIS?

AppPool No Managed Code

The rest of the Core 2.0 MVC application works perfectly. Why would it work remote on my machine via VPN then throw error like that on TEST server which is on same network? I really think this has something to do with IIS.

basicHttpBinding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;

var serviceSoapClient = new ReportExecutionServiceSoapClient(basicHttpBinding, new EndpointAddress($"{model.ReportServerUrl}/ReportExecution2005.asmx"));

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

serviceSoapClient.ClientCredentials.Windows.ClientCredential = (NetworkCredential)(new NetworkCredential() { UserName = model.Username, Password = model.Password, Domain = model.Domain });

Error:

System.AggregateException: One or more errors occurred. (The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was ''.) ---> System.ServiceModel.Security.MessageSecurityException: The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was ''.

[cgountanis]

https://stackoverflow.com/questions/47416234/core-2-mvc-wcf-to-ssrs-execution-project-needs-administrator-iis-apppool-to-wo

[mconnew]

If you are hosting in IIS, I presume you are running on the full .Net framework and not .Net Core?

[cgountanis]

We install the .NET Core Windows Server Hosting bundle and run Core 2 web applications through IIS. I would say .NET 4.5 might be installed by default being that it is latest Windows Server but we are not using it directly with these applications.

[mconnew]

This seems like it might be an issue with the IIS Asp.Net Core module. Your code isn't running inside the IIS app pool process, it runs in its own process which IIS launches via Asp.Net Core module. Changing the identity of the app pool is modifying the inherited permissions of your Asp.Net core process. Whatever is happening there is messing up the authentication. Can you reproduce this issue without WCF and using HttpClient/HttpClientHandler directly? Try and access a service URL using HttpClient and see if it reproduces. Having WCF involved makes these sorts of issues harder to diagnose.

[cgountanis]

Understood. Just trying to access SSRS reports in PDF form. To be honest, I don't know any other way to do it. Would you have a simple example that I could test with? Based on my code example is there an easy way to just use the client and not the built-in easy way of doing things? Willing to research if you have maybe a link or just a little bit of a tip.

[mconnew]

You don't need to send anything intelligible to the server as the authentication comes before looking at the request. The URL needs to be correct, that's all.

[cgountanis]

I will give it a shot. One thing I did test was a bad URL and it would fail as expected. So troubleshooting wise I know it's connecting just has some kind of strange issue with the header unless you run the app pool as administrator very strange. Both machines have no similar users and no domain always worked on my development machine just very odd.

[mconnew]

You will need to hit the same URL and possibly (I think most likely but not 100%) send a POST request as authentication is done before the request body is looked at. Once it sees an unintelligible POST body, it will return either a simple 400 bad request response or a full blow SOAP fault xml message if it gets past authentication. If this fails (and please validate that you get a different response than when running the test in the successful iisexpress scenario), as you aren't using a domain but instead are using local machine user accounts, could you set up a temporary dummy user and capture a trace using fiddler and provide that trace? It's important to use a dummy account as capturing the traffic of NTLM authentication is as good as capturing the actual username and password and anyone with access to the capture can be presumed to be able to authenticate as that user so make sure you disable/delete the dummy account before making the capture available and don't reuse any passwords.

[cgountanis]

Just to clarify when I use IISExpress I am connecting to the same remote server, the only difference is IIS vs IISExpress and what came down to AppPool permissions. I was not connecting to some local SSRS machine during development or anything. I send the same U/P (SSRS Windows User), read from settings. I will try what you ask but it is very strange to me that it works with Admin AppPool in IIS, not like that local user exists on the SSRS machine.

[cgountanis]

Is this a known issue or am I just out of luck? Is there anything wrong with my code above? Seems simple enough. Should I be using an easier way, maybe using WFC to access a simple web service is not the easiest way? I tried again today, same issue everything but running the AppPool as Administrator works and again the remote server does not have anything in common with the IIS server, not even on a domain.

The error is not even close to helpful as I tried all the basics.
2018-03-08 17:10:04.729 -05:00 [Error] One or more errors occurred. (The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was ''.

Full code: https://stackoverflow.com/questions/47416234/core-2-mvc-wcf-to-ssrs-execution-project-needs-administrator-iis-apppool-to-wo

Why would it work as AppPool Administrator and not LocalService or anything else?

[mconnew]

@cgountanis, there is something going on with how the AspNetCoreModule is launching a child process such that the authentication isn't working, the issue isn't with WCF. Unfortunately as you've experienced other teams have difficulty with understanding problems when WCF is involved as it's seen as a black box (and WCF has a large code base so to some degree this is understandable). The information I requested of you previously will allow one of two things to happen. Either I'll be able to work out what's going on and can give you a workaround or talk to the appropriate team directly to get them to fix this, or I'll be able to help get the correct person looking at the problem to root cause the issue and they won't have WCF involved in their investigation causing confusion.
Right now I just have a description of what's going on with no logs or data to aid in diagnosing. If you want this worked on, you will need to provide some logs.

[cgountanis]

@mconnew Can you be specific on where and what logs would be helpful? I will get and learn with this information, I am clueless to what logs would be helpful other than the ones coming from my WebApp. Maybe IIS logs would show more information? Please let me know what would help dig into this as SSRS SOAP via WCF with Core seems to be a mystery.

Worst case can I just drop WCF and get a heads up on how to connect to ReportExecution2005.asmx manually and simply get the response which turns out to be the binary version of the report. That is all I need just not my strongest area.

[cgountanis]

So what I have done for a work around is just add a locked down (system) Windows User, remove from all groups and run the AppPool/Directory permissions as that system only user. Took a Linux approach and it works fine. I guess it just needed a user other than what the AppPool options provide default. It would be nice of this was solved, would love to run as AppPool default virtual user but not in the cards, better work around the running as a high privileged user at least.

[mconnew]

@cgountanis, sorry I didn't get back sooner. The logs I was mentioning was fiddler logs that I asked for here. If you still want to pursue finding a solution for this even though you have a workaround (which I agree isn't an acceptable workaround), then feel free to reopen the issue. One thing which you might want to try is using a preview release of .Net Core and setting the environment variable to enable usage of SocketsHttpHandler as the underlying implementation behind HttpClientHandler. This has a different implementation of NTLM authentication and might behave differently. If you would like more information about that option, let me know and I'll get the information on how to enable SocketsHttpHandler in your app.

[cgountanis]

I would test that, just waiting on final release, on the latest stable right now with the runtime 2.0.6. The issue with fiddler is I have very little experience in getting you want you need. If you have a 10 step guide I can get you whatever you want privately.