User rights needed for IIS 7.5 application pool user (domain user, not the AppPoolIdentity)

We have an active directory domain (let's call it foodomain) and a domain user account (foodomain\fooAppPoolUser) used for the IIS application pool identity.

We want to run the app pool under this user account and not under Network Service or the new AppPoolIdentity as we have to access SQL server and have multiple applications on IIS (with own app pools) accessing different databases.

The problem is that I can't find a clear HOW-TO explaining, which user rights have to be set for this user account and how IIS has to be setup so that this will work.

First I got errors (unfortunately I can't remember which ones), then I added fooAppPoolUser to the local admin group (Administrators, I know, was only to test), then it worked. Now I removed the user again, restarted IIS and it still works.

So I'm confused a bit and would like to know, how the configuration/setup has to be to have it working.

Somwhere I read, that the account needs to have the "Impersonate a client after authentication" user right. That's the reason I added the account to the Admin group (the user rights assignment is blocked via group policy, but this can for sure be changed if really needed.

I hope I was clear enough what the question is and hope somebody has an answer.

It's frustrating that this information is so hard to find, since some security admins seem to enjoy the cruel and unusual punishment of changing default policy settings to thwart installing apps within IIS.

Here's what I believe you should do to enable an account to work as an ApplicationPool identity:

• Run aspnet_regiis -ga DOMAIN\USER to add permissions to access the IIS Metabase. (Exactly what that means, who knows?) aspnet_regiis reference
• Add the user to the IIS_IUSRS group. This may be done automatically depending on the IIS configuration setting processmodel.manualGroupMembership but easiest to add it yourself.
• If security policy is using windows defaults that's about it. If the security policy is locked down you may need to enable specific user rights for the account. The ones you have by default for ApplicationPoolIdentities (which seems a good place to start but not necessarily all required):
  • Access this computer from the network
  • Adjust memory quotas for a process
  • Allow log on locally
  • Bypass traverse checking
  • Generate security audit details
  • Impersonate a client after authentication - (Often not available by default on locked-down environments)
  • Log on as a batch job - (Often not available by default on locked-down environments)
  • Log on as a service - (I'm not sure this is needed)
  • Replace a process level token
• If you're using windows auth and Kerberos (provider=Negotiate) then depending on the URL and if kernel-mode auth is on you might need to set up an SPN. I suggest switching to NTLM if possible. Otherwise, see articles below about SPNs and find a friendly domain admin to add them for you.

Fun reading:

• Default permissions and user rights for IIS 7.0, 7.5, 8.0. This is the best reference, see the user rights at the bottom.
• User Rights (on Windows Server 2008, but still interesting and helpful as it's a long article you can CTRL+F to find IIS-related comments)
• User Rights Assignment on Server 2008 R2+. You have to drill into each right to see what it mentions about IIS.
• How To: Create a Service Account for an ASP.NET 2.0 Application - pity there's no more recent version of this article.
• SPN Checklist for Kerberos on IIS7/7.5
• How to use SPNs - applies to IIS6 or to 7/8 if Kernel-mode authentication is turned off.