36

I'm having some trouble calling a web service from within a web application and I was hoping someone here might be able to help. From what I can tell, this seems to have something to do with the Kerberos double-hop issue. However, if it is, I'm not sure what to do to actually fix the problem. To make things harder, I don't have the proper permissions to make changes to Active Directory accounts, so I need to know what to ask for when requesting changes. In my situation, I need to pass the credentials (Integrated Windows Authentication) from a web application onto a backend web service so that the web service runs under the proper user context.

Here's my exact issue:

This works

Working scenario

This doesn't work

Non-working scenario

The only difference between the working scenario and the non-working scenario is that the working scenario is running the application on localhost (whether a developer's PC or on the server in question) and the non-working example is running on another machine. The code between both scenarios is exactly the same.

What I've tried

  1. Adding an SPN to the domain account that runs the app pool for each server setspn -a http/server1 DOMAIN\account
  2. Different methods of impersonation
  3. Removing the impersonation code using(...) and executing the web service call as the app pool account. This works as expected.

Does anyone have any idea on what I might be able to do in order to fix this problem?

Steve Platz
  • 2,215
  • 5
  • 28
  • 27

2 Answers2

18

The intermediate server must be trusted for delegation. Otherwise no credential will be delegated and the intermediate server cannot impersonate the original client.

coni2k
  • 2,535
  • 2
  • 20
  • 21
Michael-O
  • 18,123
  • 6
  • 55
  • 121
  • 1
    This ended up being the solution in the environment I described above. However, we ran into (and are still running into) the same problem in our production environment now that NLB is being used. I'm working through the problem now, but need to set up a test environment that mimics our production environment in order to pinpoint the exact cause. Any chance you know what do do in that case? Adding an SPN to the domain account running all of the services with the cluster name and FQDN ended up breaking all authentication. – Steve Platz Feb 20 '13 at 19:41
  • You cannot map a SPN to several accounts. All SPNs have to be distinct forest-wide. Since you are behind a load balancer, you could try the following: 1. forward DNS to the NLB domain, reverse DNS to the actual servers. 2. Use the NLB in conjunction with DNS round-robin. This works for sure. – Michael-O Feb 20 '13 at 21:14
  • Maybe I explained things incorrectly due to my limited knowledge of the problem space. What I initially tried doing (that broke everything) was to run the following commands: setspn -A http/servername DOMAIN\webaccount setspn -A http/servername.FQDN DOMAIN\webaccount – Steve Platz Feb 25 '13 at 15:04
  • Actually, it's fine to register two SPNs. One for the FQDN and the short name. But the latter is not necessary if you have DNS-only in place with FQDNs. Make sure that all SPNs are unique. – Michael-O Feb 26 '13 at 12:01
  • 7
    I found the *exact* for my problem yesterday. What you had suggested helped fix the problem delegating credentials to another server. To fix the NLB issue, in IIS > 7, I had to add "useAppPoolCredentials = true" to the application's configuration in order to have everything work as expected. Without that configuration element, all authentication was broken. – Steve Platz Feb 27 '13 at 12:12
  • 1
    Great, are you able to link any documention for that flag for other users? – Michael-O Feb 27 '13 at 18:23
  • Does this require trusting the server for delegation AND SPN, or just trusting the server for delegation? – Goulash Dec 13 '19 at 15:28
  • @Mr.King You trust a specific account, not an SPN. – Michael-O Dec 13 '19 at 15:33
  • @Michael-O yes, I understand that, however, my question is: do I need to have SPN properly configured for double-hop delegation to work, or can I just use the trusted delegation toggle? – Goulash Dec 13 '19 at 16:46
  • 1
    @Mr.King, yes. Otherwise you won't get any service tickets. – Michael-O Dec 13 '19 at 23:13
4

More often than not the reason is that Server 1 does not pass a delegation token to Server 2. So when Server 2 tries to use that authentication ticket to go somewhere else (probably a SQL server) it fails.

You should set the impersonation level for the WCF call 

ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Delegation

http://msdn.microsoft.com/en-us/library/system.servicemodel.security.windowsclientcredential.allowedimpersonationlevel.aspx

Knaģis
  • 20,827
  • 7
  • 66
  • 80