IIS Process Identities

[Previous] [Next]

The purpose of this section is to describe the identities Internet Information Services processes use when executing client requests. When IIS accepts a client request, it acts on behalf of a user account, as shown in Figure 5-29.

Figure 5-29. Steps involved when IIS processes a client request.

The core IIS process, InetInfo.exe, is a service that runs under the LocalSystem account, and it is this process that does the following:

1. Takes the client request
2. Impersonates the user
3. Performs the appropriate tasks
4. Finally, reverts to the process identity, which is LocalSystem

The entire process is shown in Figure 5-30.

Figure 5-30. A thread inside IIS running in a user context accessing a resource. All other threads are in the LocalSystem context waiting for work to arrive.

Protection Levels

Here's a twist, however: for robustness reasons, IIS can be configured to run parts of the Web site in a separate process, so if the process crashes it doesn't crash the InetInfo.exe process. The processes in question, called DllHost.exe, are controlled by COM+. In IIS 4, the processes were called Mtx.exe and were controlled by Microsoft Transaction Server.

When a request is received by the Web server, it looks into the configuration store to look at the Application Protection settings for that part of the Web site's address space. You can configure the protection level of a Web site or a Web application by doing the following:

1. Open the IIS tool.
2. Right-click the Web server or Web application in question.
3. Choose Properties from the context menu.
4. Click the Virtual Directory or Home Directory tab.
5. Choose the application protection level from the Application Protection drop-down list.

Figure 5-31 shows what the options look like.

Figure 5-31. Choosing an Application Protection setting in the IIS tool.

There are three levels of protection:

• Low (IIS Process)
• Medium (Pooled)
• High (Isolated)

The default for all new Web sites is Medium (Pooled). Let's look at each setting in detail.

Low (IIS Process)

This is the way IIS ran prior to IIS 4; all requests are performed in the InetInfo.exe process. This is the fastest option, but it is also the least robust because a rogue application could crash the InetInfo.exe process.

Medium (Pooled)

This is a new option in IIS 5 and is the default setting for all new Web applications. In this model, all parts of the Web space marked as Medium (Pooled) run in the same process external to InetInfo.exe. As already mentioned, the process name is DllHost.exe and this process does not run as LocalSystem as InetInfo.exe does. Instead, DllHost.exe runs under the identity of an account controlled by IIS. By default, the identity is IWAM_machinename.

When the request is received, IIS (using COM+) checks to see if a process is running to handle the medium protection Web applications. If not, COM+ starts the process and IIS offloads the work to the new process. If the process is already running, IIS simply passes the work to the process.

The net effect, as shown in Figure 5-32, is that in a default installation of IIS two processes run: InetInfo.exe, running as LocalSystem, and an instance of DllHost.exe, running as IWAM_machinename.

Figure 5-32. A thread inside IIS running in a user context accessing a resource, and a thread in an instance of DllHost.exe doing likewise.

This offers the best performance/robustness trade-off, because if a Web application crashes it might crash only the instance of DllHost.exe, not the InetInfo.exe process. However, all other Web applications running in the DllHost.exe process will stop functioning also. Nevertheless, when IIS receives a new client request, the Web server will automatically start a new instance of DllHost.exe.

High (Isolated)

This option, introduced in IIS 4 and shown in Figure 5-33, executes each Web application in its own instance of DllHost.exe that runs in the context of the IWAM_machinename account. In doing so, it offers the highest degree of robustness, but it's not as fast as Medium.

Figure 5-33. A thread inside IIS running in a user context accessing a resource, and a thread in two separate instances of DllHost.exe doing likewise.

Figure 5-34 shows a server running Windows 2000 and IIS with two instances of DllHost.exe running.

Figure 5-34. Two DllHost.exe processes executing.

Why Is the IWAM_machinename Account Needed?

As already discussed, IIS runs all Web applications marked as requiring Medium protection in one process named DllHost.exe. The process is created by COM+. Each Web application marked as requiring High protection runs in its own instance of DllHost.exe.

The processes are implemented as COM+ applications, and you can view these applications by using the Component Services tool as follows:

