Architecture

As you have seen, applications can contain code that sometimes generates errors such as memory leaks, access violations, and many others. An error generated in one Web application can bring a whole Web server down, and thereby affect more sites than the one the error occurred in. The processes hosting the applications need to be active managers of the runtime environment to catch these errors in time to take actions that minimize the effect they have on other applications. If the hosting process also is fault tolerant, and has the ability to restart processes and queue requests in the meantime, users of the application might not even notice the error. To provide all this, IIS 6.0 includes a new application isolation environment with active process management. This is named worker process isolation mode, but before we take a closer look at this, we will show you how the IIS 6.0 request processing architecture works.

The Inetinfo process was the main Web server process in IIS 5.0 that let dllhost.exe handle requests to out-of-process applications. In IIS 6.0, the architecture presents a new kernel mode driver that two components, also new, use. These new components are HTTP.SYS, which is a kernel-mode HTTP listener, and the WWW Service Administration and Monitoring Component, which is a user-mode configuration and process manager.

Note

All Web application processing done by the Iisw3adm.dll, which is the WWW Service, is loaded into one or more host processes called worker processes. The worker process executable is w3wp.exe. An application pool corresponds to one request queue within HTTP.SYS and one or more worker processes. The application pool is a collection of one or more Web applications or sites.

HTTP.SYS listens for requests and sends them to the appropriate application pool queue. No third-party code runs in HTTP.SYS, which provides for high fault tolerance, since failures in user-mode code cannot affect it. If an error occurs that terminates the user-mode request processing, HTTP.SYS continues to accept and queue requests because the only thing affected is the worker process. This means that the WWW Service is still running. When WWW Service notices the failed worker process, it automatically starts a new one as long as there are requests left in the queue. Since the requests are still accepted, an end user should experience minimum disruption to the service. However, HTTP.SYS cannot queue requests forever. Three conditions stop it from accepting requests:

• No queues are available.

• No space is left on the queue.

• The Web service has been shut down.

The WWW Service Administration and Monitoring Component is responsible for configuration and process management. When initialization of the service occurs, metabase information is read, and the HTTP.SYS namespace routing table is initialized with one entry for each application. The routing table maps a URL to a specific application pool. This way HTTP.SYS knows there is an application pool that will respond to requests for a specific namespace. First after this mapping, it can request the start of a worker process for an application pool when there is demand for it.

The WWW Service Administration and Monitoring Component is also responsible for controlling the lifetime of the worker processes. In this role it determines the following:

• When to start a worker process

• When to recycle a worker process

• When to restart a worker process

Let us now take a closer look at the worker process isolation mode. As you saw earlier in the chapter, a performance penalty is incurred for running applications in isolation mode with IIS 5.0 and earlier versions. This is no longer true with IIS 6.0.

After an HTTP request has been routed to the correct application pool queue, the worker process pulls the request from HTTP.SYS. This eliminates the overhead of sending a request to an out-of-process DLL host and back again.

Figure 7-11 presents an overview of IIS 6.0 running in worker process isolation mode.

Here is what really happens when a new request arrives at HTTP.SYS:

1. The new request arrives at HTTP.SYS.

2. HTTP.SYS decides if the request is valid.

3. If the request is invalid, code for the invalid request is sent back to the client.

4. If it is valid, a check is made by HTTP.SYS to find out if the request can be located in the kernel-mode cache.

5. If it is found in the cache, a response is immediately returned.

6. If not in the cache, HTTP.SYS places the request in the correct queue.

7. If no worker processes are assigned to the queue, WWW Service starts one.

8. The worker process pulls the request from the queue and processes it.

9. The response is sent back to HTTP.SYS by the worker process.

10. HTTP.SYS sends the response back to the client.

11. If logging is enabled, HTTP.SYS writes the request to the log.

In IIS 6.0, all HTTP application runtime services, like ISAPI support, are available to every application pool. There is no longer any notion of in-process applications, which means an application error in one specific Web application or Web site cannot affect other Web applications or sites.

