IIS 5.0's Hidden Differences

Knowing IIS 5.0's secrets will make your upgrade more safe and secure

Windows 2000 is host to many new features, including Microsoft IIS 5.0. No longer relegated to mere Microsoft Windows NT 4.0 Option Pack status, IIS 5.0 is considered a core component and comes on the Win2K CD-ROM.

IIS 5.0 is a faster, more stable Web server than IIS 4.0. Some businesses that use IIS 4.0 need to schedule reboots of their servers to avoid problems with Web server functionality. When Microsoft developed IIS 5.0, the company concentrated its efforts on stability and performance at the expense of new features. IIS 5.0 is now a key reason for businesses to adopt Win2K.

Although new features aren't IIS 5.0's main goal, the product is significantly different from IIS 4.0. Many of IIS 5.0's differences are widely known: new authentication methods, better performance, and the option to run applications as pooled-out-of-process. Some differences, however, are obscure but important.

Installation
When you install IIS 4.0, the software asks where you want to place your Web and FTP root folders. This option lets you locate your Web root on the volume of your choice. For security and optimization purposes, administrators commonly place the Web root on a volume other than drive C.

However, a typical Win2K installation automatically places the IIS 5.0 Web root on drive C without giving you an option to place it elsewhere. The only way to install IIS 5.0 on a drive other than C is to perform an unattended installation. To start such an installation, you can use the Sysocmgr utility, which Win2K installs, and specify the location of the Web root, the FTP root, and the inetsrv folder, which is typically under C:winnt. If you install IIS 5.0 on drive C and find that you don't want it there, uninstall it immediately and use unattended installation to place it wherever you want. For information about unattended installations, see the Microsoft article "How to Change the Default Installation Paths for FTP and the Web" (http://support.microsoft.com/support/ kb/articles/q259/6/71.asp), the Deployment Planning Guide of the Win2K resource kit, and "Microsoft Windows 2000 Guide to Unattended Setup" (unattend.doc), which you can find in thesupporttoolsdeploy.cab folder of the Win2K installation CD-ROM.

File and Directory Changes
IISHelp. You can find IIS 5.0's IISHelp directory at %systemroot%winnthelpiishelp. IIS 4.0's Help files are in the same path, but the folder is iis instead of iishelp. Help files often have links to administrative features, wizards, and programs that you don't want typical users to access. So IIS 4.0 contains a security risk because the product shares and maps the entire Help folder, including NT Help, as a virtual directory in the Default Web site. To address this problem, IIS 5.0 maps the virtual directory Help in the Default Web site to the iishelp folder, not to the help parent folder.

Adminscripts. Adminscripts in IIS 5.0 contains sample .vbs scripts that illustrate using Microsoft Active Directory Service Interfaces (ADSI) to manage the Web server. You can find the Adminscripts folder under inetpub. In IIS 4.0, a similar folder, Adminsamples, resides at %systemroot%system32inetsrv.

Default documents. Installing IIS 4.0 creates the Default and Administrative Web sites. In the Default Web site, IIS 4.0 places a default document that appears when you access your newly installed server. IIS 5.0 doesn't create this default document but instead creates IISStart .asp. When you access IISStart.asp, it checks whether the access request is local or remote. When it's local, IISStart .asp launches localstart.asp. When the request is remote, you see an Under Construction message. IISStart.asp is executed only if no default.asp or default .htm file exists. If you create a default document, IIS 5.0 shows that document at startup instead of IISStart.asp.

IISADMPWD. IIS 4.0's Default Web site contains a virtual folder, IISADMPWD, which holds files that let users change their user-account passwords through a Web browser. If you performed a clean install of IIS 5.0 (i.e., you didn't upgrade from IIS 4.0), the Default Web site doesn't contain the IISADMPWD virtual folder. However, although the virtual folder is absent, the files that let users change passwords through a Web browser exist on the server. To let users access these files, follow the instructions in the Microsoft article "IISADMPWD Virtual Directory Is Not Created During Clean Install of IIS 5.0" (http://support.microsoft.com/support/kb/articles/q269/0/82.asp). Letting users change user accounts through a Web server has security implications. For information about possible security exposures, see the Microsoft articles "Malformed HTR Request Returns Source Code for ASP Scripting Files" (http://support.microsoft.com/support/kb/articles/q260/0/69.asp) and "GET on HTR File Can Cause a 'Denial of Service' or Enable Directory Browsing" (http://support.microsoft.com/support/kb/articles/q267/5/59.asp). Also see Ken Spencer, "Changing Passwords over the Web," page 121.

