IIS moving virtual directory to file share breaks impersonation of logged on user

Question

We have an instance of IIS6 running an intranet website with Windows Authentication and Impersonate = true so that it uses the NT credentials passed in by the clients browser. The AppPool is set to run as a network service user: serviceAcctX so that we can undo impersonation in rare cases (to read or write a resource that the client user does not have access to)

It works perfectly when the source of the virtual directory is on a local drive. The logged in user is authenticated and page content is customized based on authorization settings.

Our infrastructure team is trying to move the virtual directory source to a file share on a remote server. We have already gotten past the issue with changing the .Net security policy by adding a full trust for that specific file share path. We have set the Connect As property to the same serviceAcctX, the same one that the AppPool is running as.

The site starts fine. However, the client user is not impersonated. The request is processed using the default serviceAcctX credentials instead of with the client's NT credentials as before.

Is there a way to have the client impersonation still work as before and still have the virtual directory on a file share? Any pointers are greatly appreciated.

Answer 1

You may have to check the "trust this computer for delegation" check box in Active Directory for the web server in order for the user's token to be passed on.

Answer 2

I'd put this in the category of Not A Good Idea.

There are a number of potential problems that crop up and you are introducing a lot of dependent complexity.

Instead, I'd go for something a little more "offline" than this. Use File Replication to keep the files in sync between your web server(s) and remote server.

Although slightly complex, it increases the survivability of your application. Meaning, if the remote server reboots, goes down, or there is a network problem between the two, your app is still functional. Further, you are still able to have the files on the remote server.