IIS 7.0 : Managing Application Pools (part 2) – Managing Application Pool Identities

Managing Application Pool Identities

You can configure the identity under which worker processes in the application pool will run by assigning an account to the application pool. Application pool identity configuration is an important aspect of security in IIS 7.0, because it determines the identity of the worker process when the process is accessing resources. In IIS 5.0, the process runs under the LocalSystem account. That has significant security implications, because the user account has high access privileges. This changed in IIS 6.0 with the introduction of an application pool for which NetworkService is the default application pool identity. In IIS 7.0, the predefined worker process identities are the same as for IIS 6.0. Table 3 illustrates the built-in application identities in IIS 7.0.

Table 3. Built-In Application Pool Identities

LocalSystemLocalSystem is a built-in account that has administrative privileges on the server. It can access both local and remote resources. The account technically has access privileges similar to the system administrator account with unrestricted access to local resources. Application pools should never be assigned this identity. (If an application requires this identity, it indicates that the application is poorly designed, and you should strongly consider changing the application so that it does not require administrative privileges.)
LocalServiceThe LocalService account is a special built-in account that has reduced privileges similar to an authenticated local user account. It does not have network access privileges.
NetworkServiceNetworkService is a built-in account that has reduced privileges similar to an authenticated local user account. It can access remote resources as the machine account. This is the default account that IIS application pools use, and it has limited access to resources on local and remote computers.

On top of built-in accounts, you can create a custom user account to run the worker process in the context of the custom user account.

Security Account Changes in IIS 7.0

In IIS 7.0, both the anonymous user account (IUSR_computername) and IIS_WPG user groups have been removed and replaced by system built-in accounts rather than normal user and group accounts. Using a built-in predefined user Security Identifier (SID) ensures that the same common accounts exist in the remote IIS 7.0 computer. The built-in account initiative also eliminates the need to manage issues with user credentials, such as password expiration. The following built-in accounts are created during IIS 7.0 installation:

  • IUSR. The default user account for anonymous identity; replaces IUSR_computername account

  • IIS_IUSRS. New built-in user group; replaces the IIS_WPG user group


IUSR_computername is created if the FTP Publishing Service (the legacy IIS 6.0 FTP) role service is installed in Windows Server 2008.

On top of the security user and user group account changes, IIS 7.0 introduces two additional enhancements related to application pool identity:

  • Application Pool Identity as Anonymous Account. Designate the application pool identity as the anonymous user account. (Simply set the userName in the anonymousAuthentication configuration section to be blank. ) The main advantage of configuring application pool identity as the anonymous user is that you do not have to manage security for a separate account.

  • Automatic IIS_IUSRS Membership. In IIS 6.0, when you configure custom application pool identity, the custom account must be a member of IIS_WPG, because this user group has preconfigured access permissions and rights to start the worker process. Similar access permissions and rights have been granted to the IIS_IUSRS user group in IIS 7.0. However, the custom account does not need to be explicitly added to the IIS_IUSRS group, because this is done implicitly by IIS 7.0. (The application pool identity is not actually added to the IIS_IUSRS group. The group SID is injected into the worker process token at run time, so it acts as a member of IIS_IUSRS. No changes to the local user database or Microsoft Active Directory directory service domain group membership are made.)

    To revert to IIS 6.0 behavior, you can configure manual IIS_IUSRS group membership. This setting is per application pool, meaning that for the application pool with manual group membership, you will need to explicitly add the custom account to the IIS_IUSRS group. The following Appcmd syntax configures DefaultAppPool for manual IIS_IUSRS group membership.

    appcmd set apppool "DefaultAppPool" /processModel.manualGroupMembership:True

Direct from the Source: Using Application Pools to Sandbox Applications

The application pool is the fundamental unit of isolation for IIS applications, because it sandboxes the application code in a separate IIS worker process and allows sandboxing external access from resources within the process by applying access control lists (ACLs) to the application pool identity as well as granting or denying access to the application pool identity. Using application pools makes it possible to achieve a more thorough level of isolation between applications on the same server than is possible with any other technique, including impersonation or ASP.NET partial trust sandboxing.

IIS 7.0 goes further, enabling the application pool to be effectively used for isolation scenarios. It does this by automatically providing a unique account security identifier (SID) for each application pool so that the SID can be used in securing the resources with ACLs for that application pool. Windows Process Activation Service (also known as WAS) automatically creates this SID and therefore does not require you to create and use custom application pool identities. Moreover, IIS 7.0 also automatically isolates the global server configuration, by generating filtered copy of applicationHost.config configuration file for each application pool that contains only the configuration applicable to the application pool and does not retain configuration for other application pools such as their application pool definitions and identity information.

Combined with the increased worker process density, these improvements make it easier than before to create truly sandboxed application environments through the use of application pools.

Mike Volodarsky

IIS Core Program Manager

Configuring Application Pool Identity

Although NetworkService is an account with reduced access privileges, you might change the worker process identity due to your business needs. For example, a security application might require access to system resources for which NetworkService does not have the necessary permissions. In this case, you can run the worker process from a custom account with necessary access rights

To use IIS Manager to configure application pool identity, expand the IIS computer node in the Connections pane and navigate to the Application Pools node. In the Application Pools display pane, select the application pool for which you want to change the identity account. Then click Advanced Settings in the Actions pane. In the Process Model section of the Advanced Settings dialog box, select the Identity property and then click the browse button (…) to display the Application Pool Identity dialog box, shown in Figure 3.

Figure 3. Configuring application pool identity by using IIS Manager.


When changing the application pool identity, IIS 7.0 shuts down the current worker process if it is running and initiates a new worker process with the selected user identity. This impacts the availability of the application, and session details are lost during the application pool changes.

Use the following Appcmd syntax and the parameters shown in Table 4 to configure application pool identity.

appcmd set apppool ApppoolName /processModel.identityType:enum
/processModel.userName:string /processModel.password:string

Table 4. Syntax for Appcmd to Configure Application Pool Identity

ApppoolNameThis string represents the application pool name.
processModel.identityTypeThe identity type represents either built-in accounts such as LocalService, LocalSystem, NetworkService, or customer account as SpecificUser for the application pool.
processModel.userNameThe user account name for the custom application pool identity.
processModel.passwordThe user account password for the custom application pool identity.

The following example changes the default worker process identity from NetworkService to LocalService for the “Fabrikam Stock” application pool.

appcmd set apppool "Fabrikam Stock"

The identityType enumeration is case sensitive inside the configuration store. If you enter the correct value, Appcmd executes the command successfully and returns output like this.

APPPOOL object "Fabrikam Stock" changed

If you enter an incorrect value, you will see the following error messages.

ERROR ( message:Unknown attribute "identityType".. Reason: Enum must
be one of LocalSystem, LocalService, NetworkService, SpecificUser. )

To configure a custom application worker process identity, enter SpecificUser as the identityType attribute value. Then specify the user credentials by using the userName and password properties.

appcmd set apppool /apppool.name:"Fabrikam Stock"

The preceding example configures the MyAppUsr user account as the Fabrikam Stock application pool identity and specifies the account password as passw@rd1.

IIS updates changes in application pool identity in the <applicationPools> section in the applicationHost.config file. The element value includes the name of the application pool, the worker process model, and the process identity, if it is different from the default settings. The following shows the <applicationPools> configuration of the custom worker process identity configured for Fabrikam Stock application pool.

    <add name="Fabrikam Stock" managedRuntimeVersion="V1.1"
        <processModel identityType="SpecificUser" userName="MyAppUsr"