IIS Informant - 07 Sep 1999

Can I remove the default Web site? The IIS documentation sounds as if IIS requires it.

According to the Microsoft IIS team, you can remove the default Web site; however, you might not want to. Some features, such as Help and the Certificate Administration (CertAdm) virtual directory, operate through the default site. In addition, the Secure Sockets Layer (SSL) requires that you have the default Web site if you want to set up multiple Web sites within one IP address.

Because incoming requests (including the header) are encrypted, IIS must first decrypt the header to route the request to the appropriate Web site. If you remove the default Web site, you must use a different IP address for each Web site. Thus, you don't want to delete or rename the default Web site. Such a change can have unintended consequences and might limit your future options.

My company runs Microsoft Internet Explorer (IE) 5.0. Users complain that Web pages occasionally download only partially. Having the users refresh the pages sometimes fixes the problem; other times, it doesn't. The network appears stable, so I'm at a dead end. Do you have any ideas?

Users have recently discovered the same problem in IE 5.0. If an unexpected pause in the data stream to the browser occurs, IE 5.0 can simply stop rendering the page. Refreshing the page might correct this problem or cause the page display to stop in a different place. This problem is a headache because you can't remedy it on the server side; you must apply a patch to IE 5.0 on each client. The offending DLL is wininet.dll. You must update versions of this DLL earlier than version 5.00.2614.3400.

To locate the file, instruct each client to look in the default Windows system folder (C:windowssystem for Windows 98; typically C:winntsystem32 for Windows NT). Right-click the default Windows system folder. Select Properties and the Version tab. As Screen 1 shows, I need to apply this update to my Win98 R2 system. Details about this problem and its fix are in the Microsoft article "Partial Web Page Is Rendered When HTTP Stream Terminates Early" at http://support.microsoft.com/support/ kb/articles/q226/5/50.asp.

Sometimes my Active Server Pages (ASP) application is unstable. What resources are available to debug the application?

Debugging ASP and IIS 4.0 can be frustrating. One common ASP error, ASP 0115, is an access violation error. This error occurs when a DLL in IIS tries to use memory already in use or free memory that is already free. No one cause exists because different sites use different objects in different ways. The error takes the form

error 'ASP 0115'Unexpected errorWeb_nameASP_file_name.aspA trappable error occurred in an external   object.The script cannot continue running.

This message tells you the page on which the error occurred and that it occurred in an external object. (With ASP, any object you create with server.createobject is an external object.) If you have suspicions about the error's cause, you can remove suspect objects and see what happens. However, on a complex page, that approach has limited value.

To get more information, you can use the IIS Exception Monitor. The monitor attaches to the IIS process and reports what occurs. You can download the monitor from the Microsoft Developer Network's (MSDN's) Online Web Workshop at http://msdn.microsoft.com/workshop/ server/iis/ixcptmon.asp. This page also provides a detailed look at how to install and use the IIS Exception Monitor for debugging. In addition, Microsoft can use the IIS Exception Monitor remotely to debug your system, if required.

Another alternative is to use Visual Studio (VS) Service Pack 3 (SP3) or later. VS supports object tracing and debugging in ASP pages.

Given all the patches and updates that are available, what is the correct sequence in which to install and update IIS 4.0? Microsoft seems to have conflicting information about it.

Typically, you're supposed to reapply a service pack after you update an NT system, but this process becomes complicated with IIS 4.0 because the service pack is part of the NT 4.0 Option Pack. In addition, the multicomponent aspect of IIS makes keeping up with the required updates a significant part of an IIS administrator's job.

Microsoft provides conflicting information about the IIS installation and update sequence. For example, Microsoft told one administrator to follow the process discussed in the document "Sequences for Installing and Configuring Server Applications Running on Windows NT Server 4.0" (http://www.microsoft.com /ntserver/nts/deployment/ planguide/install.asp). This document recommends five steps:

However, Microsoft told another administrator to follow different steps:

I checked with several other IIS administrators. Together, we came up with the following recommended sequence:

Many people don't read README files. However, SP5's README file is required reading because it tells you about two potential problems with applying SP5 to IIS:

Potential problem 1. If a well-known third party didn't issue your root certificate, you might need to reinstall the root certificate after applying SP5. Fortunately, you no longer have to use the iisca.exe tool. Instead, you can follow these steps:

Potential problem 2. When you access the Certificate Server's administrative Web pages or logs to set the Program attribute on the CertAdm virtual directory, you might get an error. To properly set the Program attribute, follow these steps:

Can I move the metabase to a different location?

Yes—and I recommend that you not only move the metabase but also rename it. These measures increase the security of your Web server because snoops and intruders won't be able to find the metabase as easily. By default, IIS installs metabase.bin in the inetsrv directory. To rename and move the metabase, make this Registry modification:

Because of my security setup for IIS 4.0, I can use only NT Challenge/Response authentication. I want to route different users to different locations based on their logon names. For example, if a user with the logon name John logs on, he would go to page john.htm and a user with the logon name Frank would go to page frank.htm. I don't want to make the URLs visible. How can I set my users up this way?

You can use the code in Listing 1 to route users based on logon names. This task is fairly easy with ASP if you don't mind sending HTTP redirects. If you don't want to modify the ASP code for each new user, you can use the code in Listing 2 instead.

If you use NT Challenge/Response authentication, the username format is domainusername. If the user accesses the page anonymously, the username comes in as blank, not IUSR_computername. So make sure you set the permissions and authentication scheme accordingly. If you have many users, you can store the names in a database with a table associating the usernames with redirect paths. (Thanks to Daniel Longley at Nextwave Consulting Group for this information.)

I use the World Wide Web Consortium (W3C) Extended Log File Format to capture IIS activity. The logs, however, don't show the correct system time. If I change the log format to the National Center for Supercomputing Applications (NCSA) format, the log records the correct system time. How can we get the W3C Extended Log File Format to show the correct time?

Phillip M. Hallam-Baker, principal consultant at VeriSign, developed the W3C Log File specification. A so-called feature of the W3C specification is that it records times in Greenwich Mean Time (GMT). So, the W3C Log File format won't show your system time; fortunately, the other log formats don't have this specification.

I've read that intruders can gain administrative access to IIS without having administrative credentials. How can I prevent this potential security breach?

Last year, Microsoft announced the problem that MDAC allows unauthorized access under certain rather common conditions. Because the problem lies in the component system that supports IIS and not in IIS, this problem is more of a system weakness than a bug. For the same reason, firewalls and other forms of protection are ineffective against this problem. The fix lies in configuration changes. Some major companies using IIS haven't made the changes and are still vulnerable. Many other sites are probably vulnerable, too.

The difficulty is in the Remote Data Services (RDS) component of MDAC, specifically the DataFactory object. Even if you don't use RDS, you might still be vulnerable because RDS is often installed by default. Furthermore, the example Web pages that IIS automatically installs use the DataFactory object. Thus, one of the configuration changes is to remove these example pages. Microsoft said it never intended for customers to put the example pages on their production servers. Too bad the installation process doesn't ask you whether you want to install those pages.

You must also make other configuration changes. You can find complete details at http://www.microsoft.com/security/ bulletins/ms99-025.asp.