Next we will examine the application pools. As an administrator, you can collect one or more Web applications or Web sites into a separate group, called an application pool. The applications or sites in a pool share one or more worker processes. Application pools are separated from each other by process boundaries, which prevents one pool from affecting others and also makes sure an application cannot be routed to another pool as long as the current pool is servicing it. However, you can quite easily assign applications to other pools if you want, even when the server is running. Each of these application pools is represented in HTTP.SYS by a request queue. The user-mode worker process(es) serving a pool fetches requests from this queue.

Note

By default, each application pool has only one worker process, but you can configure it to have n worker processes sharing the work. HTTP.SYS distributes among the worker processes in the pool. This configuration is known as a Web garden. The difference between a Web garden and a Web farm is that the former resides on one server and the latter on many. One benefit of this is that if one worker process fails, there are others to take its place immediately.

Here is how you create a new application pool (see also Figure 7-12):

1. Open IIS Manager.

2. Expand Application Pools.

3. Right-click Application Pools.

4. Choose New\Application Pool.

5. Enter an ID for the pool (for example, MyNewPool).

6. Click OK to create the new application pool.

By providing the worker process isolation mode, IIS 6.0 makes sure you can prevent one application or site from stopping the others.

To be compatible with IIS 5.0, IIS 6.0 includes something called IIS 5.0 isolation mode. This is an isolation mode that works very similarly to the corresponding mode in IIS 5.0 and lets you more easily move your existing applications without upgrading them immediately. You still can benefit from many of the new features in IIS 6.0 in this mode. We will not, however, cover this feature in more detail here.

Table 7-1 shows the isolation modes that IIS is set to after installation.

Table 7-1: Overview of the Isolation Modes of IIS 6.0 After Installation

Installation Method	Isolation Mode
New installation of IIS 6.0	Worker process isolation mode
Upgrade from previous installation of IIS 6.0	Same as new installation of IIS 6.0
Upgrade from IIS 5.0	IIS 5.0 isolation mode
Upgrade from IIS 4.0	IIS 5.0 isolation mode

If you want to change the isolation mode, follow these steps:

1. Open the IIS Manager.

2. Right-click the Web site's folder.

3. Choose Properties.

4. Click the Services tab.

5. Note the Isolation Mode checkbox. If the checkbox is checked, IIS 5.0 isolation mode is active.

6. Check/uncheck the checkbox as required.

7. Click Apply.

8. Click Yes to restart the Web services.

9. Click OK.

Performance and Scalability

Many of the performance issues discussed in the "Internet Information Services 5.0" section are still valid in IIS 6.0, so we will not cover them again. We have mentioned that performance has been improved in IIS 6.0. Now we will examine some of the features responsible for this improvement, and the benefits they confer on reliability as well.

First of all, you have a clean separation between user code and the server. This is provided by letting the worker processes handle all user code. Since the worker processes are completely separated from the server, an error in user code will not affect the server, only the worker process in which it occurred. The WWW Service creates a new worker process to replace the failed one, which prevents the user from noticing the error. By providing the worker process isolation mode, IIS 6.0 makes sure you can prevent one application or site from stopping the others, thereby greatly improving reliability.

By cutting down most of the overhead, IIS 6.0 improves performance when isolating applications or sites. This way you can host many more sites and applications on your server and still get great performance and reliability.

If an error occurs in a specific application, IIS 6.0 can fire events and commands when the WWW Service detects the problem. By providing this extensibility model, IIS 6.0 also allows load balancers and switches to be configured to automatically stop routing traffic to a faulty application, while not affecting routing to the healthy ones. If you have two applications and one of them fails so often that IIS automatically shuts it down, you will still want the healthy one to receive requests. This is when the extensibility model comes in handy.

As you just saw, IIS now can shut down an ill-behaving application. This feature, called rapid-fail protection, occurs when a specific application pool encounters many failures in a row. When this happens, the application pool is placed in "out-of-service" mode and HTTP.SYS returns the error message "503— Service unavailable" to anyone making a request to the pool or requests in the queue for the pool. This feature is configurable, so you can decide if and when rapid-fail protection should occur.

To free unused resources, you can configure an application pool to shut down its worker processes if they are idle for a specified time. When there is demand for additional worker processes, they are automatically started again.

The HTTP.SYS is a new kernel driver. It is a single point of control for all incoming HTTP requests, and as such it provides high performance in regard to connectivity for HTTP server applications. According to Microsoft, this new architecture provides performance gains of up to 200 percent with static content, and up to 165 percent higher throughput for cached responses—compared to IIS 5.0, that is.

