views:

385

answers:

1

Case 1. When I browse a little test site from my own PC called JOHNXP (e.g. http://localhost/WebClient ), my .aspx page invokes my ASMX webservice picks up my credentials and passes them across to another webservice on ANOTHER machine (SERVERTRIM) in the same domain. I can see my request resulting in a Security Log entry on the SERVERTRIM machine with my credentials.

Case 2. I move to another PC in the same domain and logon with the same credentials I used back at my personal desktop. When I browse the same test site above (this time as http://johnxp/WebClient ), I get this percolated back to my .aspx page:

System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.Net.WebException: The request failed with HTTP status 401: Unauthorized

Looking at the Security Log on SERVERTRIM, I note that the access in case 2 resulted in an ANONYMOUS LOGON which seems to explain the 401 / Unauthorized.

I'm trying to get my webservice to use the credentials of the logged in DOMAIN user when my WS calls a vendor's webservice on a different server.

My ASMX webservice runs on my desktop (IIS 5.1 WinXP Pro - machine name is JOHNXP). I have Enable anonymous UNCHECKED in every server involved and I have this in every web.config involved in my scenario:

The vendor webservice runs on SERVERTRIM (Win 2003 Server) and it is also ASMX and uses WSE 3.0.

Wireshark and Netmon look too formidable as tools for me right now. I am figuring the different resulting LOGONs on the "remote" server (SERVERTRIM) are sufficient "evidence". All machines above are in the same domain but I want to keep the "remote" webservice on SERVERTRIM and my intermediate webservice on a different server in the same domain if possible. Does this scenario demand that I have to dig into "delegation"? What would be the easiest tool to monitor why the same credentials result in an ANONYMOUS LOGON when the web request is initiated on another machine in the domain?

A: 

My knowledge of authentication is a bit hazy, but if I understood your description correctly:

  • in the first case, you're browsing to localhost, which is impersonating the caller, then calling a web service on a different machine. The impersonation is being done on the same machine as the client. I believe in this case, the impersonating application doesn't need to be on a machine that is trusted for delegation (because it's already the same machine as the client).

  • in the second case, you're browsing to a different PC, which is attempting to impersonate the caller when calling a third PC. In this case, the PC in the middle would need to be trusted for delegation (which it presumably won't be if it's a development workstation).

Joe
Joe, I think you've described it correctly. The "PC in the middle" name is JOHNXP and it has been marked "Trust computer for delegation". Also, the webservice running on JOHNXP is started from VisualStudio2005 while I am logged on as CBMIWEB\johna. When the doc for delegation says to "configure the user account under which the server process runs", I took that to mean CBMIWEB\johna and ActiveDirectoy has "Account is trusted for delegation" now CHECKED. I've tested both ways and it still fails.
John Galt
When you say starting the WS from VS2005, do you mean with the Cassini server or IIS? And if IIS are you definitely running under a domain account?
Joe