IIS Informant - 07 Sep 1999

Downloads
7174.zip

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:\windows\system for Windows 98; typically C:\winnt\system32 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 error
\Web_name\ASP_file_name.asp
A 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:

1. Install NT Server 4.0 with IIS 2.0.
2. Install SP5 or SP4 on the NT Server system.
3. Install IE 4.01 with SP1 or later.
4. Install the Option Pack, and choose Upgrade Plus (upgrades to IIS 4.0).
5. Reapply SP5 or SP4 on the NT Server system.

However, Microsoft told another administrator to follow different steps:

1. Install NT Server 4.0.
2. Apply SP3 to the NT Server system.
3. Install IE 4.01 with SP1 or SP2.
4. Install the Option Pack.
5. Apply the FrontPage 98 Server extensions hotfix.
6. Install Microsoft Data Access Components (MDAC) 2.0 SP2 if you're using Microsoft SQL Server 6.5 (MDAC 2.1 and hotfixes for SQL Server 7.0).
7. Apply SP5 to the NT Server system.

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

1. Install NT Server 4.0.
2. Apply SP5 to the NT Server system.
3. Install IE 4.01 with SP1 or SP2.
4. Install the Option Pack.
5. Apply the FrontPage 98 Server extensions hotfix.
6. Install MDAC only if required for your installation; otherwise, uninstall MDAC. If MDAC is required, install MDAC 2.0 SP2 if you're using SQL Server 6.5. Install MDAC 2.1 and hotfixes if you're using SQL Server 7.0.
7. Upgrade to IE 5.0.
8. Apply SP5 to the NT Server system.

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:

1. Launch IE 4.0 or later on IIS.
2. Browse to the root certifying authority certificate that you want to add. For Microsoft Certificate Server, go to http://your_server/ certsrv/certenroll/cacerts.htm.
3. Click the desired root certifying authority certificate.
4. Select Open this file from its current location, and click OK.
5. Click Install Certificate.
6. Click Next after the Certificate Manager Import wizard starts.
7. Select Place all certificates into the following store.
8. Click Browse, and select Show physical stores.
9. Expand Trusted Root Certification Authorities.
10. Select Local Computer, and click OK.
11. Click Next and then click Finish to complete the changes.
12. Restart your Web server.

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:

1. In the Microsoft Management Console (MMC), double-click the default Web site.
2. Right-click the CertAdm virtual directory.
3. Click Properties.
4. On the Virtual Directory tab in Application Settings, click Create.
5. Click Apply and OK.

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:

1. Stop IIS, and log on as an administrator.
2. Find the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\INetMgr\ Parameters Registry key.
3. Add a REG_SZ value named MetadataFile. In that value, specify the complete path, including drive letter and filename, to the new metabase location or filename.

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 \domain\username. 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.