This is certainly not my area of expertise and your own knowledge likely
exceeds my own. I believe you are headed in the right direction, it
probably does involve the impersonate tag  in one the *.config files.
However, I didn't follow your situation well enough to make an educated
suggestion.

Here is an article that helps explain all the possible combinations:
http://support.microsoft.com/kb/306158

I found some info… not great news, but it’s an answer. Granted, this is from a 3rd  party who worked  with an AD expert in his org, as well as 2 MCS consultants.

Some background:

In the below situations… all portal  & web  service virtual servers and web applications do not allow anonymous requests, but do require  integrated authentication. I am trying to pass  the default credentials  of the current logged  in user  off to the web service  I’m requesting.

This works:

· Web part  on SERVER-A in portal http://portal1 requesting a web service on SERVER-A at http://portal1/webservice

· Web part on SERVER-A in portal http://portal2 requesting a web service on SERVER-A at http://portal1/webservice

This doesn’t work:

· Web part on SERVER-A in portal http://portal1 requesting a web service on SERVER-B at http://portal3/webservice

This has something to do with the underlying credentials, but not with settings in IIS. Apparently AD can’t pass credentials off to too many hops. So… once you were authenticated on one server, that’s one hop from your desktop -> server. But when that server  was trying to pass those credentials off to a second server, the hops are exceeded and they aren’t sent. Apparently this isn’t a bug… it’s known… and it looks like it’s a security feature. You can impersonate another user, but then you have to keep track of someone. Apparently there is something special within Kerberos that we could implement to make this work… but that’s over my head and not available (from what I’m told).

This IS a known and intended security
limitation.

However, we have successfully overcome this limitation using an
AppDomain. This solution effectively creates a new worker process  with
no security hops running in a security context that you establish. We
had to do this to overcome Anonymous user  problems accessing the
SharePoint API via impersonation.

I believe that you can also use a local Web Service that subsequently
calls the remote Web Service. That may be the simplest solution.

I never considered the local web  service that calls a remote web service… in effect I guess you’re creating  a proxy service  on the local server. How is that any different from doing another hop to the remote box?

I believe that the local Web Service would have its own security context
from which you could make your hop. Not sure how you instantiate the
local Web Service using the credentials  of the currently authenticated
user but I think it can be done.

I got that far (instantiate the local web  service using the credentials  of the current  user).

Look at the following:

[webservice object].Credentials = CredentialCache.DefaultCredentials;

You also need to have the following:

Ø your site/web application security in IIS must not be set  to anonymous and should be set to integrated.

Ø Your web.config should have the impersonation  node set to true  (SharePoint does this by default)

Did using a local Web Service to call the remote Web Service work?

Haven’t had a chance to test… in the “tight deadline, gotta make it work ASAP and move onto next task” mode. It’s on my post-launch “dig deeper” list.

I’ll let you know.