Operational Changes
Persistent anonymous user account. During installation, IIS 5.0 and IIS 4.0 create the user account IUSR_servername. This account logs anonymous connections to the Web server. For security purposes, IIS 4.0 administrators often remove or rename IUSR_servername. If you try to remove or rename the IUSR account in IIS 5.0, the program recreates the account when you reboot the server. The only workaround is to create and use a different account that doesn't use IUSR in the name. For more information about the IUSR account, see the Microsoft article "Correction and Addendum to Internet Information Services 5.0 Release Notes" (http://support.microsoft.com/support/kb/articles/q254/2/60.asp).

Less reliance on the registry. One of the most significant hidden changes in IIS 5.0 is its almost total reliance on the metabase rather than the registry. The IIS 5.0 metabase contains many registry keys that IIS 4.0 uses. This relocation in IIS 5.0 might not be obvious because the HKEY_LOCAL_MACHINESystemCurrentControlSetServicesInetinfo subkey exists in IIS 5.0 and appears to contain information about the server, just as the subkey in IIS 4.0 does. However, this subkey remains in IIS 5.0 only to provide backward compatibility with the IIS 4.0 Microsoft Management Console (MMC).

WWW Distributed Authoring and Versioning. WebDAV is a standard in progress whose purpose is to extend HTTP to add file I/O capability. Internet Engineering Task Force (IETF) Request for Comments (RFC) 2518 outlines the WebDAV standard, which lets you open, save, rename, search, create, change, and delete files on an IIS 5.0 server from Microsoft Office applications, the Win2K desktop, and Microsoft Internet Explorer (IE) 5.0.

WebDAV is automatically enabled in IIS 5.0, and you can't turn it off. IIS 5.0 constantly monitors all HTTP traffic for WebDAV verbs, including the new Microsoft-only creations (e.g., the Translate header). When IIS 5.0 encounters a WebDAV verb, the Web server invokes the Internet Server API (ISAPI) extension httpext.dll to process the WebDAV request. WebDAV doesn't rely on file extensions to operate, so you won't find httpext.dll in your IIS 5.0 server's application mappings. Although httpext.dll is an ISAPI extension, you can't unmap the extension.

Controlling file I/O on a Web server is the basis of Web security, and WebDAV lets users perform file I/O; thus, WebDAV creates a potentially serious security problem. You can't use port filtering to just stop file access through WebDAV because access occurs through the HTTP port (port 80).

To write files to the server through WebDAV, you need to enable IIS 5.0's Write permission. This permission isn't user-specific, so enabling it lets all users write to the Web. Thus, WebDAV makes NTFS solely responsible for controlling who can access files on the file server. However, enabling IIS 5.0's Write permission doesn't let users modify Active Server Pages (ASP) or other script-mapped files.

To enable script editing, you need to turn on Script source access, the only WebDAV property that you can adjust in IIS 5.0. Figure 1 shows the Default Web Site Properties Home Directory tab. When you select the tab's Script source access and Write check boxes and use a WebDAV-enabled application to open an ASP or other application-mapped script file, IIS 5.0 delivers the ASP source document instead of interpreting the ASP code and sending the resulting HTML. You can set Script source access at the Web site level and for individual pages.

