Let's now look in detail at the various site-level administrative tasks we can perform on IIS. We'll begin by looking at how to manage Web sites or virtual servers created using the WWW service. Then we'll consider FTP sites and SMTP and NNTP virtual servers in the following sections.
We've already briefly considered the Master Properties dialog box for the WWW service in Figure 28-4, and seen that there are 10 tabs that contain various settings we can configure. Nine of these ten tabs are also used at the site level for administering individual Web sites, and in this section we'll look at these various tabs and their settings in detail. For our choice of a Web site to configure in this section, we have selected the Default Web Site.
NOTE
A Server Extensions tab will also be present if FrontPage extensions are configured on the Web site, as discussed earlier in this chapter.
The Web Site tab of the Properties window (Figure 28-8) allows you to specify Web site identities, to configure a limit for the maximum number of concurrent TCP connections with the server for HTTP sessions, to enable or disable HTTP Keep-Alives, and to enable IIS logging on your server. Let's examine how to assign identities to Web sites first.
Figure 28-8. The Web Site tab for the Default Web Site.
Each Web site hosted on an IIS machine must have a unique identity so browser clients can connect to it to download its content. Web sites are defined using three different parameters: IP address, TCP port number, and host header name.
The identity for a Web site is specified on the Web Site tab of the Properties window for the particular Web site under consideration. For Web sites on the same machine to have unique identities, they must differ from each other in at least one of the three parameters just mentioned. Let's look at some different ways of specifying Web site identities by considering how to host several different Web sites on the same server.
The disadvantage is that if many sites must be hosted on the machine, then many IP addresses must be obtained and assigned to it. This isn't a problem on a private internetwork when using one of the private IP address blocks like 10.y.z.w, 172.16-31.z.w, or 192.168.z.w. On servers directly connected to the Internet, however, you must obtain a sufficient number of IP addresses from your ISP. Nevertheless, this method of specifying Web site identities is the preferred and commonly used one.
NOTE
When you open the Properties window for the Default Web Site and select the Web Site tab, the IP address is specified as (All Unassigned). This means that this Web site will respond to any IP addresses that aren t specifically assigned to other Web sites on the machine. That s actually what makes this site the Default one, and only one Web site on an IIS machine can have its IP address specified this way.
When the client requests a URL like http://sales.scribes.com, the client passes the host header name sales.scribes.com in the HTTP request headers that it sends to the server. (See Chapter 27 for more information on HTTP headers.) The server parses the host header name and identifies which Web site the client is requesting and returns the appropriate files. One disadvantage is that the client must also support host header names, that is, the ability to pass the DNS name of the site in its HTTP request headers. Host header names are supported by Microsoft Internet Explorer 3 or later and by Netscape Navigator 2 or later. Another disadvantage is that host header names don't work with SSL connections because the HTTP session is encrypted.
If you're working with older browsers that don't support host header names, you can implement a cookie-based mechanism to enable them to distinguish between Web sites having the same IP address and TCP port number. See the online documentation for more information on how to do this.
TIP
Unlike the previous version (IIS 4 for Windows NT), when you change the TCP port number for a Web site, you don't need to reboot your server for the change to take effect.
The Web Site tab also allows you to configure a limit for the maximum number of concurrent TCP connections with the server for HTTP sessions. You can also enable or disable HTTP Keep-Alives and specify a connection timeout value. HTTP Keep-Alives are a feature of HTTP 1.1 that enable a client to keep a TCP connection open with a server after downloading a file, in case other files need to be immediately downloaded from the server. If clients start complaining about the server being sluggish or that they're frequently receiving HTTP 500: Busy errors, try decreasing the connection timeout value so that unused TCP connections will time out more quickly.
NOTE
Connection timeouts specified on the Web Site tab are for active TCP sessions. TCP has its own settings for automatically terminating half-open TCP connections, such as those created during a Denial of Service (DoS) attack that tries to bring down a Web server by flooding its network connection with TCP SYN packets.
The Web Site tab also allows you to enable IIS logging on your server. This feature is enabled by default and allows administrators to monitor access to the site by client browsers. Logging information can be saved in a variety of formats, including the following:
New IIS logs can be created on an hourly, daily, weekly, or monthly basis, or when the existing log file grows to a specified size. Logs are stored by default in the \%WinDir%\System32\LogFiles folder, but you can use the Properties button to modify this setting. Note that the older Microsoft IIS Log File Format (supported under IIS 4) is no longer available here.
TIP
Enabling IIS logging on the Web Site tab doesn't actually mean that visits to all parts of your site will be logged. In the Web site's dialog box, you can use the Home Directory tab's Log Visits check box to enable or disable the logging of accesses to content located in the site's home directory. On other tabs, you can similarly track visits to other directories or even individual files.
A Web site operator is a user account that can perform common administrative tasks that relate only to that site. Operators are like site administrators, as opposed to members of the Administrators group who can administer all aspects of all sites on a machine. Operators have the necessary rights to configure the following options and characteristics for the Web sites on which they are defined:
However, operators cannot perform tasks that would modify the basic nature of the site itself, such as configuring the IP address, the TCP port number, bandwidth throttling, and application settings. Operators also can't create or delete virtual directories.
You can tune performance for individual Web sites using the Performance tab of the site's Properties window, as shown in Figure 28-9. On this tab you can configure the following settings:
Figure 28-9. The Performance tab for the Default Web Site.
Internet Server Application Programming Interface (ISAPI) filters are optional DLLs that perform specific actions when IIS processes an HTTP request from a client. You can use the ISAPI Filters tab to install a series of these filters and specify the order in which IIS processes them. Filters installed here at the site level are used only by the selected site; filters installed at the server level apply to all sites on the server.
ISAPI filters perform their action before the server actually responds to the HTTP request itself. For example, you could design an ISAPI filter to perform custom authentication, encrypt data, write traffic information to a custom log file, or perform some other action. Implementing ISAPI filters is beyond the scope of this book.
The Home Directory tab (Figure 28-10) allows you to specify the location of the content that is mapped to a Web site's home directory, to specify various access permissions and other settings for the directory, and to specify application settings relating to any Web application you have implemented in this directory.
Figure 28-10. The Home Directory tab for the Default Web Site.
The home directory for a site determines the location of any content that is accessed using a URL such as http://Site_Name/File_Name, where Site_Name represents the NetBIOS name, IP address, or DNS name of the site, and File_Name represents the name of any particular HTML page, image file, script, or other file in the site's home directory. You can specify the home directory for a site in three different ways:
REAL WORLD Redirecting Access
Being able to redirect the home directory (or any virtual directory) to a URL is useful when Web sites are being developed or are down for maintenance or upgrade. IIS gives you the option of redirecting a request for any file in the home directory to the same URL (such as a We're Down for Maintenance page) or to a similar file in the remote directory (for example, to redirect the client to a temporary mirror site). You can also redirect access to a subdirectory of the current home directory if your maintenance page or mirror content is located on the same server.Specify a permanent redirection only if you really plan to move the site's content to another server, as some browsers that receive an HTTP 301 Permanent Redirect message might actually modify a favorite or bookmark linked to the site automatically. The result is that when redirection is turned off, the client continues to access the alternate site instead of the original one.
If you specify the location of the home directory as either a local directory or a network share, you have the option on the Home Directory tab of specifying various access permissions and other settings for the directory (Figure 28-10). These settings aren't available if you specify redirection to a URL for the home directory location. You can specify the following settings:
NOTE
Although Read access is enabled by default on the Default Web Site, whether you can access a particular Web site and its contents depends on a number of conditions. See the section Understanding IIS 5 Security in Chapter 27 for more information on securing access to IIS Web sites.
If you have selected a local directory or network share for your home directory, you also have the option on the Home Directory tab to specify application settings relating to any Web application you have implemented in this directory. An example of a Web application might be a collection of ASPs working together to provide some programmatic functionality to the user who visits the site. Developing Web applications is not the subject of this book, but the settings that can be configured here include these:
CAUTION
If you specify Write access for the directory along with Scripts And Executables, your security might be threatened: an untrusted user might be allowed to upload a hostile executable program file to the server and cause damage.
The Documents tab of the Properties window for a Web site allows you to specify possible filenames for default documents for the home directory, and specify the order in which a browser attempts to access them. The three types specified by default are (in order) Default.htm, Default.asp, and Iisstart.asp.
For example, if a browser tries to connect to the Default Web Site on the server ws1.scribes.com by using the URL http://ws1.scribes.com, the server will first check to see whether a file named Default.htm resides in the home directory. If such a file is there, it will be returned to the client. If not, the server will check for a file named Default.asp. The process continues until either a file is returned or the list of default documents is exhausted. You can specify additional default document names, like Index.htm, or delete existing ones if you like. You can also disable default documents entirely, in which case, clients must know and type in the actual name of the file they want to access on the server, for example, by using the URL http://ws1.scribes.com/default.htm.
This tab also lets you specify the name of a footer file (written in HTML) that is appended to the bottom of every file retrieved from the site by a client. You could use this, for example, to add a copyright statement or disclaimer to the bottom of each page. If you're using FrontPage to develop your content, you can create complex footers that display information like the date when the file was last modified, a hit counter, and so on.
The Directory Security tab allows you to specify whether anonymous users are allowed to access content in your site, to restrict access to a Web site, and to enable secure HTTP communication. Let's take a look.
To specify whether anonymous users are allowed to access content in your site or whether some form of authentication will be required, open the Authentication Methods dialog box, shown in Figure 28-11, by clicking the Edit button within the Anonymous Access And Authentication Control field on the Directory Security tab. Use the dialog box to configure these settings:
Figure 28-11. The Authentication Methods dialog box.
TIP
Integrated Windows authentication is designed to be used primarily on intranets and other internal networks because it won't work through an HTTP proxy connection.
REAL WORLD Combining Different Authentication Methods
Consider the consequences of selecting more than one method in the Authentication Methods dialog box. If you select Anonymous Access together with some form of authenticated access like Basic Authentication, anonymous access is attempted first. If this fails, authenticated access is tried. Anonymous access could fail if the NTFS permissions on the resource explicitly deny access to the anonymous user account, for example.If you select two or more forms of authenticated access, the most secure forms are attempted first. For example, integrated Windows authentication would be tried before attempting basic authentication. For information on how authentication fits into the general scheme of IIS security, see Chapter 27.
The Directory Security tab also allows you to restrict access to a Web site by giving clients a particular IP address or DNS domain name. Figure 28-12 shows the IP Address And Domain Name Restrictions dialog box that you can access from this tab.
Figure 28-12. The IP Address And Domain Name Restrictions dialog box.
Use this dialog box either to allow all clients access to the site except for those whose IP addresses or domain names are as specified here, or to deny all clients access to the site except for those whose IP addresses or domain names are specified here. You can place restrictions on clients in three ways:
Note that selecting the last option can significantly affect server performance because reverse DNS lookups must be performed on all clients prior to granting them access. For information on how IP address and domain name restrictions fit into the general scheme of IIS security, see Chapter 27.
The Directory Security tab also allows you to enable secure HTTP communications by implementing the SSL version 3 protocol, which you can use to encrypt Web traffic between client and server. SSL is essential if you plan to use your server for running Web applications that involve financial transactions or hosting sensitive information. Web browsers access a secure server using SSL by using URLs that are prefixed by https:// instead of the usual http:// prefix.
SSL is based on public-key cryptography, in which digital certificates are used to establish the identity and trustworthiness of servers (and of clients), while a public/private-key pair is used for encrypting and decrypting transmissions to ensure that the information being transmitted is secure and has integrity (in other words, that it's from who it says it's from). Public-key cryptography and its associated concepts are covered in Chapter 17.
Before attempting to implement secure communications, you must establish access to a certificate authority (CA) that can grant the IIS server the necessary server certificate and public/private-key pair. For this purpose, you have a choice:
To enable SSL, you first need to generate a certificate request file and submit this to a CA in order to receive a server certificate from the CA. The server certificate contains the associated public key and is used for verifying the identity of the server and establishing secure connections.
To obtain a server certificate, follow the steps outlined below. For our example, the server certificate is being requested for the Default Web Site on server ws1.scribes.com, while the server running Certificate Services is the domain controller dc1.scribes.com. The name of the CA for our scribes.com enterprise is Scribes.
Figure 28-13. The Web Server Certificate Wizard.
Once a server certificate is installed on your Web site, you can view the certificate information by clicking the View Certificate button on the Directory Security tab. Figure 28-14 shows a certificate installed on the server ws1.scribes.com, which was obtained from server dc1.scribes.com, the Windows 2000 Server running Certificate Services.
Figure 28-14. Server certificate for ws1.scribes.com issued by the certificate authority known as Scribes.
Now finish enabling SSL for the Default Web Site on ws1.scribes.com:
Figure 28-15. Enabling SSL using the Secure Communications dialog box.
REAL WORLD Secure Communications Options
Besides enabling SSL using the server certificate installed on the IIS system, you can also use the Secure Communications dialog box in Figure 28-15 for the following purposes:
- To specify that SSL connections will use strong 128-bit encryption. (This is available only in the United States and Canada under current U.S. encryption laws.)
- To specify how to handle client certificates. Client certificates verify the identity of clients and are typically used when remote users need to securely access a corporate intranet over an nonsecure Internet connection. You can specify either to ignore, accept, or require client certificates during SSL communications.
- To enable client certificate mapping. This feature enables administrators to create mappings between Windows 2000 user accounts and client certificates so that users who have the appropriate client certificate can automatically be authenticated and logged on to the network.
- To enable a certificate trust list (CTL). A CTL is a list of approved CAs for the Web site that are considered trusted by the Web site. CTLs are created using the CTL Wizard by selecting the New button at the bottom of the Secure Communications dialog box.
You can use the HTTP Headers tab of the Properties window for a Web site to enable content expiration on the site, to specify custom HTTP headers that are returned by the server to requesting HTTP clients, to enable and specify Recreational Software Advisory Council (RSAC) content ratings on the server, and to specify additional MIME mappings for a particular Web site.
When you enable content expiration on the site, the result is that when a client browser requests a file from the site, the HTTP headers returned by the server include information regarding the expiration date of the site's contents. The client can then decide whether it needs to download a newer version of the file or use an existing copy in the client browser cache.
TIP
If your site contains information that changes frequently (like sports scores), you can force clients to always retrieve fresh copies of files from the server (and never use cached versions of these files) by selecting the Expire Immediately option.
This rather esoteric feature allows you to specify custom HTTP headers that are returned by the server to requesting HTTP clients. You might use this option in certain situations involving firewalls or proxy servers to enable or disable specific features during HTTP sessions.
This option is used to enable and specify RSAC content ratings on the server. These settings rate the site's violence, sex, nudity, and language content and are typically enabled on sites hosting content unsuitable for viewing by minors.
MORE INFO
For more information about the RSAC, see http://www.rsac.org.
The global MIME mappings for an IIS server were discussed in the previous section on server-level administration. For site-level administration, you can specify additional MIME mappings for a particular Web site.
The Custom Errors tab allows you to specify how your server will generate HTTP error messages when users attempt to access the selected Web site (Figure 28-16).
Figure 28-16. Specifying custom HTTP error messages.
The HTTP specification defines that the first header line returned by a Web server in response to a request by a client will contain a number and associated message indicating the status of the request. These three-digit numbers are called HTTP status codes, and they fall within various ranges:
Instead of returning bare HTTP status codes and their brief messages for the error codes (400 through 499), however, IIS is configured by default to use predefined HTML pages that contain somewhat more information than the status codes and messages. These "error files" are located in the \%WinDir%\help\iishelp\common folder on the server, and you can modify them if you want.
Alternatively, by selecting one of these error files on the Custom Errors tab and clicking Edit Properties, you can specify that the Default HTTP status codes and messages will be returned by the server when that error occurs, or that any specified file located in either a local folder or a network share will be returned when that error occurs. Companies commonly use this feature to create error pages that contain elements like the company logo, the e-mail address of customer support, or even a search tool for finding the page the client is trying to access.
NOTE
IIS uses more detailed error messages than are included in the original HTTP specification. For example, the HTTP error code 401 which in HTTP simply means unauthorized is represented in IIS by a group of codes spanning from 401.1 through 401.5, representing various reasons why a server might deny a user s credentials.