Windows Server 2008 R2–how give a WCF service write permission to folder

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).

Using the AppPool Identity for a remote SQL server essentially means you're giving the AD computer account for the web server access to the SQL database. Because of that, anything else running on the web server in the context of the computer account also has access to the SQL server. You could do a lot worse in terms of security, but an explicitly defined domain account is definitely better since you can make sure the only code using it is your web site.

If managing a domain based account (and its requisite password) is too much hassle and your web server is running on 2008 R2 or Win7, you might be able to use a Managed Service Account which basically gives you the manageability benefits of the AppPool Identity with the security of a domain account.

I haven't personally gotten the chance to play with managed service accounts yet. So I'm not sure if the TechNet documentation has any gaps or caveats. But it's worth a shot if you've got the time and your environment meets all the requirements. They definitely won't work on your IIS6 box though.