IIS Informant - 20 Dec 1999

We would like to use Active Server Pages (ASP) scripting, but we don't want our script files to end in .asp. How can we process custom file extensions as if they were .asp files?

You can have custom file extensions of basically any sort and map them as .asp files. To choose a specific file extension, highlight the path to asp.dll and the exclusions. Click Add to bring up the next screen, which Screen 1 shows. Enter the path to asp.dll, the exclusions, and the custom file extension you're using as an .asp file (e.g., C). Select the Script engine check box to obtain the ability to assign Script permission instead of Execute permission to your Web site, thereby providing a bit more security.

I'm moving some ASP files from Personal Web Server (PWS) to IIS 4.0. I placed all the .asp files into a virtual directory and registered the .dll files I'm using. When I try to access the .asp pages, I see the The page cannot be displayed message. Do I need to dump all the .dll files into C:\winnt\system32\inetsvr, or can I just put them in the virtual directory?

When you move files from PWS (the scaled-down version of IIS that is on Windows NT Workstation or Windows 9x), you must consider many steps. One of the most commonly overlooked steps is that you specify the virtual directory (or Web site that contains the virtual directory) as an application and give it Script permission. From the Home Directory tab on the Web site or the virtual directory Properties page, click Create to set up your Web or virtual directory as an application. At the same time, enable Script permissions so that IIS can execute your ASP scripts.

Administrators need access to some files no matter where the administrators are. When I'm working at the server, I have full access to these files without having to log on as an Administrator. When I log on as an Administrator at a workstation and access IIS, I receive a Permission denied message. Why is IIS refusing Administrator access from a remote workstation?

This problem can arise when you permit Anonymous access mixed with other authentication modes. When you enable Anonymous access, users accessing the server from their browser automatically log on to IIS as an anonymous user (typically IUSR_computername). When you've installed IIS, IIS automatically creates this account in the user database. The notion of an anonymous user on IIS is sort of a misnomer. All access to NT must occur in the context of a bona fide user account. This requirement poses problems in the case of an Internet-accessible Web server because creating an account for every potential user simply doesn't make sense. Instead, if you enable Anonymous access, all users log on using one predefined user account. Users logged on in this way have only the permissions granted to the IUSR account, which you want to be as restrictive as possible.

Administrators, however, typically need more extensive permissions than you grant the IUSR account. After you log on as an anonymous user (which will occur automatically if you enable this option), to change to an administrative user account, you need to open a file or folder that the IUSR account doesn't have permission to see. When you open such a file or folder and you've enabled Basic or NT/Challenge Response authentication (presuming you have an NT/
Challenge Response-capable browser), you must enter credentials that will provide access to the resource. Then you can enter your administrative username and password.

Now, let's go to the problem. If you let users change from Anonymous access to their user account, be sure the newly authenticated users have access to the same resources as the anonymous users. Otherwise, your authenticated users might be in for a surprise when they get an Access denied message while attempting to use resources any anonymous user can access. Here's one way this can happen.

Let's say the IUSR account has access to the root folder wwwroot. Under this folder is a subfolder called Restricted that only Administrators can access. In the Restricted folder is an .asp file called adminonly.asp that references Include files. (An Include file is an external file that a referenced source file contains.) Although the main .asp file is in the Restricted folder, the Include files are in the directory above (the wwwroot folder). As Table 1 shows, the anonymous users can access the wwwroot folder, but not the Restricted folder.

In this situation, when an anonymous user attempts to access the Restricted folder, he or she must provide a valid username and password. After the user provides this information, IIS authenticates the user and, if the user has Administrator access, provides access to adminonly.asp. The Administrator is in for a surprise, however, because Administrators can't access the Include files adminonly.asp uses. As a result, errors are certain.

The moral of the story? If you require users to authenticate, consider granting group Domain Users (on a domain controller) or Users (on a member server) access to the same resources you've granted anonymous users. In this way, the authenticated users won't lose access to resources they were able to access as anonymous users.

When I begin to install IIS 4.0 and I've already installed NT Service Pack 4 (SP4) or SP5, I receive a message that says Microsoft has tested IIS 4.0 only with SP3 and the question Do you want to continue? Can I proceed safely? I can't locate any clear instructions from Microsoft.

You can proceed safely. This message appears when you install or reinstall the NT 4.0 Option Pack on an NT system with SP3 or later. For a more detailed explanation, see the Microsoft article "IIS 4.0 Upgrade Error on Servers with Windows NT 4.0 SP4" (http://support.microsoft.com/
support/kb/articles/q199/9/18.asp). For information about upgrade paths for new installations, see "IIS Informant" (October 1999).

After we updated our IIS system from SP3 to SP4, Certificate Server failed to work. The installation apparently damaged or deleted the certificate store for IIS. Have you heard of this problem?

The problem you're referring to has to do with using root certificates other than those that the Certificate Authorities (CA) VeriSign and Thawte issue. Companies using IIS for an intranet don't need to purchase a certificate because their security needs are strictly internal.

Cases such as this are well suited for using a self-signed certificate. Unfortunately, when you apply SP6, SP5, or SP4, those self-signed certificates simply disappear. In that event, you must reinstall your root certificate.

If this scenario sounds like your situation, the following procedure will reinstall the root certificate:

If you're using IE 5.0:

For more information about installing root certificates, see the Microsoft article "Using Secure Sockets Layer, Root Certifying Authority Certificates, and Iisca.exe" (http://support.microsoft.com/ support/kb/articles/q216/3/39.asp).