HttpBinding HttpClientCredentialType.Windows IIS10 - Core 2.0
See original GitHub issueTrying 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 ‘’.
Issue Analytics
- State:
- Created 6 years ago
- Comments:15 (6 by maintainers)

Top Related StackOverflow Question
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.
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.