<identity> Issues w/Web Service

  • Thread starter Thread starter nobody101
  • Start date Start date
N

nobody101

I have a web service configured with Anonymous access disabled.
The calling client, prior to executing a method on the service,
sets its network credentials for the IIS to authenticate:

CredentialCache cacheVU = new CredentialCache();
cacheVU.Add( new Uri(<my url here>), "Negotiate",new
NetworkCredential( Username, Password, Domain) );

WebServiceProxy.Credentials = cacheVU;


My web service method works OK. However, I need to access a network
share, so I wanted to use the

<identity impersonate="true" />

setting in my web service's web.config file. However,
when I try to access the remote share, I get an access denied error:
Access to the path "..." is denied

However, if I change the <identity> element and add the "username"
and "password" attributes - which are the same username and password
that the web service authentication use, it works OK.

I thought the <identity> w/o the username/password should
inherit the user context.

I added some debug statements, and displayed:

- Thread.CurrentPrincipal.Identity
- WindowsIdentity.GetCurrent
- User.Identity

and in both cases ( with and without explicit username/password in the
<identity> element), the
dumped names are the same, so I am assuming the impersonation is
enabled. So, why are my access rights denied for the case w/o the
explicit username/password defined?
 
its because of the 1 hop rule with nt authentication. to tlak to another
server server, the process need a primary token. when you set the user name
password in the webconfig, the web service has a primary token and can talk
to other network services as that user. when impersonating the login from
the user, this is not a primary token (thats on the client box), and can not
be used to access resouces on another server.

you have 2 work arounds

1) use basic instead of ntlm (should use https in this case as the password
passes in clear text). this will give the webservice a primary token.
2) use Kerberos, and allow creditial forwarding.

-- bruce (sqlwork.com)
 
Back
Top