Sometimes it is not desirable to cache an item just for the sake of caching. It might be too costly in terms of memory and management to keep it cached. To prevent this, IIS 6.0 includes a new advanced heuristic to determine what to cache. The decision is based on the distribution of requests to a specific application. This better use of server resources increases scalability, while still keeping the performance high on frequently requested services.

In IIS 5.0, all ASP code is compiled to an ASP template by the ASP engine. This template is then stored in the process memory. The cache is cleared based on the age of the templates, so older templates make room for newer ones. In IIS 6.0, these templates are saved and persisted to disk. The advantage of this is that you do not have to spend CPU time on compiling them again. Instead, you load the templates from disk.

Security

Microsoft has been criticized over the years for the lack of security in its products. But with Windows Server 2003 a lot has happened. Earlier versions of IIS were installed by default with many of its features already enabled. The downside of this was that many administrators actually were not aware they had a Web server and did not take any actions to secure it. It was left open for intruders to exploit. This is no longer the case. IIS 6.0 is not installed if you do not specifically select it for installation during Windows Server 2003 setup (see Figure 7-13).

You must open Windows Setup through Add or Remove programs in the Control Panel to install IIS 6.0. This way you do not unknowingly expose the Web server.

If you perform an upgrade of the operating system to Windows Server 2003, IIS is disabled. The reason for this is to prevent accidentally installed IIS from earlier Windows versions from being active after the upgrade. The first time this feature was introduced in the beta of Windows Server 2003, it took us quite some time before we figured it out. After that, we performed no upgrades without first reading the readme file.

To prevent users from installing IIS on their machines without the administrator knowing about it, you can restrict installation by group policy. This is a great way of keeping track of Web servers in the company, so you know which servers to patch when new security updates are available. The only thing you have to worry about now is ducking when the users find this out.

Even after you have installed IIS, only static content, like HTML files, JPEGs, and so on, is served. An administrator must enable ISAPI and ASP support manually for the server to handle such requests (see Figure 7-14). This feature enhances security further.

It is also important to disable the Web service extensions—for instance, .asp, asp.net, or server-side includes—that are not necessary for your solution. To manually enable or disable Web service extensions, follow these steps:

1. Open Internet Information Services Manager and expand the local computer.

2. Click Web Services Extensions.

3. Click the Web Service Extension to enable/disable it in the details pane.

4. Click Allow to enable Web service extensions, or Prohibit to disable them (see Figure 7-15).

   
   Figure 7-15: Here you can manually enable or disable extensions in IIS Manager

5. Click OK.

To be really flexible, you can even add a new Web service extension if you want to, as Figure 7-16 shows, by following these steps:

1. Open Internet Information Services Manager and expand the local computer.

2. Click Web Services Extensions.

3. Click Add a new Web service extension.

4. Enter the name of the new extension in the Extension name box.

5. In the Path to file text box, you can supply a path to any files necessary for the new extension. Click OK to close.

6. Click Add.

7. Select the Set extension status option to Allowed to automatically enable the extension (optional).

8. Click OK.

One of the most important security principals, which we cannot stress enough, is not letting anyone have more privileges than absolutely necessary. This makes it harder for anybody trying to exploit a security vulnerability. In IIS 6.0, the worker process runs as NetworkService, a new, built-in account with few privileges on the underlying system.

One popular way of trying to hack a Web server is by executing command-line tools via the Web server. This is no longer possible because IIS 6.0 will not allow command-line tools to be executed by the Web server. When examining one of the logs on one of our own Web sites, we realized the extent of this behavior. So this is a welcome addition to our servers.

There have also been some improvements to Secure Sockets Layer in IIS 6.0. According to Microsoft, IIS 5.0 was the fastest software-based SSL implementation on the market. The result has been that approximately half of all SSL servers use IIS. The new IIS in Windows Server 2003 is said to be even faster. Microsoft has put a lot of effort into tuning SSL, but unfortunately we have not been able to test this yet, so we really do not know if it stands up to real-life testing.

One problem with having many IIS servers with SSL certificates is how to manage them. In IIS 5.0 this was not possible, but IIS 6.0 provides the CertObject to allow you to do this.