1. Click Programs on the Start menu.
2. Choose Component Services from the Administrative Tools menu.
3. Expand the Component Services node.
4. Expand the Computers node.
5. Expand the My Computer node.
6. Expand the COM+ Applications node.

You will see an application named IIS Out-Of-Process Pooled Applications. This is the COM+ application that will start when IIS processes any application marked for Medium protection. You'll also see a COM+ application for each Web application marked for High protection. The name of these COM+ applications is something like IIS-{Default Web Site//Root//HumanResources}. The first part of the name—in this case, Default Web Site—is the name of the Web site where the Web application resides, and the last part of the name—Root//HumanResources—is the name of the Web application. This is the application marked to run with High protection.

As you've probably determined by now, these COM+ application settings are created ahead of time when you create the Web application in the IIS tool, because COM+ must know the identity of the application ahead of time. You can verify this by performing these steps on the COM+ application in question:

1. Right-click the COM+ application—for example, IIS Out-Of-Process Pooled Applications.
2. Choose Properties from the context menu.
3. Click the Identity tab.

You'll see something like what's shown in Figure 5-35. As you can see, the process is marked to start under the IWAM_machinename account; this is set automatically by the IIS tool when the application is created.

Figure 5-35. COM+ application identity for Medium protection Web Applications.

Changing the startup account

Using the COM+ Component Services tool, you can change the startup account of an IIS/COM+ application to another account. For example, you might want to run the application as This User—take another look at Figure 5-35—for debugging purposes.

However, there is a caveat. If you want to set the user account back to IWAM_machinename, you probably don't know the account's password, and failure to enter the correct password will result in failed Web requests. When this happens, the following two events are written to the system event log:

 Event ID: 10004 Source: DCOM Error: DCOM got error "Logon failure: unknown user name or  bad password." and was unable to logon. Event ID: 36 Source: W3SVC Error: The server failed to load application '/LM/W3SVC/1/Root/ HumanResources'. The error was 'The server  process could not be started because the configured identity is  incorrect.  Check the username and password.' 

To correct this problem, run the SyncIwam.vbs utility in the InetPub/AdminScripts directory.

Protection Levels, ISAPI Applications, and ISAPI Filters

The Internet Server Application Programming Interface (ISAPI) is an API for writing high-performance applications in C or C++ for Web servers, including IIS.

ISAPI applications

ISAPI applications, also called ISAPI extensions, are implemented as DLLs and operate in a similar fashion to a CGI script: the Web server loads the file, the file performs its function, and the file then returns control to the Web server.

ISAPI applications run in the same security context as the impersonated user account and obey the same protection rules discussed earlier. Therefore, a Web application marked to run with High protection and using an ISAPI application will run the ISAPI application in a DllHost.exe process. The process will, by default, run as IWAM_machinename.

ISAPI filters

ISAPI filters, also implemented as DLLs, run in the InetInfo.exe process and respond to events such as authentication requests and logging events. ISAPI filters allow the Web developer to preprocess user requests and postprocess server responses. Because they run in the InetInfo.exe process, ISAPI filters always run in the same security context as the Web server, LocalSystem.

Protection Levels, Impersonation, and RevertToSelf

When a process starts in Windows 2000, it does so in a specific security context. For example, all default DllHost.exe processes run as IWAM_machinename and the InetInfo.exe process runs as LocalSystem.

A process can contain multiple threads, each of which will also be running in the same security context. When a client request is processed, IIS impersonates the client before performing the work; this involves changing the thread context from IWAM_machinename or LocalSystem to the user context. Once the work is completed, the thread drops back to the process context—in other words, IWAM_machinename or LocalSystem. This process is called reverting to self.

Some Web developers perform a dangerous trick, which we strongly discourage. When their Web application processes a client request, they call a function called RevertToSelf. At that point, the thread handling the client request is no longer impersonating the user. It is running as the identity of the process, and if the Web application is running with low protection it will revert to the InetInfo.exe identity, LocalSystem. Because this account is a highly privileged account, any security mistakes made while running in the LocalSystem context can be very serious indeed.

Calling RevertToSelf from a Medium or High protection Web application will revert to the IWAM_machinename account.

WARNING

---

Do not rely on being able to revert to the LocalSystem context. Microsoft has stated that it intends to remove this side effect in a future version of the Web server.