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