2

I was tasked to port and move an old ASP application from a Windows 2003 server (x86) to a Windows 2008R2 server running IIS 7.5

A number of things needed to be changed (mostly related to registry access) but I stumbled across one problem that I couldn't solve in a satisfying way.

The application makes use of an external COM object (in-process dll). It will create an instance of that object during the login phase and store it as a session variable.

This used to work quite nice and worked well in my test but when I deployed it on the first production server, I started to have random "500" errors when users tried to log in. The error was really not consistent so I used procmon to trace the source of the problem and got this: when a user tries to access the web site, the IIS worker process tries to open the Dll that hosts the COM object but fails with an access denied error.

Now, I don't understand this: the web application uses a service account for accessing the local resources. That service account has explicit rights on the directory where that COM library is located. Yet, the access to that file is still denied.

I "fixed" the issue by giving "everyone" explicit read and execute access on the dll and it (seems to) have solved the problem.

But I don't know why.

The strangest thing is that is I use a local administrator account to connect to the web page once (and just once), then the issue was fixed for as long as the application wasn't recycled.

I would appreciate if anyone could shed some light on that issue. I can live with the fix, but I really would like to understand.

Edit To clarify: the web site is NOT set to impersonate the connecting user. In fact, the only authentication scheme enabled is "Anonymous Authentication". The basic settings, however, are set to use the service account.

Edit The identity reported by procmon during the access denied is "IIS APPPOOL\(application name)"

Stephane
  • 6,382
  • 3
  • 25
  • 47
  • The most relevant detail - still omitted - is the identity of the W3WP thread trying to access the DLL the first time. That's the identity that needs Read permission, regardless of everything else. – TristanK May 10 '12 at 10:48
  • You are correct. I remember checking that and not being able to make sense of the result. I will check again and update the question. Thanks – Stephane May 11 '12 at 07:18

1 Answers1

1

I think you've answered your own question.

Your web app is configured to impersonate an authenticated user.

When a request is accepted, the thread handling the request is given the token of the user that authenticated, and then that identity is used for all operations by that thread until the request terminates.

The COM object only needs to be loaded once, and Admins can read basically any file, so the first request as an Admin is able to a) read the file and b) load it into the process address space. This usually doesn't need to happen repeatedly: once the DLL is in memory, it's there.

If a regular user (or anonymous user) authenticates and is impersonated, they didn't have permission to open the file in the first place, and ProcMon should show you that, along with the identity which was being used. (By default: IUSR for anonymous requests).

The "service account" bit you've described sounds like a worker process identity. They're only used to start the app pool, read the configuration, and then for sitting around doing things that aren't directly related to a request*.

* unless you're using the App Pool account as the anonymous user account, and unless the thread impersonating the user isn't able to get off-box (i.e. needs to delegate), in which case the App Pool account will be used.

TristanK
  • 8,953
  • 2
  • 27
  • 39