What role does "App Pool Identity" play for an Application Pool?
Solution 1:
Lots of overloaded terms here, and a change between IIS 7 and 7.5.
App Pool Identity vs App Pool Account
Let's start with the Application Pool identity (lowercase I, aka App Pool Account):
The way I tell it, the Application Pool Account is the account used to boot an App Pool, and the identity that the App Pool assumes when it's not impersonating anyone else.
So whatever identity you give the App Pool, it's going to need to be able to read the files in the content folder: particularly {but not limited to} any web.config files (which form part of the IIS configuration, and control what the App Pool is going to be doing).
If it can't access a folder, it'll assume there might be an important (game-changing) web.config file in there, and display an error. So the App Pool Account needs Read access to all content folders.
ApplicationPoolIdentity
Why differentiate the App Pool Account (the identity of the app pool) from the App Pool Identity? Because the special-capitals-used ApplicationPoolIdentity is a new account type - a managed service account - introduced and made default in IIS 7.5 / Windows 2008 R2, and available from Windows 2008 SP2 as well (but not the default).
See Application Pool Identities on IIS.Net
When you create a website under R2 using the GUI:
- an App Pool will be created to host that website, and
- the account type will be ApplicationPoolIdentity, instead of Network Service (the 2008 default), Local Service or Local System.
With 2008 RTM, the default App Pool account was Network Service plus a unique app pool identity/uniquifier; the new R2/SP2 AppPoolIdentity account type is a Network-Service-like account (i.e. is the computer when connecting off-box), but prevents impersonation of another App Pool within the same box.
Back to the original question:
App pool account defines who your app runs as when it's not impersonating anyone else
Authentication method describes how you're going to authenticate the clients (in order to impersonate them)
The Anonymous user account defines who you're going to run as when impersonating a user for a request which isn't authenticated - IUSR is such a user.
Incidentally, with IIS 7.5, you can set the Anonymous user account to be the Application Pool Identity (properties of the Anonymous authentication method), which might make it more straightforward to isolate and secure the content for a given website.
Set permissions using IIS AppPool\YourSiteName for the name format. (see also this post)
Solution 2:
You are seeing two things, that are commonly confused in ASP.NET:
- "user identity" - Authentication of a user account has nothing to do with the account or identity that actually runs under both IIs and ASP.NET. Anonymous authentication allows any user to access any public content without providing a user name and password challenge to the client browser. The anonymous IUSR account that gets authenticated by default in IIS just applies access to public website content. It doesn't affect the processes or resources used by the underlying IIs or ASP.NET services.
- "application identity" - This is the actual "WindowsIdentity" account on the server that actually runs behind IIS and ASP.NET, which is the Application Pool Identity account assigned to the pool by IIs and given to ASP.NET. Your ASP.NET process runs under this Application Pool Identity account (called a virtual account in IIs version 7.5+) by default.
Explanation: First, "authentication" in ASP.NET is just an event usually setup in the web.config that logs in a given user account which gets passed as a user token by IIs to ASP.NET as a plain HttpContext object... i.e. the current session or context of the current user. It doesn't actually change the WindowsIdentity that's running the ASP.NET process, just passes a user id token to it. Using HttpContext, your code can use that id or name to store database rights to various sections of your website. But it wont affect file access by ASP.NET because it does not affect or change the identity of the actual application "process" account that runs ASP.NET under IIs.
That doesn't happen until you do "Impersonation" which tells ASP.NET to impersonate whatever token gets passed to it by IIs and to then run under that account id. You can set impersonation in your web.config. When you activate impersonation in ASP.NET then the WindowsIdentity does change on the worker process to whatever authenticated account gets passed to ASP.NET from IIS, and you can then access files, based of course on what rights you assign that user account. Its important to note when that occurs its temporary and ASP.NET can revert back to its default process identity which is in current IIs versions again the Application Pool Identity account assigned to a given App Pool.
When IIs just uses the plain anonymous user account with no explicit authentication set in ASP.NET, IIs starts up by default the website's assigned Application Pool's Application Pool Identity account and passes it to ASP.NET and the worker process running it. That Application Pool identity account processes all requests for IIS and runs ASP.NET for that site.
When IIs starts under this setup and is accessed by a user, it actually authenticates behind the scenes by default the anonymous IUSR account which determines access to web pages and other basic resources. But that account is NOT passed to ASP.NET. And it doesnt affect the Application Pool Identity IIS runs and which ASP.NET runs under.
If you set Impersonate to "true" in say your web.config, AND you are using the default anonymous IUSR account in IIs for public access, AND you set to true explicitly the anonymousAuthentication property in the web.config (instead of using a Windows or other login account), IIs will toss out the Application Pool Identity and IIs and ASP.NET will both now run their application processes as the anonymous IUSR authenticated and impersonated account.
When you do that ASP.NET and its processes will now be running under the IUSR account .... i.e. the applications process of ASP.NET will run its WindowsIdentity account as the IUSR account. You can now apply read/write access to that anonymous IUSR account and to the folders you want that account to access. (Note: be sure however to add the default process account, the Application Pool account for the pool, rights as well to those folders. That is according to Microsoft's recommendation)
Good Luck!
Solution 3:
There are two authentication contexts at play. The web server process (that handles your web requests) runs as the App Pool Identity user. When a request comes in for your virtual host, the application pool impersonates the user listed in the specific site's "Anonymous Authentication Credentials" - by default IUSR.
Any scripts run from within your website will run as IUSR, but logging and certain other functions will run as the App Pool User (by default Network Service - although this has been changed recently to use a special virtual app pool user). The App Pool Identity (Network Service) needs to be able to list the files in your directory as certain checks are done in the request stack before control is handed off to your script.
It is good practice to run one site per pool, and set the App Pool Identity to run as the same user as your website's Anonymous user. It is possible to break out of the Anonymous User context (IUSR) and elevate privileges to those of the App Pool Identity itself.