What are all the user accounts for IIS/ASP.NET and how do they differ?

Question

Under Windows Server 2008 with ASP.NET 4.0 installed there is a whole slew of related user accounts, and I can't understand which one is which, how to they differ, and which one is REALLY the one that my app runs under. Here's a list:

• IIS_IUSRS
• IUSR
• DefaultAppPool
• ASP.NET v4.0
• NETWORK_SERVICE
• LOCAL SERVICE.

What is what?

Ambitendency

And using Windows Server 2012 with ASP.NET 4.0 or above ? – Candlefish

Answer 1

^{This is a very good question and sadly many developers don't ask enough questions about IIS/ASP.NET security in the context of being a web developer and setting up IIS. So here goes....}

To cover the identities listed:

IIS_IUSRS:

This is analogous to the old IIS6 IIS_WPG group. It's a built-in group with its security configured such that any member of this group can act as an application pool identity.

IUSR:

This account is analogous to the old IUSR_<MACHINE_NAME> local account that was the default anonymous user for IIS5 and IIS6 websites (i.e. the one configured via the Directory Security tab of a site's properties).

For more information about IIS_IUSRS and IUSR see:

Understanding Built-In User and Group Accounts in IIS 7

DefaultAppPool:

If an application pool is configured to run using the Application Pool Identity feature then a "synthesised" account called IIS AppPool\<pool name> will be created on the fly to used as the pool identity. In this case there will be a synthesised account called IIS AppPool\DefaultAppPool created for the life time of the pool. If you delete the pool then this account will no longer exist. When applying permissions to files and folders these must be added using IIS AppPool\<pool name>. You also won't see these pool accounts in your computers User Manager. See the following for more information:

Application Pool Identities

ASP.NET v4.0: -

This will be the Application Pool Identity for the ASP.NET v4.0 Application Pool. See DefaultAppPool above.

NETWORK SERVICE: -

The NETWORK SERVICE account is a built-in identity introduced on Windows 2003. NETWORK SERVICE is a low privileged account under which you can run your application pools and websites. A website running in a Windows 2003 pool can still impersonate the site's anonymous account (IUSR_ or whatever you configured as the anonymous identity).

In ASP.NET prior to Windows 2008 you could have ASP.NET execute requests under the Application Pool account (usually NETWORK SERVICE). Alternatively you could configure ASP.NET to impersonate the site's anonymous account via the <identity impersonate="true" /> setting in web.config file locally (if that setting is locked then it would need to be done by an admin in the machine.config file).

Setting <identity impersonate="true"> is common in shared hosting environments where shared application pools are used (in conjunction with partial trust settings to prevent unwinding of the impersonated account).

In IIS7.x/ASP.NET impersonation control is now configured via the Authentication configuration feature of a site. So you can configure to run as the pool identity, IUSR or a specific custom anonymous account.

LOCAL SERVICE:

The LOCAL SERVICE account is a built-in account used by the service control manager. It has a minimum set of privileges on the local computer. It has a fairly limited scope of use:

LocalService Account

LOCAL SYSTEM:

You didn't ask about this one but I'm adding for completeness. This is a local built-in account. It has fairly extensive privileges and trust. You should never configure a website or application pool to run under this identity.

LocalSystem Account

In Practice:

In practice the preferred approach to securing a website (if the site gets its own application pool - which is the default for a new site in IIS7's MMC) is to run under Application Pool Identity. This means setting the site's Identity in its Application Pool's Advanced Settings to Application Pool Identity:

In the website you should then configure the Authentication feature:

Right click and edit the Anonymous Authentication entry:

Ensure that "Application pool identity" is selected:

When you come to apply file and folder permissions you grant the Application Pool identity whatever rights are required. For example if you are granting the application pool identity for the ASP.NET v4.0 pool permissions then you can either do this via Explorer:

Click the "Check Names" button:

Or you can do this using the ICACLS.EXE utility:

icacls c:\wwwroot\mysite /grant "IIS AppPool\ASP.NET v4.0":(CI)(OI)(M)

...or...if you site's application pool is called BobsCatPicBlogthen:

icacls c:\wwwroot\mysite /grant "IIS AppPool\BobsCatPicBlog":(CI)(OI)(M)

Update:

I just bumped into this excellent answer from 2009 which contains a bunch of useful information, well worth a read:

Apophthegm

don't agree in using same user for anonimous authentication and app pool identity... if you need to give to apppoolidentity write permission to a folder.... – Raye

@Raye - why not? Unless you have a special case, using application pool identities is the most secure approach provided each site is in its own application pool. Hate to do the "appeal to authority" but been a shared web host engineer and security guy for 15 years, this approach is a no-brainer on IIS7+. – Apophthegm

@Apophthegm simply i don't like to give write permission on a site to the anonymous user – Raye

Your application pools can be even more specific by using IIS AppPool\<name_of_apppool>. On a related note, IIS Express will only work with IIS AppPool\ASP.NET v4.0 because the app pool virtual accounts are not created. – Pyrex

@daub815 - IIS Express works differently because it was intended to run under your Windows login and startup and shut down as needed when developing and debugging. In reality it doesn't actually use or have any dependency on Full Fat IIS application pools or infrastructure. The intent of IIS Express was to give developers as much of the same behaviour, flavour and config as the real thing because VS's toy web server was severely limited... – Apophthegm

@daub815 - i.e. it doesn't know how to parse <system.webServer> and other IIS specific config; the result being that you never know if your stuff will work on IIS when you deploy. The problem with debugging in VS + Full Fat IIS is that it takes a reasonable amount of knowledge to get that working. Sure in an ideal world developers should know how to get that working, but many just want to write code and push to some hosted environment already managed for them. – Apophthegm

@daub815 - All of the answer is intended to be read with Full Fat IIS in mind, not IIS Express. You can actually get IIS Express to run different framework versions, you can even run PHP and Classic ASP (https://mcmap.net/q/100899/-how-to-run-php-on-iis7-5-express), but you need to dip into the command line and tweak its own app host config files....but that's a whole other topic. – Apophthegm

@Apophthegm Understood. But I wanted to add to this answer, so that if someone else was working with IIS Express and comes across this answer, they can get some help without me needing to post another question/answer. – Pyrex