Other concerns with WebDAV include potential Denial of Service (DoS) attacks, locking files, and access to source files. In response to a security concern involving a Microsoft addition to the WebDAV verbs (i.e., the Translate:f command), Microsoft released Security Bulletin MS00-058, "Patch Available for 'Specialized Header' Vulnerability" (http://www.microsoft.com/technet/security/bulletin/ms00-058.asp). For more information about this particular problem, see the Microsoft article "Internet Information Service May Return Source of Active Server Pages File" (http://support.microsoft.com/support/kb/articles/q256/8/88.asp) and "The Translate:f Security Hole" (http://www.4guysfromrolla.com/webtech/081500-1.shtml). You can find more information about other IIS 5.0 security settings in IIS 5.0's online WebDAV documentation.

Application mappings. If you don't understand the difference between the ways that IIS 5.0 and IIS 4.0 handle application mappings, you can create problems for your server. IIS uses application mappings to map file extensions to executables. For example, application mappings direct ASP files to asp.dll. You can add mappings to let IIS use almost any kind of scripting, such as Perl, Rexx, or PHP.

To access the App Mappings tab in IIS 5.0 or IIS 4.0, select the Default Web Site Properties' Home Directory tab. Click Configuration, and in the resulting dialog box, click App Mappings. You can also reach App Mappings through a virtual directory set up as an application.

Figure 2 shows the IIS 5.0 App Mappings tab, and Figure 3 shows the IIS 4.0 version. The labels on the rightmost columns in Figure 2 and Figure 3 show the big difference between IIS 5.0 and IIS 4.0. The IIS 5.0 label is Verbs, and the IIS 4.0 label is Exclusions. By default, IIS 5.0 disallows new verbs in the HTTP specification. When you map applications to executables, you need to specify which HTTP verbs the system allows. IIS 4.0 is the opposite, allowing new verbs by default. You need to specify which verbs the system disallows, or excludes.

If you ignore the App Mappings column headings and specify exclusive verbs such as DELETE and PUT instead of inclusive verbs such as GET and POST, the server will return the error message 403.1 ­ Execute Access Forbidden, with additional misinformation: You have attempted to execute a CGI, ISAPI or other executable program from a directory that does not allow programs to be executed. If you believe the error message, you'll never track down the problem. Auditing won't help you identify it, and neither will Filemon (a file-monitoring program available at http://www.sysinternals.com) or other troubleshooting techniques that search for executable NTFS permissions. Giving the Everyone group full control of the target files also won't solve the problem.

Socket pooling. When you use IIS 4.0 to create a Web site, the Web server allocates TCP sockets specifically for that Web site. For example, if you have 20 Web sites, each with a different IP address, IIS 4.0 dedicates a connection socket to each of those 20 sites, and each socket listens at port 80. This arrangement limits scalability and performance because resources that idle sockets consume aren't available for other sites to use.

In contrast, IIS 5.0 uses socket pooling, which the Web server enables by default for all sites that have different IP addresses and use the same port. Regardless of the number of Web sites using port 80, all sites will share the same set of TCP sockets. This arrangement improves the distribution of server resources.

If your Web sites don't have different IP addresses, you're most likely using host headers to create multiple Web sites on one IP address. Socket pooling doesn't work for host-header sites; it works only for sites that have unique IP addresses. Most online documentation about host headers doesn't make this distinction clear.

IIS 5.0's README file (see the Microsoft article "Contents of Internet Information Server 5.0 Release Notes" at http://support.microsoft.com/support/kb/articles/q250/9/79.asp) describes a hidden feature that relates to socket pooling. If you tune the performance of one pooled-socket Web site, you affect the performance of all the other Web sites in the socket pool. You adjust Web site performance settings on the Default Web Site Properties' Performance tab, which Figure 4 shows.

You can disable IIS 5.0's socket-pooling feature for an individual site or a server. To turn off socket pooling for a server, type the command

cscript c:inetpubadminscripts  adsutil.vbs set w3svc/  disablesocketpooling true

Then restart IIS 5.0. To disable socket pooling for an individual Web site, type the command

cscript c:inetpubadminscripts  adsutil.vbs set w3svc/x/  disablesocketpooling true

where x is the Web site's number. Internally, IIS 5.0 uses numbers­—not Web site names­—to distinguish between virtual Web sites. IIS 5.0 assigns Web numbers in sequence as it creates sites. You can download MetaEdit 2.1 from http://support.microsoft.com/support/kb/articles/q232/0/68.asp and use it to determine a Web site's number. You can also find a Web site's number by typing

cscript c:inetpubadminscripts  findweb.vbs "websitename"

where websitename is the name that the site's Internet Service Manager (ISM) displays. The command is case sensitive.

Logging. If your IIS 5.0 or IIS 4.0 logs don't show the correct time, the problem might be that they're using Greenwich Mean Time (GMT) instead of local server time. The World Wide Web Consortium (W3C) standard calls for GMT, so your log reporting software needs to convert GMT to your local time. To make the conversion, you can use the Convlog utility available from the Microsoft Windows Internet Information Server Resource Kit or the Win2K resource kit.

IIS 5.0 and IIS 4.0 also use GMT to trigger the date rollover and, in some cases, name the log files, which can affect analysis of your Web site traffic. For example, an IIS server in California is in the Pacific time zone, an 8-hour difference from GMT. If the server logs records on a daily basis, you might think that the server would close the current day's log file and start the next day's file at midnight Pacific time. But because IIS uses GMT, the server's log file rolls over at 4:00 p.m. Pacific time, and IIS names the file as if it contains all the traffic for the day. In reality, though, the log holds traffic information from 4:00 p.m. to 4:00 p.m. instead of midnight to midnight.

IIS 5.0 contains a new feature that addresses the log rollover problem. In your Web site's Properties window, select the Web Site tab, select Enable Logging, select W3C Extended Logging Format as the Active Log Format, and click Properties. On the Extended Logging Properties window's General Properties tab, which Figure 5 shows, you can select the Use local time for file naming and rollover check box to cause the log files to roll over according to local time. However, IIS 5.0 doesn't let log-file entries use the local date and time.

You can also set IIS 4.0 to use local time to roll over and name log files, although the process is more complicated than in IIS 5.0. According to the Microsoft article "Log Files Rolled Over According to GMT, Not Local Time Zone" (http://support.microsoft.com/support/kb/articles/q193/6/12.asp), you can type the command

mdutil.exe SET -svc w3svc -i x  -utype UT_SERVER -dtype DWORD  -attrib INHERIT -prop 4015 -value 1

to set the proper metabase key for local time. In this command, w3svc is the name of the Web server section of the metabase, and x is the number of the Web site for which you want to set the logging parameter. You can use this fix on any NT 4.0 server running Service Pack 5 (SP5) or SP4. SP6 fixed the rollover problem.

Pass-through authentication. When you create a virtual directory that maps to a remote share, you need to provide a username and password that the remote system will honor to allow access to the share. Every subsequent access to the virtual directory will occur within the security context of that username and password unless you configure IIS 5.0 or 4.0 to use a logged-on user's credentials instead. Using a logged-on user's credentials to authenticate to the remote share is called pass-through authentication.

To enable pass-through authentication for IIS 5.0, you need to use an authentication method that supports pass-through authentication and create a metabase entry. The authentication methods that support pass-through authentication include Anonymous authentication (with the IIS 5.0 control password disabled), Basic authentication, and Integrated Windows authentication. If you use Integrated Windows authentication and your system is Kerberos-capable, your system will use Kerberos, which supports pass-through authentication. To use Kerberos, your system must meet the following conditions: The client is running Win2K and IE 5.0 or later, the server is running Win2K and IIS 5.0, the client and server are in the same domain or trusted domains, IIS 5.0 is configured to use Integrated Windows authentication, and the Win2K server and the Web resource you're accessing have the same name or you've used the Setspn tool from the Win2K resource kit to register the Web name as a new service principal name.

You can use a script or MetaEdit 2.1 to edit the metabase. The following ASP code enables pass-through authentication for IIS 5.0 on the virtual directory Protected in the Default Web site. You need to substitute the correct Web site number for 1 and the name of your virtual directory for Protected.

<%Dim oVDrSet oVD = GetObject("IIS://" & _  "localhost/W3SVC/1/Root/" & _  "Protected")oVD.UNCAuthenticationPassThrough = TrueoVD.SetIfnoSet oVD = Nothing%>

IISReset. Stopping and starting IIS 4.0 is a complicated process, and you frequently need to restart the Web server because of various hang-ups. Many IIS 4.0 administrators resort to rebooting their servers nightly or using a batch file to restart stopped services.

To address this problem, Microsoft added an IISReset.exe command to Win2K. This command-line routine stops and reliably starts IIS 5.0 and related services. To stop Internet services, use IISReset instead of the Control Panel Services applet. The online documentation states, "You should use the (IISReset) method, and not the Windows 2000 Services snap-in, for restarting Internet services. Because several Internet services run in one process, Internet services shut down and restart differently from other Windows services."

IISReset has several optional parameters that let you control how the reset occurs and specify other actions. For example, to tell the server to reboot if IIS 5.0 doesn't restart after a specified number of seconds, type the command

IISreset /restart /rebootonerror  /timeout:seconds

where seconds is the number of seconds.

If IIS 5.0 stops responding, you can run IISReset through the Win2K Service Control Manager (SCM). To enable this feature, right-click IIS Admin Service in the IIS 5.0 Services snap-in, select Properties, and click the Recovery tab, which Figure 6 shows. Figure 6 contains the default settings, but you can customize recovery actions and timing. In Figure 6, each failure instance (i.e., First failure, Second failure, and Subsequent failures) will cause IISReset to run. In Run file, you define the file that will run after each failure (in Figure 6, the file is C:\WINNTSystem32iisreset.exe). You can specify different actions to occur after the first, second, and subsequent failures; you can also call a custom routine that restarts other processes, makes log entries, or notifies administrators. You can type

iisreset

to display all the options listed in the IIS 5.0 online documentation.

SSL Connections and Client Access Licenses
In a discussion about implementing IIS 5.0, the Microsoft article "Deploying Windows 2000 with IIS 5.0 for Dot Coms: Best Practices" (http://www.microsoft.com/technet/iis/iisdtcom.asp) says, "Dot-com businesses must purchase enough Client Access Licenses (CALs) for all Secure Sockets Layer (SSL) connections."

Win2K requires you to have a CAL for each user that logs on, and the system limits the number of authenticated simultaneous logons to the number of CALs that you've purchased. The Win2K License Logging Service enforces this rule. If you disable this service, Win2K limits you to 10 connections.

Unknown to most administrators, a second counter­—the SSL connection counter­—exists separately from the authenticated user counter. Win2K and Win2K SP1 limit the number of SSL connections, even anonymous ones, to the number of CALs. An SSL session doesn't actually consume a CAL. In other words, if you have 10 CALs, you can have 10 authenticated users and 10 anonymous SSL connections simultaneously. Nevertheless, the limit on SSL connections exists, and if you exceed that limit, you get this message:

HTTP 403.15 - Forbidden: Client Access Licenses exceededInternet Information ServicesThe number of authenticated users has exceeded the number of Client Access Licenses (CAL).

It doesn't make sense that Win2K limits the number of anonymous SSL connections to the number of CALs that you've purchased, and Microsoft Product Support Services (PSS) has released a fix. For information about exceeding CALs in IIS 5.0, see the Microsoft article "Error Message: HTTP 403.15 - Forbidden: Client Access Licenses Exceeded" (http://support.microsoft.com/support/kb/articles/q264/9/08.asp). You can modify the registry to stop IIS 5.0 from checking in with the License Logging Service for permission to create an SSL session. To the HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesW3SVCParameters subkey, add the value name EnableCAL, of data type REG_DWORD and a value of 0. The Microsoft article "What's New in the Windows 2000 Server Licensing Model" (http://www.microsoft.com/windows2000/guide/server/pricing/changes.asp) explains that you won't violate your license agreement with Microsoft if you don't have as many CALs as you do anonymous SSL connections.

SSL and Wildcards
In IIS 4.0, if you host multiple sites or multiple servers that end in the same domain name (e.g., mysite.com), you can use a wildcard (e.g., *.mysite.com) in the common name (CN) portion of a certificate and bind that certificate to all the sites or servers. (You can use wildcards if your licensing permits multiple use.) Unfortunately, IIS 5.0 doesn't support CN wildcards. If an IIS 5.0 server's CN doesn't match the DNS name, a user's browser will display a message saying the certificate doesn't match the requested site and asking whether the user is sure he or she trusts the site. This isn't the type of message that e-businesses want users to see.

Microsoft plans a hotfix to correct IIS 5.0's inability to use CN wildcards. (Win2K SP1 doesn't fix the problem.) For more information about CN wildcards, see the Microsoft article "Accepted Wildcards Used by Server Certificates for Server Authentication" (http://support.microsoft.com/support/kb/articles/q258/8/58.asp).

Upgrade to IIS 5.0
Many other differences exist between IIS 5.0 and IIS 4.0, including changes in ASP, ODBC connection sharing, COM+, MetaEdit, security wizards and templates, and the registry. Most changes in IIS 5.0 are significant improvements and are clearly Microsoft's responses to the lessons learned in IIS 4.0. I encourage you to upgrade to IIS 5.0 as soon as feasible.

However, when you upgrade your system, remember that IIS 5.0 contains significant and hidden differences that can affect how you implement security, tuning, and coding. Now that you know about these changes, your IIS 5.0 upgrade can be more reliable, secure, and enjoyable.