Access denied to Temporary ASP.NET Files folder after iisreset when browsing site using the server's own Internet Explorer

Question

Configuration:

• Windows Server 2008 R2/IIS 7.5

• ASP.NET web application using Windows Integrated Authentication. Application pool identity is set to NetworkService. Targeting .NET Framework 2.0. Managed Pipeline mode = Classic.

• Full permissions granted to the Temporary ASP.NET Files folder for the Users group and the Internet Guest Account

• Logged into server as a test user account (let's call it testuser) which is a member of the Administrators group

• User Account Control is on

• Internet Enhanced Security is off

• Internet Explorer is using all the default security settings and all Compatibility View settings are off

Now I do the following:

1. iisreset.exe

2. clear Temporary ASP.NET Files folder

3. open Internet Explorer

4. browse to the local ASP.NET web site => success

5. close Internet Explorer

6. iisreset.exe

7. open Internet Explorer

8. browse to the local ASP.NET web site => FAIL

So far, I have found a few things I can do to keep the site working after an iisreset.exe (each of these work individually, i.e. they do not have to be combined):

• Turn off User Account Control

• Log in as the Administrator

• Run Internet Explorer "As Administrator..." (instead of defaulting to the testuser account)

• Use Google Chrome or Mozilla Firefox instead of Internet Explorer(?!?) Those two browsers do not have to be run using the Administrator account but work perfectly well running under the user account and with User Account Control turned on.

• Browse the site using an Internet Explorer instance running on an external machine

This problem does not exist on Windows Server 2003. It would appear to be related to User Account Control somehow.

It makes no difference if the user is a member of the Administrators group or not.

Using Process Monitor, it would appear that the access denied problem happens when NetworkService (w3wp.exe) is impersonating the user, but given all the permissions granted to the Temporary ASP.NET Files folder, this still does not make much sense.

The question is:

Why does this only occur with the local Internet Explorer browser, running as a non-administrator user? I would like to use the local Internet Explorer browser for testing, but having to clear the Temporary ASP.NET Files folder after an iisreset is annoying.

What makes Internet Explorer different from Chrome or Firefox (which both work) in this scenario? I could understand if this was something that affected all local browsers, but this is not the case.

I could understand if my web application was doing something special when detecting that Internet Explorer is being used as the client browser, but I do not believe that to be the case and we are talking about an assembly binding failure here - I am not trying to access some arbitrary folder.

EDIT:

• The tests above were done using Internet Explorer 8. I have since tried Internet Explorer 9 on the same machine, but with the same results.

• If I enable ASP.NET Impersonation for the web site, the problem goes away - but I still would like to know why it does not work for a local Internet Explorer when ASP.NET Impersonation is disabled.

EDIT 2:

What I failed to mention the first time around is that logging in is a two-step process: When accessing the application (let's call it "MyWebApp"), you are redirected to a MyWebApp/Login directory where you will be prompted for your Windows credentials before granted access to the login page residing in that Login directory.

This always works.

After entering your application credentials (in case the code in the login page does not recognize your Windows credentials), you are redirected to a page in the root folder.

The Authentication settings for MyWebApp and MyWebApp/Login are as follows:

                             MyWebApp         MyWebApp/Login
                             --------         --------------
Anonymous Authentication     Enabled          Disabled
ASP.NET Impersonation        Disabled         Enabled
Basic Authentication         Disabled         Disabled
Digest Authentication        Disabled         Disabled
Forms Authentication         Enabled          Enabled
Windows Authentication       Enabled          Enabled

In both cases, I am getting the "Challenge-based and login redirect-based authentication cannot be used simultaneously" warning.

These settings date back to before I got involved with the project, but that is besides the point. Right now I am only interested in what it takes to get it right - preferably a set of settings that will work for IIS 6.0 and 7.x alike.

Setting ASP.NET Impersonation = Disabled for "MyWebApp/Login" appears to be another way of making my problem go away, but clearly there is more to be done here.

Answer 1

The issue is almost certainly related to Internet Explorer using Windows authentication rather than Basic Authentication (what you'd likely get with FF or Chrome). The combination of Windows authentication and ASP.NET impersonation. If you enable NTLM authentication in Firefox, you will likely see the same behavior there. Likewise, disabling Windows authentication (forcing IE to use basic) or disabling impersonation will likely cause IE to behave like Firefox.

Answer 2

I cannot imagine that browsers have anything to do with it, but if you experienced differences, it must be true. For ASP.NET to be able to compile an ASPX file, 2 things are imported (as we found out today:

1. Write access to the ASP.NET Temporary files dir (where the compiled DLL is written)
2. Write access to the Windows TEMP (where csc.exe writes intermediate files like *.obj)

Which user should have acces there? Depends. In our case the Application Pool user. In your case maybe the impersonated user. Or the IUSR. To me, that part is still obscure.