Administrative Changes

Most IIS administration is accomplished through the IIS console, a Microsoft Management Console (MMC) snap-in. There are a number of other administration interfaces, though, such as Windows Management Instrumentation, scripts, command-line tools, and so forth. All these interfaces, however, interact with IIS's Administration Base Objects (ABOs), a set of COM components that modify the IIS metabase. The metabase contains all IIS's configuration settings, making them universally available. Figure 7.3 shows the relationship between the administrative interfaces, ABO, and the metabase.

Figure 7.3. The metabase is XML based and contains all of IIS's configuration settings.

Administering IIS 6 is similar to administering earlier versions of IIS; the next few sections cover the major changes, especially those that relate to IIS 6's new architecture and security enhancements.

Configuring Server and Web Site Options

One major change to IIS Web sites is the capability to support Microsoft .NET Passport authentication, in addition to the familiar Integrated Windows authentication, Basic authentication, and Digest authentication. Passport authentication can be enabled in the properties of a Web site, as shown in Figure 7.4. Keep in mind that Passport authentication requires a .NET Passport infrastructure, which you have to set up with Microsoft for additional fees. Visit www.Microsoft.com/passport for more details.

Figure 7.4. Passport authentication makes creating Internet Web sites that use Microsoft's popular authentication mechanism easier.

You'll find that most other Web site and server administrative options are unchanged from Windows 2000: Logging, directory security, digital certificates, document paths, and other settings work the same as in IIS 5.0. Note that the Default Web Site enables additional document types for the default document, as shown in Figure 7.5. Now, Default.aspx joins Default.asp , Index.htm , and Default.htm as default pages that IIS looks for. Default.aspx is an ASP.NET file type.

Figure 7.5. Default.aspx is last on the list, meaning any other default page is loaded instead, if one is present.

Another important change is to a Web site's general properties: The ability to specify the application pool with which the site is associated. IIS is configured with a couple of default application pools to which you can assign your applications, but you'll more than likely want to create your own pools for full control over IIS's behavior and performance.

Configuring Application Pools

To configure a new application pool, simply right-click Application Pools and select New Application Pool from the pop-up menu. Each application pool's properties dialog box includes four tabs: Health, Recycling, Performance, and Identity.

The Recycling tab, shown in Figure 7.6, is where you tell IIS how to treat worker processes. You can tell IIS to automatically recycle worker processes after a specified number of minutes, after they handle a certain number of requests , or a combination of the two. You can also specify that processes be recycled at specific times, such as idle times for your application. Finally, you can tell IIS to recycle worker processes after they've consumed a specific amount of memory, forcing IIS to clean up and terminate any processes that are no longer being used.

Figure 7.6. IIS defaults to recycling worker processes every two hours, which is sufficient for most applications.

Figure 7.7 shows the Health tab, which is where you tell IIS how to determine whether a worker process within the application pool is healthy . By default, IIS pings each process every 30 seconds to see whether it responds; processes that don't respond are considered unhealthy and are normally terminated. This dialog box also enables you to configure IIS's rapid-fail protection feature by specifying a maximum number of failures within a specified period of time. Application pools that exceed these thresholds are permanently disabled. Finally, you can specify the maximum amount of time, in seconds, that a worker process should take to start or stop. You'll need to take into account the initialization time for any ISAPI filters or extensions the processes must load. Any process exceeding these time limits is assumed to be unhealthy and is terminated .

Figure 7.7. The default health settings are sufficient for most Web applications.

Figure 7.8 shows the Performance tab, which enables you to configure the performance for an application pool. You can specify that IIS automatically terminate worker processes that have been idle for a specific amount of time (the default is 20 minutes). This dialog box is also where you specify the maximum number of worker processes for the application pool's Web garden. The default is 1, which means the pool will be served by a single worker process.

Figure 7.8. A single worker process is not the same as a single thread; one process can still be multithreaded to support multiple simultaneous users.

The Performance tab also enables you to configure the application pool's request queue length, and the default is 1,000 requests. As worker processes pull requests from the queue, it empties. New requests are placed onto the queue by http.sys . When the queue fills, http.sys automatically responds to new requests with an error message until the queue empties out. You can use the queue limit setting to restrict the number of requests that can stack up for a slow-running Web application; in many cases users might prefer to receive an "unavailable" error message rather than wait for your application to catch up and service their request. Also, forcing the server to queue more requests for a slow application requires http.sys to maintain a larger number of open HTTP connections, which consume server resources.

