Worker Processes
IIS protocol listeners forward client requests to the associated Web site's worker process. In IIS 7.0, Windows Activation Service (WAS) manages application pool configuration and worker processes instead of WWW Service. The worker process is user mode-based code that does the actual handling, delivery, and response to the incoming request for a particular Web site. For example, a worker process may retrieve HTTP content and send it to the requesting client, call an ISAPI filter to handle a particular type of request, or run a scripting engine.
Application Pools
Each Web site runs in an application pool, which is a named worker process and logical memory allocation where one or more Web sites or applications reside. Application pools can be shared by Web sites and applications or used to isolate sites and applications from each other .
When IIS 7 is installed, two application pools, called the DefaultAppPool and Classic .NET AppPool, are created (see Figure 1). IIS 6 did not have the latter application pool, but Classic .NET AppPool behaves in the same way as IIS 6's DefaultAppPool. Application pools can be configured to run with or without (i.e., no managed code) .NET Framework (see Figure 2). The Managed pipeline mode refers to whether the developer wants ASP.NET and non-ASP.NET requests to be processed together (i.e., Integrated), which is a new IIS 7 feature, or separately (i.e., Classic) using Aspnet_isapi.dll for the ASP.NET requests.
Additional application pools can easily be created, and each Web site and directory can belong to one or more application pools. Additional application pools can be created in IIS Manager by clicking the Add Application Pools option under Application Pools leaf object. Additional application pools can also be created using the command line as well. Here is the command and syntax:
appcmd add apppool /name:string /managedRuntimeVersion:.string 
/managedPipelineMode: Integrated | Classic
Placing different Web sites in different application pools isolates what corruption or damage can be done by one site to another. A web server administrator can run high-risk applications in their own application pool, separate from the main Web site. If a malicious action happens to a Web site in one application pool, the vulnerability does not immediately compromise Web sites in other application pools.
| Note |
When discussing how IIS works, application pools are often discussed as if they are the same as worker processes, even though they are not one and the same.
|
In IIS 7's default mode (called worker process isolation) there is a separate worker process for each application pool. Each runs in the W3wp.exe process, which runs in the Network Service security context by default. In previous IIS versions (or a Web site running in IIS 5 isolation mode), Dllhost.exe is the default single instance worker process for all Web sites. Applications and Web sites running in Low Application Protection mode (for example, ASP) use the Inetinfo.exe worker process, which as stated previously, runs in the Local System security context. This means that in previous versions of IIS, a single compromise could allow easy access to all Web sites on the server.
| Note |
The W3wp.exe process will not launch until a Web site on the web server is first accessed.
|
| Note |
In Vista, just as in previous Windows versions, Dllhost.exe can also be used by other applications, many of which are unaffiliated with IIS, so don't be surprised if you see it as an active process in memory.
|
Application Pool Identities
Each worker process and associated application pool runs in the security context of an application pool identity. The identity is a user or service account used to run the worker process and application pool (i.e., the security context that the worker process and application pool run in). The default identity for both default application pools is Network Service.
Introduced in XP Pro, the Network Service account has permissions similar to the Authenticated Users group, but accesses network resources using the web server's computer account. The Network Service account has the following privileges:
-
Replace a process-level token
-
Adjust memory quotas for a process
-
Generate security audits
-
Bypass traverse checking
-
Access this computer from the network
-
Logon as a batch job
-
Logon as a service
-
Impersonate a client after authentication
You can choose the more secure Local Service account if your application pool does not need to access other network services or computers. The Local Service account, also introduced in XP Pro, has permissions similar to the Authenticated Users group, but accesses any network resources using an anonymous null session because it does not have the "Impersonate a client after authentication" privilege. In XP Pro and above, network resources cannot be accessed using a null session, except to domain controllers. The Local Service account has the following privileges:
-
Replace a process-level token
-
Adjust memory quotas for a process
-
Generate security audits
-
Bypass traverse checking
-
Access this computer from the network
-
Logon as a batch job
If a Web site doesn't need access to other network resources (i.e., besides the normal remote requesting clients), the Web site administrator can change the worker process identity to Local Service.
You can create or use a custom user or service account (i.e., Specific User) for the application pool identity (see Figure 3). The pool will then have access only to the resources and permissions of the custom identity account. If you create a custom identity account, add it to the IIS_IUSRS group, which assigns the necessary permissions and privileges to allow the account to function as an IIS application pool identity. You then need to add the other NTFS file and folder permissions to the resources used by the web application.
You can also choose the LocalSystem account for the identity if the application pool needs Administrator-level privileges and permissions. This is not recommended unless absolutely needed. If a hacker is successful in compromising a web application running in an application pool with the LocalSystem identity, he or she has far more potential to be damaging than if the application pool ran under Local Service or Network Service.
| Note |
In IIS 6, any application pool identity had to be added to a group called IIS_WPG to get the correct permissions. This group and requirement has been replaced by IIS IUSRS, although the previous group may still appear.
|
If the Web site using a custom application pool identity is also involved in delegation to another back-end server (for example, IIS front end authenticating users for an MS-SQL back-end database), a Service Principal Name (SPN) must be created for the custom identity. Specifically, the administrator can use Microsoft's SetSPN.exe utility (http://www.technet2.microsoft.com/WindowsServer/en/library/1033.mspx) to create the new SPN. The syntax would be similar to this for a Web site located at http://www.example.com using a custom user identity called custom in a domain called Contoso:
setspn.exe -A HTTP/www.example.com contoso\custom
