IIS 7 introduced the concept of the Application Pool Identity, but it was not used by default. This was changed in IIS 7.5, and it is a change I fully endorse. The Application Pool Identity is a special account that is created per application pool which adds additional process isolation between your application pools.

The tricky thing is granting permissions to this special account. The account has a fully qualified name of “IIS AppPool\ApplicationPoolName”. However I was unable to get this account to be added via the GUI. I needed to resort to the command line tool icacls, which has a grant syntax of:

icacls path /grant “IIS AppPool\ApplicationPoolName”:RX

This will add the user with “special permissions” for reading. After you do this, the account shows up in the GUI and you can go in and just check the standard boxes for read rights (Read & Execute, List Folder contents, Read). Once you check these boxes the special read permissions that were initially set are removed, and everything looks like it usually does.

For network access, the AppPoolIdentity accesses the network using the machine’s domain account which is DomainName\MachineName$. The article says that this is how NetworkService worked, and that this makes it easy to add ACLs by just granting them to the Machine Account. Maybe I am unnecessarily paranoid, but I would prefer to grant access to network resource on a per app pool basis, which most likely requires a separate domain account. However, since I do not need network access right now, I will proceed with the AppPool Identity and write a follow-up post when I need to go down the domain account path.

You can read more about the AppPool Identity here: http://learn.iis.net/page.aspx/624/application-pool-identities/