Impersonation does not work with Interop.MSClusLib

I have a WCF web service with different sections that need to run under different users.

One of them is clustering, which is implemented using the Interop.MSClusLib API.

I'm trying to apply impersonation with a specified user, but it's completely getting ignored.

using (new Impersonator(_impersonation.User, _impersonation.开发者_Python百科Domain, _impersonation.Password))
{
    var cluster = new Cluster();
    cluster.Open(clusterName);
}

(Impersonator: http://www.codeproject.com/KB/cs/zetaimpersonator.aspx)

WindowsIdentity.GetCurrent() gets the user that I'm impersonating, but I still get:

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) at MSClusterLib.ClusterClass.Open(String bstrClusterName)

When I set the application pool identity to that user, it does work but that's not what I want to be doing.

Is there any way that this can get fixed?

Thx!

Got the explanation from a colleague:
There are 2 levels of authentication in applications: process and thread.
Impersionation only sets the thread identity, while the Cluster API seems to use the process identity.

The reason you don't get the error when you change the AppPool identity to the impersonated user is that the code is running in a thread with that identity. With WCF hosted in IIS, the service instance always runs under the AppPool identity. Impersonating a user doesn't change the security context of the running thread.

It is likely that the MSClusLib is accessing "remote" resources to perform its work. Windows impersonation is not capable (permission-wise) of accessing "remote" resources. You may be able to do what you need by implementing delegation instead of impersonation. You should look at this MSDN article to see how impersonation & delegation work in WCF.

This looks like it should work to me. I think you are correct that IIS hosting is the problem. Check whether your application pool account has "Act as part of the operating system". This MS Support article on accessing network files from IIS is doing what you describe:

LogonUser also requires that the account that calls LogonUser has the "Act as part of the operating system" privilege in User Manager. By default, most users who IIS impersonates while it handles an HTTP request do not have this user right. However, for "In Process Applications" there are a number of ways to cause your current security context to change to the LocalSystem account, which does have the "Act as part of the operating system" administrative credentials...

If this doesn't work, I suggest a quick test of hosting your service outside of IIS (The Visual Studio service host is easy for this type of test). Make sure that IIS really is the issue before you spend more time down that road...