Update: The original question was for Windows Server 2008, but the solution is easier for Windows Server 2008 R2 and Windows Server 2012 (and Windows 7 and 8). You can add the user through the NTFS UI by typing it in directly. The name is in the format of IIS APPPOOL\{app pool name}. For example: IIS APPPOOL\DefaultAppPool.
IIS APPPOOL\{app pool name}
Note: Per comments below, there are two things to be aware of:
- Enter the string directly into the "Select User or Group" and not in the search field.
- In a domain environment you need to set the Location to your local computer first.
Reference to Microsoft Docs article: Application Pool Identities > Securing Resources
Original response: (for Windows Server 2008) This is a great feature, but as you mentioned it's not fully implemented yet. You can add the app pool identity from the command prompt with something like icacls, then you can manage it from the GUI. For example, run something like this from the command prompt:
icacls c:\inetpub\wwwroot /grant "IIS APPPOOL\DefaultAppPool":(OI)(CI)(RX)
Then, in Windows Explorer, go to the wwwroot folder and edit the security permissions. You will see what looks like a group (the group icon) called DefaultAppPool. You can now edit the permissions.
However, you don't need to use this at all. It's a bonus that you can use if you want. You can use the old way of creating a custom user per app pool and assigning the custom user to disk. That has full UI support.
This SID injection method is nice because it allows you to use a single user but fully isolate each site from each other without having to create unique users for each app pool. Pretty impressive, and it will be even better with UI support.
Note: If you are unable to find the application pool user, check to see if the Windows service called Application Host Helper Service is running. It's the service that maps application pool users to Windows accounts.
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-identity, what I call the App Pool Account to avoid ambiguity):
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 2008 R2 or later 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
- a virtual identity, IIS AppPools\AppPoolName will be made available for use as a security principal on the local machine
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 this post).
Best Answer
The IIS_Anonymous account is the the account that the user accessing the site runs as. So you want to make sure that this user can't access any files outside of the web root and files with sensitive information IE sql connection strings etc. You generally don't want to allow this user write access anywhere.
The App pool account is the account your app (or the IIS server) runs under. You want to give this account the bare minimum access it needs to run your script. If you are security conscious you will create different app pools for each site, so that a security misconfiguration on one site will not leak to another.