IIS Informant - 09 Jun 2000

I'm using IIS 4.0 with Service Pack 6a (SP6a). I set up the Web site for Anonymous access, but IIS prompts users to enter a username and password. If I switch to Basic or Windows NT Challenge/Response authentication, users can log on and access the server, but I don't want to require that. What's the problem with Anonymous access?

Authentication can be surprisingly tricky. One complication is in the IUSR account and how it interacts with User Manager. In IIS 3.0, you had to manually match the IUSR password in User Manager with the password in the Internet Service Manager (ISM) tool. In IIS 4.0, Microsoft added a feature that lets IIS control the password. This process is called password synchronization, and it's enabled by default. Password synchronization is supposed to make password administration easier by letting administrators change the password for the IUSR account in User Manager without having to make the same change in the Microsoft Management Console (MMC) snap-in. The process seems simple enough, but it involves more than meets the eye.

You turn password synchronization on or off with a check box on the Anonymous User Account dialog box, which you access from the Security tab of an IIS virtual Web site's Properties dialog box. Figure 1 shows the Allow IIS to control password check box in IIS 5.0. The check box in IIS 4.0 is in the same place but has a different name—Enable automatic password synchronization. Also from this dialog box, you can select a different user for your Anonymous account, and in fact Microsoft recommends this for security considerations. For example, you could specify an account on a domain controller, but be aware that IIS doesn't support this configuration (see the Microsoft article "Password Synchronization and Local User Accounts Information" at

http://support.microsoft.com/support/kb/articles/q183/7/22.asp). Ideally, the Anonymous account is local to the IIS server, or password synchronization might not work correctly. See the IIS Help files for more important information on this topic.

The problem with password synchronization is that you won't have a problem until something changes. For example, if you delete and recreate the IUSR account, IIS generates a new SID; as far as NT is concerned, the account is completely new, even if the account name is the same. To avoid confusing the password-synchronization process, you need to browse to the new IUSR account and specify it as the Anonymous account to resynchronize.

These problems aside, some even more serious side effects of the password synchronization feature exist. As I mentioned earlier, by default, IIS selects the Enable automatic password synchronization (IIS 4.0) or Allow IIS to control password (IIS 5.0) check box. IIS then becomes the authentication agent through a process called subauthentication (which iisuba.dll handles). The side effect of this process is a big deal: Because the logon occurred as a result of a subauthentication process, the logon is a network logon. Users who log on in this way become members of the Network built-in group.

So what's the big deal? Network logons have the same problems as NT Challenge/Response authentication logons, which can keep IIS from authenticating a user to other network resources. When that user tries to access the network resource, IIS prompts him or her to enter a username and password that the remote resource can validate.

The good news is that you can prevent this prompt from occurring by clearing the password control check box. IIS then hands off the task of authentication to the LogonUser() API instead of performing the subauthentication task. This handoff results in a local logon. Users who log on in this way become members of the Interactive built-in group. Strangely enough, just clearing this check box can provide Anonymous users with access to network resources they can't otherwise reach.

You'll find the built-in Interactive and Network groups in the list of users and groups that appears when you apply NTFS permissions. A lot of NT administrators use these special groups to control user access. Understanding how the password control check box moves Anonymous users from one group to another can help with debugging and authentication planning.

If you turn off password control, you need to manually synchronize passwords within User Manager and IIS. This process is as simple as making sure that the username and password listed for the Anonymous account in IIS is the same as that in User Manager. If you change it in one place, make the same change in the other.

I have about 50 sites set up with IIS 4.0, SP6a, and Microsoft FrontPage Server Extensions. I have only five IP addresses, so I'm using host headers to route users to Web sites, which is working well. What do I need to do to let non-FrontPage users update their sites through FTP?

As you probably know, FTP doesn't support host headers, so FTP sites can't use the host headers method to create multiple Web sites. FTP has a built-in feature that you can leverage to help, but it involves having a user account for each FTP user. Because you're using FrontPage, you probably already have an account for your users. Here are the steps for accessing this feature:

When you've created the user group and granted permissions, create a virtual directory within the FTP server with the same name as the user account. (This name is case sensitive.) This step is the key to sorting users into specific folders. In the path for the virtual directory, specify the location (e.g., the target folder) to which the user will upload files. In your case, this folder will have the same path as the Web folder.

On the FTP Home Directories tab, which you access by right-clicking the FTP site in the IIS snap-in and selecting Properties, be sure to grant Write permissions. On the FTP Security tab, clear the Allow only anonymous connections check box. Removing this option requires the user to provide a username and password. Check the NTFS permissions on the target folder to be sure that the user has Change or Read/Add special NTFS permission.

That's it. Now when your users log on, they'll automatically go to their FTP directory. When you use an FTP client, don't be surprised if you don't see the virtual directories you created: They don't show up. You can, however, access the invisible virtual directory as if it were there.

How do you add the icons that show up in front of the URL in Microsoft Internet Explorer (IE)? They seem to appear in the URL field and Favorites listings of only certain Web sites, so apparently you must perform some action on the Web server.

With IE 5.0, you can have your company or Web site logo appear in the Favorites list and Address bar in front of the URL. However, the graphic appears only if users place your site in their Favorites list.

First, you have to create an .ico (icon) graphic file of exactly 16 x 16 pixels. You'll need a graphics editing program that lets you save as an .ico file, or you can use one of the many icon editors available as shareware.

When you have your perfect icon, save it with the filename webicon.ico in the root directory of your Web site. I also recommend placing it in any other directory your users might bookmark. If you want to use a different name or location, you need to tell IE where the name and icon file are located:

The link to the icon file must be in every page that you think users will bookmark.

Because this feature is available only when a user bookmarks a page, you might want to encourage your users to create bookmarks. You can find a snippet of code to get you started on a button for this purpose at http://msdn.microsoft.com/workshop/author/dhtml/howto/shortcuticon.asp.

I have a portal that I used Active Server Pages (ASP) to develop. A few days ago, I received an email message that the site was open to attack and the server administrator should shut down the hit counter. I think this problem is the result of the bug in webhits.dll. Can you tell me what this bug is and what measures I can take to make the portal safe from attacks?

This particular problem has an involved history. Here's a quick summary. First, this problem involves Microsoft Index Server, not a hit counter. Because users commonly access Index Server through IIS, the problem appears to be an IIS vulnerability. IIS is the vehicle, but Index Server is the problem. You can use ASP to query Index Server, which returns the resulting set to IIS in such a way that the words used in the query are highlighted. This way, you can quickly see the keywords you were looking for in the abstracts or short descriptions of each item displayed as a result of the query. Webhits.dll is responsible for appropriately highlighting the returned results.

Microsoft announced two problems with Index Server simultaneously. One problem was that users could potentially see files they shouldn't be able to see. Microsoft gave this exploit the very fancy name Malformed Hit-Highlighting Argument vulnerability. This problem relates to webhits.dll. The vulnerability is that users can request a file through Index Server that they shouldn't be able to see, one that is outside the Web server boundary. The file and the Web server must be on the same computer and on the same logical drive. (For information about problems with the hotfix for this vulnerability, see the sidebar "Problems with the Malformed Hit Hotfix.")

Microsoft released a patch to fix this problem for Index Server 2.0 and 3.0. The company then announced that NT 4.0 users could exploit the webhits.dll problem, even if you'd applied the patch. This problem was more serious than the original problem. Users could see the content of server-side files (e.g., ASP files), which is a big concern because information about security methods, pathnames, and even passwords can be in these files. You can find information about how to check whether your site has this problem at http://www.aspynews.com/aspynews/issue2.asp.

The second problem has a similar two-stage history and applies only to Index Server 2.0 and NT 4.0. The problem here is that if users make a request for something like http://www.iisanswers.com/xyz/query.idq but no such file exists, then instead of seeing http://www.iisanswers.com/xyz/query.idq not found, they see C:inetpubwebrootxyzquery.idq not found. This message reveals a bit of the Web site's underlying structure, which you don't want a would-be intruder to see. The patch that initially fixed the webhits.dll problem also fixed this problem, but as in the case of the webhits.dll vulnerability, additional ways to exploit the file not found problem appeared after the initial patch release.

Microsoft has updated the patches to include all known aspects of these two problems. For the patches and complete information about these vulnerabilities, go to http://www.microsoft.com/technet/security/bulletin/ms00-006.asp.