Finally, the Performance tab enables you to monitor the amount of CPU that the application pool uses. Simply enable a CPU threshold, and then specify an action to be taken if that threshold is exceeded. By default, the CPU monitoring feature is disabled.

Finally, Figure 7.9 shows the Identity tab, which is where you can configure the security context of the application pool. You can use a predefined identity, such as the default Network Service or configure a custom user account the application pool will use.

Figure 7.9. By default, all application pools run under a low-privileged, anonymous user account.

Caution

Be very careful when configuring application pool identity. If the pool runs under a high-privilege user account, or even an ordinary domain user, hackers might be able to exploit IIS security flaws and perform unauthorized actions on your servers.

Configuring Web Services Extensions

Web Services extensions enable you to more easily configure extensions such as ASP and ASP.NET. Figure 7.10 shows the Web Service Extensions container in the IIS console, listing all the extensions configured in IIS by default. Notice that many extensions are configured but set to be Prohibited (the figure does not reflect the default prohibited/allowed status for each extension). The Prohibited setting allows Microsoft to ship IIS with a number of useful extensions but to ensure that those extensions are disabled until an administrator specifically enables them.

Figure 7.10. Notice the filter extensions for unknown ISAPI extensions and CGI extensions, which are prohibited by default.

You can modify the properties for any extension by double-clicking it. The extensions' Properties dialog box, shown in Figure 7.11, lists the files required for the extension to operate and the status of the file. For example, Figure 7.11 shows the properties for the Internet Data Connector extension, which uses the httpodbc.dll file. By default, this file is prohibited, preventing the extension from operating.

Figure 7.11. A single extension can have any number of associated files; the Internet Data Connector extension shown here has only one associated file.

You can also create your own extensions. For example, one popular alternative to ASP is PHP (www.php.net), an Open Source scripting language designed specifically for creating dynamic Web pages. Most PHP pages use PHP as their filename extension and are processed by a special ISAPI DLL. IIS 6 makes configuring PHP as a Web Service extension easy, enabling your Web server to host PHP pages.

To create a new Web Service extension, right-click the Web Service Extensions container in the IIS console and select New Web Service Extension from the pop-up menu. As shown in Figure 7.12, provide the extension's name and required files and select the check box that sets the extension's status to Allowed. Click OK , and IIS will immediately recognize the new Web Service extension and allow it to be executed by worker processes.

Figure 7.12. Remember that any extensions not specifically defined as Allowed are automatically prohibited and not allowed to execute.

Web-Based Administration

IIS 6 also supports full Web-based administration as part of Windows Server 2003's Web-based administration console. The Web-based console is accessible only to administrators and uses a built-in digital encryption certificate to provide secure HTTPS connections. To access a server's administrative Web page, simply type the server's name, followed by :8099 , in your Web browser. For example, type http://ServerA:8099 .

Tip

Don't try to access the administration site by using the URL http://localhost . The site requires encryption and can enable encryption only when you use the server's actual name.

Figure 7.13 shows the Web-based console, opened to the Web Server administration screen. Notice that the server is displaying a status of Warning in the upper bar, just below the server name. This warning is present on all new Windows Server 2003 computers and is a reminder to you to replace the server's preconfigured encryption certificate with a valid certificate of your own.

Figure 7.13. The Web-based administration console provides access to several administrative functions.

Only members of the server's local Administrators group can access this Web site by default. In a domain, the local Administrators group includes the domain's Domain Admins group , allowing any domain administrator to access the Web site.

If, for any reason, the Web site is not capable of using a secure HTTPS connection, you'll see the error screen shown in Figure 7.14. You should never try to bypass this security check; the administrative Web site contains a great deal of confidential information, and if you use it to reset user passwords or deal with other sensitive data, the HTTPS encryption will protect that data as it travels across your network. Without the HTTPS encryption, your sensitive data can be easily compromised.

Figure 7.14. Notice that encryption could not be enforced here because the localhost URL was used rather than the server's actual name.

As an additional security precaution, you might want to reconfigure the Administration Web Site to use a different port number. Doing so will help deter attackers who might try to access the site on its default port number. Additionally, if you don't plan to use the Administration Web Site, use the IIS console to stop it completely, preventing an attacker from accessing it at all.