https://docs.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities

IIS Application Pool Identities

Securing Resources

Whenever a new application pool is created, the IIS management process creates a security identifier (SID) that represents the name of the application pool itself. For example, if you create an application pool with the name "MyNewAppPool," a security identifier with the name "MyNewAppPool" is created in the Windows Security system. From this point on, resources can be secured by using this identity. However, the identity is not a real user account; it will not show up as a user in the Windows User Management Console.

You can try this by selecting a file in Windows Explorer and adding the "DefaultAppPool" identity to the file's Access Control List (ACL).

1. Open Windows Explorer

2. Select a file or directory.

3. Right click the file and select Properties

4. Select the Security tab

5. Click the Edit button and then Add button

6. Click the Locations button and make sure that you select your computer.

   

7. Enter IIS AppPool\DefaultAppPool in the Enter the object names to select: text box.

8. Click the Check Names button and click OK.

By doing this, the file or directory you selected will now also allow the DefaultAppPool identity access.

You can do this via the command-line by using the ICACLS tool. The following example gives full access to the DefaultAppPool identity.

Console

ICACLS test.txt /grant "IIS AppPool\DefaultAppPool:F"

For more information, see ICACLS.

On Windows 7 and Windows Server 2008 R2, and later versions of Windows, the default is to run application pools as the application pool identity. To make this happen, a new identity type with the name "AppPoolIdentity" was introduced. If the "AppPoolIdentity" identity type is selected (the default on Windows 7 and Windows Server 2008 R2, and later), IIS will run worker processes as the application pool identity. With every other identity type, the security identifier will only be injected into the access token of the process. If the identifier is injected, content can still be ACLed for the ApplicationPoolIdentity, but the owner of the token is probably not unique. For more information about this concept, see the New in IIS 7 - App Pool Isolation blog post.

Accessing the Network

Using the Network Service account in a domain environment has a great benefit. Worker process running as Network Service access the network as the machine account. Machine accounts are generated when a machine is joined to a domain. They look like this:

XML

<domainname>\<machinename>$,

For example:

Console

mydomain\machine1$

The nice thing about this is that network resources like file shares or SQL Server databases can be ACLed to allow this machine account access.

What about Application Pool Identities?

The good news is that application pool identities also use the machine account to access network resources. No changes are required.