Question

I am trying to call a Sharepoint Web Service via WCF from inside a .ASHX on a different server. My code works if I run inside of Visual Studio’s debug web server, but not from IIS. The working server works in various authentication modes (Kerberos, NTLM), and the non-working one doesn’t work in any. I am impersonating the same user in both cases.

Using NTLM, I recorded a working session and non-working session in Wireshark. In the working one, Wireshark parses the NTLM data and reports a DOMAIN and USER NAME that I expect. In the non-working one, it shows

  DOMAIN: NULL
  USER NAME: NULL

I have debugged in IIS and impersonation is definitely working at the point of the service call. If I check WindowsIdentity.GetCurrent(), it’s the user I expect.

If I inspect the WCF service proxy on the working and non-working servers, they look identical — the part that deals with ClientCredentials is set to "" for Username and Password for both versions.

Any ideas on what else to check? Why would the NTLM data have DOMAIN and USER NAME set to NULL — where does it pick that up from?

Answer 1

According to this:

http://support.microsoft.com/kb/207671

When IIS services an HTTP request, IIS performs impersonation so that access to resources to handle the request is limited appropriately. The impersonated security context is based on the kind of authentication performed for the request. The five different types of authentication available from IIS 4.0 are:

Authentication Type                          Impersonation Type
------------------------------------         ---------------------
Anonymous Access (no authentication)         Network
Auto Password Synchronization is
ON (ON=default)

Anonymous Access (no authentication)         IIS Clear Text
Auto Password Synchronization is OFF         

Basic Authentication                         IIS Clear Text 

NT Challenge/Response Authentication         Network 

Client SSL Certificate Mapping               Interactive

In my case, I have a Network Token, but

Network tokens are “NOT” permitted to access network resources. (Network tokens are named so because this kind of token is traditionally created by a server when a user is authenticated across the network. To allow the server to use a network token to act as a network client and access another server is called “delegation” and is considered a possible security hole.)

The KB has many possible ways to avoid the problem