Classic ASP Impersonation problem on IIS7 Windows 2008 server

Question

Hi,

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).