7

I have two sites, A and B. A consumes an API that B exposes, and B requires Windows authentication. Both sites live in Domain D.

The API is consumed via HttpClient, and when site A is run locally, under my domain account (which is in Domain P), access is granted. In this case, HttpClient is instantiated like so:

using(var client = new HttpClient(new HttpClientHandler { UseDefaultCredentials: true }))

When A is deployed to a testing server, the above results in a 401 Unauthorized response. The application pool on the testing server is running under a service account in domain D.

When explicitly using that service account like this:

var credential = new NetworkCredential("service-account", "password", "D");
var cache = new CredentialCache
{
  {
    new Uri(apiServerUri), "NTLM", credential
  }
};
var handler = new HttpClientHandler
{
  Credentials = cache
};

using(var client = new HttpClient(handler))
...

And again running site A locally, access is still granted. Access is also granted when accessing the API directly via browser, and specifying the service account credentials. Logs indicate that it is definitely the service account being used to access the API.

Deploying the above back to the testing server still results in 401 Unauthorized.

Deploying site A to a local instance of IIS, also successfully consumes the API of B.

Running site B locally, and then accessing it via site A locally, results in a 401 Unauthorized.

Accessing the API through a browser on the testing server where A is deployed, and specifying the service account credentials, also gives a 401 Unauthorized.

I'm not sure where to go from here - am I missing something in the code to get this working? Or is it likely to be an IIS or AD issue?

TylerH
  • 20,799
  • 66
  • 75
  • 101
pala_
  • 8,901
  • 1
  • 15
  • 32
  • Smells like Kerberos issue, try this: http://blog.jimmychandra.com/post/service-principal-name-headache – Jimmy Chandra May 12 '15 at 01:43
  • I'm not trying to do double-hop or passthrough authentication - so i'm not sure how it would be a delegation issue? It should just be using the app-pool identity. But we'll still give it a shot – pala_ May 12 '15 at 01:55
  • So Web 1 is on the same server as Web2? Might be just knee jerk reaction since I was seeing Server To Server. Assuming client -> server 1 -> server 2 (as in literal server box / server instance and not just web app level)... – Jimmy Chandra May 12 '15 at 02:07
  • Probably this SO thread may give some heads up. http://stackoverflow.com/questions/12212116/how-to-get-httpclient-to-pass-credentials-along-with-the-request – Pankaj Kapare May 12 '15 at 02:14
  • 2
    How is the trust setup between domains? Selective authentication? What domain is your local computer on, P - same as your user account? If it's not the same as the server then your computer might have the "allowed to authenticate" permission against domain D, but the service account in domain D might not. – thinkOfaNumber May 12 '15 at 03:04
  • @JimmyChandra - currently, site `A` and `B` are hosted on the same virtual server. This may change, but currently it is how it is. – pala_ May 12 '15 at 03:14
  • @PankajKapare i read through it, but we're not trying to accomplish impersonation here – pala_ May 12 '15 at 03:14
  • @thinkOfaNumber Local computer is on domain P, same as user account. For 'allowed to authenticate', are you saying that it applies to the domain of the machine asking to be authenticated, and not the domain of the user account that is being authenticated? This would make sense, as my domain user account on P cannot authenticate from the test server for site `A` – pala_ May 12 '15 at 03:16

1 Answers1

7

While I'm yet to determine exactly why this work around works, or if there is a better way of doing it (because this feels clunky), the following has allowed A to connect to B, when both are sitting on the same server.

Site B has had an additional host binding setup in IIS, to listen on localhost:12345. Site A has been configured to connect to that endpoint, rather than the domain name for Site B. Authentication is now working correctly.

I would be interested if anyone can explain why this is the case - I dislike 'magic' fixes.

edit It would seem that this kb article is a likely cause for this behavior. Specifically:

When you use the fully qualified domain name (FQDN) or a custom host header to browse a local Web site that is hosted on a computer that is running Microsoft Internet Information Services (IIS) 5.1 or a later version, you may receive an error message that resembles the following: HTTP 401.1 - Unauthorized: Logon Failed This issue occurs when the Web site uses Integrated Authentication and has a name that is mapped to the local loopback address

and

Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.

Registry modifications aren't really an option on these servers, so looks like the work around is what we will be using.

pala_
  • 8,901
  • 1
  • 15
  • 32