Sdílet prostřednictvím

IUSR vs Application Pool Identity – Why use either?

  • Článek

(pasted from my email clippings. I’m on holiday right now, catching up on paperwork!)

The TLDR version is: using AppPoolIdentity as both the App Pool Account and Anonymous user account lets you have multiple isolated anonymous websites on one box.

IIS 7.x and upwards (as of Win2008 R2 and Windows 2008 SP2, also in IIS 8.x in Windows Server 2012 and IIS 10.x in Windows Server 2016) supports a new Application Pool account type, called an ApplicationPoolIdentity. This low-privileged account can be used to isolate distinct sets of anonymous website content, without requiring the administrator to set up a unique account for each website manually.

So whereas the default IUSR anonymous account is per-server, an ApplicationPoolIdentity is per-app-pool, and IIS creates one app pool per site, by default when the GUI is used to create a site.

So by setting the ApplicationPoolIdentity as the anonymous user account for a site, you can isolate content and configuration for that site so that no other sites on the same box can access it, even if it's an anonymous site.

And now, the long version!

 

Before I start: Terminology disambiguation corner (because App Pool Identity is a horribly overloaded term nowadays):

  • Application Pool Account = the account used to run the App Pool, whether custom user, NetworkService, LocalService, AppPoolIdentity or LocalSystem
  • ApplicationPoolIdentity = the new account type that has a unique App Pool Name-based identity SID (S-1-5-82-SHA1{App Pool Name})

Also, a reminder that process identity is the basic "RevertToSelf" identity for a process, and that thread identity can be different from process identity via impersonation or explicit logon.

So, any or all of the threads in a process might be someone other than the process identity, but if any call RevertToSelf or somehow lose their token, they’ll snap back to acting as the process identity. (Which is the ultra-short version of why you don’t want that being LocalSystem or another privileged account.)

 

App Pool Account:

The when-not-impersonating/process identity; used to start the app pool and to read web.config files; pretty much needs permissions to everything.

On IUSR vs Application Pool Account as anonymous:

IUSR

  • IUSR has the same SID on every machine.
  • IUSR is appropriate if you run one anonymous website on the computer.
  • You secure your content to IUSR with NTFS permissions, and that website can access it.
  • If you run two websites with the anonymous account as IUSR, they can access each other's content.
  • For low-security applications and intranet sites, that might be OK.

App Pool Account as Anonymous

The alternative is to use an App Pool Account as the Anonymous account (so a thread doesn't bother putting on its IUSR clothes on anonymous requests)

  • ApplicationPoolIdentity has the same SID on every machine with a common config (because the SID is a hash of the name), so has the same benefit as IUSR for content security, only specific to the app.
  • It's an appropriate choice if you run multiple anonymous websites and need isolation of content.
  • Other appropriate choice: creating an explicit user account for each App Pool and using that as anonymous.
  • (i.e. the anonymous Coke application should never be able to read the Pepsi application's files) (arguably always the case with multiple anon websites on the one box)

Using the App Pool Account as anonymous is a good idea because it allows you to secure your content at the NTFS level for just COMPUTER\Coke or IIS AppPool\Pepsi, and be assured that Windows file system security will prevent one company's anonymous app from reading (or otherwise affecting) its competitor's anonymous content.

Using the AppPoolIdentity as the App Pool Account in this case is just a simple, no-hassle way of having a common user account on all machines that share the IIS configuration (or at least the name of the app pool), without having to faff about creating or replicating Windows users and worrying about their permission level.

The bit I'm less confident on but still fairly sure I'm right:

When it gets to off-box (eg database) resources, you're out of IIS-land and into app framework (ASP.Net)-land; short version is that if your token isn't delegable (for eg, comes from an NTLM auth), it'll fail to be passed to the next hop, and you'll end up with process identity and any limitations/benefits it incurs.

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed
    • Anonymous
      November 01, 2016
      Hi Tristan, I have a question..I have a desktop application in Server A, and I have a web application on Server B (same domain), my desktop application on Server A deploy files to web application on server B, for this purpose I have to share a folder on Server B, the doubt is: I can't use an App Pool Identity right? I would need to use a custom domain account that can access the shared folder?
      • Anonymous
        November 03, 2016
        No, you'd be OK, at least as far as what you've described goes. The desktop application just puts the content in the folder on either.
  • Anonymous
    December 26, 2014
    So the question is can I use a custom pool account instead of default ApplicationPoolIdentity?
  • Anonymous
    August 12, 2016
    duck
  • Anonymous
    June 06, 2017
    And what would these look like in applicationHost.config?I see:-Using ApplicationPoolIdentity -Using IUSR: Correct???