Classic ASP Impersonation problem on IIS7 Windows 2008 server

Question

I am trying to write to a file on a server (web05) from a classic asp site running on Windows 2008 serer on IIS7 (webadmin). This fails and web05 logs an anonymous logon attempt during the course of the save operation.

Webadmin's site is running on an app pool in classic mode with a domain user as the process account. The process account has rights to "Trust this user for delegation to any service (Kerberos only)". The same applies for the web05 and webadmin servers.

The site is using Windows Authentication and the idea is that when I log on the site with my domain user, the rights of my user should define what I am allowed to do in the context of the IIS site. If I turn on Basic Authentication, everything works fine.

I have also used setspn.exe to add an SPN for the URL. If I type setspn.exe -L webadmin, I get:

HTTP/webadmin.companyname.com
TERMSRV/webadmin
TERMSRV/webadmin.companypub.local
HOST/webadmin
HOST/webadmin.companypub.local

So from what I understand the SPNs are set up correctly.

If I run processmonitor on webadmin while the save operation is executed, it says that the process is indeed impersonating my domain user - but getting "Access denied" (and as I said before, web05 logs an anonymous logon attempt).

Any idea what causes this?

Kind regards, Simon

Answer 1

It sounds to me like you're a little confused over impersonation. The process isn't impersonating the domain user account its simply running as that user. There is a difference.

When a request arrives into ASP it will then impersonate a user and the thread handling the request will be running under the security token of the impersonated user. Its quite possible to have the same process impersonating multiple different users in multiple threads. In most cases where the anonymous user access is enabled this user is the Guest level IUSR account. Its most likely that its under this user your code is attempting and failing to run.

However if anonymous is turned off for the resource being accessed or the IUSR account does not have access to the resource then the a 401 response is sent back, with some indication of what authentication protocols it will accept. The browser may then attempt to authenticate the connection using either the current users credentials or request some credentials from the user.

You don't specify exactly how you are attempting to save file. Its worth pointing out couple of things though.

1. ASP code exection which may subsequently result in an access denied will not use the above mechanism to try to resolve the user.
2. Once a connection is authenticated it often continues to be re-used for subsequent requests (which is counter-intuative to the knowledge the HTTP is a "connection-less" protocol).

Answer 2

I ran into this same issue and it turned out to be a simple change to the application pool. If enable 32-bit applications is set to FALSE then I recieved a prompt to login to the machine. Setting this value to true fixed the issue.

Answer 3

I am trying to clean up my previous questions. This answer is not sufficient to answer the question above, but I concluded that it is better to provide some insight than none. If op disagrees, please take necessary action.

This is a way back - but I recall wanting to run kerberos authentication on this app. The problem turned out to be that I tried to do kerberos outside the firewall. The app would work fine within the domain and firewall of the server's home domain but failed whenever requests came from outside.

I did a lot of chatting with an Irish technician in Microsoft, and he taught me a little about the limitations when using Kerberos. The reason I wanted to use Kerberos was that I didn't like the thought of Basic Windows authentication being unencrypted.

Good luck with your Kerberos quest :-)