To speed up cryptographic computations when using SSL, a separate accelerator card is often used. This offloads the CPU on the server, so performance will remain high during SSL connections. In IIS 6.0, you can easily plug in your own Crypto API (CAPI) provider and let the Web server use this.

To further enhance security, Microsoft has done a lot when it comes to authentication and authorization in IIS 6.0. Table 7-2 shows an overview of the different authentication methods you can use with IIS 6.0.

Table 7-2: Overview of the Authentication Methods in IIS 6.0

Method	Security	How to Send Passwords	Can Be Used with Proxy Servers and Firewalls?	Client Requirements
.NET Passport	High	Encrypted	Yes, by using an SSL connection	IE and Netscape
Certificate	High	N/A	Yes, by using an SSL connection	IE and Netscape
Integrated Windows	High	When using NTLM, hashed; when using Kerberos, Kerberos ticket	Not unless PPTP is used	IE 2.0 and later for NTLM W2K; IE 5.0 or higher with Kerberos
Advanced Digest	Medium	Hashed	Yes	IE 5.0 or later
Digest	Medium	Hashed	Yes	IE 5.0 or later
Basic	Low	Base64-encoded clear text	Yes	Almost all browsers
Anonymous	None	N/A	Yes	All browsers

Figure 7-17 also shows where in IIS Manager you handle authentication.

Let us take a closer look at some of these methods, starting with Passport authentication. IIS 6.0 employs Passport version 2 and can be used with standard Passport components, enabling you to take advantage of the enormous Passport user base. As of this writing, the number of users were way past 150,000,000 and counting. By using Passport, you do not have to bother with password expiration or other issues related to account management. But you really need to give some thought to this matter before you use it. Is it really a good idea to let another company (Microsoft) handle the accounts? Can you trust the security provided? We say it depends on your application. If the Web site or application provides sensitive information, you would probably be better off without it. But you can map a Passport account to an Active Directory account if you want to. If you do, once the authentication with Passport is made, and the mapping to the AD account is done, the Local Security Authority (LSA) creates a token for the user, which IIS uses for the request.

When using Advanced Digest authentication, the user credentials are stored as an MD5 hash in Active Directory on the domain controller. Since it is stored in AD, user passwords cannot be discovered easily by anyone with access to the domain controller. This is the preferred authentication method of the two digest modes available.

After a user is authenticated, you must control what and how much the user is allowed to do. This is called authorization. To restrict an authenticated user from gaining too many privileges, we have often used Access Control Lists to make authorization decisions. The problem with this method is that it is too focused on the NTFS and its requirements. Windows Server 2003 includes a new authorization framework that lets you extend authorization to operations or tasks. Most of today's business applications have a tendency to be more operation or task dependent than object (file system) oriented, and ACLs do not solve this problem. Windows Server 2003 provides, for example, a gatekeeper authorization to URLs to solve this.

Web applications can use this URL authentication in combination with the Authorization Manager to control access. This can be done from the same policy store to control application-specific tasks and operations and also URLs that perhaps are compromising a Web application. This provides you with a single point of administration for URLs and application features, which clearly eases the job of administering your applications and sites.

Note

To open Authorization Manager, select Start | Run and enter azman.msc in the Open text box.

Another feature in IIS 6.0 is constrained, delegated authentication. Imagine a site that shows information about a customer and his or her purchasing history. To provide all such information to the user, the Web site might need to gather data from many sources on your network. To handle all authentications to these sources, the server application can act as a user on the network with sufficient privileges to access information. This is called delegation. The concept of constrained delegation was introduced with Windows Server 2003 to enable you to have control over which computers and services you delegate control to. This method is great when you have RPCs (Remote Procedure Calls) and DCOM calls in your network, because it simplifies authentication across the network.

To avoid problems, you should allow servers to connect to only the specific services, like a SQL Server, necessary for the applications to run. The concept of assigning the least privileges necessary is valid here as well. You should also make sure the client does not need to share its credentials with the server either. Otherwise someone with bad intent might try to use this to gain access to the whole domain.

When it comes to security, a lot of the best practices in IIS 5.0 are valid with IIS 6.0. Here is an overview of some of these.