How does IIS7 authorization work when setting up an application outside of wwwroot

Question

I tried to add a new application in II7 and point it to another directory on my hard drive outside of wwwroot. I have it under the default app pool and connecting as an application user. The application contains simple static html pages not asp.net and this is my development server and will only be used for just that.

When I try to access the application it throws an error. I did a bit of research on this and the advice I got was to add NETWORK SERVICE to the physical path of the application. This did not work. I then did some more research and instead of using NETWORK SERVICE I added ISUR. This worked.

Out of this I drew two vague conclusions:

• NETWORK SERVICE is used for asp.net applications
• IUSR is used for static html pages

Can someone please confirm this.

• Is it then safe to say that if my asp.net applications contains html files I would need to add both accounts to my physical path to make it run correctly?
• It also sounds to me that since this a development machine it is probably easier to just connect as and use the account I am logged in with on Windows. Am I right?
• Finally, if I would have addded my test application in a folder under wwwroot instead, would everything have worked since wwwroot and its folders are already setup with the correct privileges for static html and asp.net?

Thank you for all your help.

P.S. any blogs on how to get up to speed with IIS7 would be highly appreciated.

Answer 1

It is a little bit more complicated than that.

The calls to static HTML pages go through IIS

• If IIS authentication is anonymous it will be IUSR that accesses the file
• If IIS authentication is windows it will be the windows identity of the request that is used

The calls to ASP.net pages go first through IIS then to the ASP.net process

• The default identity of the application pool is NETWORK USER, that is why the call is made by NETWORK user in your case.
• The identity of the app pool could be configured to be a different user
• The web config could be configured to impersonate the calling user

There are a lot of possible combinations this, many more than I have covered here. But basically you must look at:

• The identity of the user accessing the site
• The configuration of IIS
• The configuration of the application pool
• The configuration of web.config