I'm trying to tighten up security to one area of my Web site by restricting access to only those browsers coming from military (.mil) domains. I'm just guessing that you format that domain name entry as .mil, *.mil, /.mil, /mil, or maybe just mil. No matter how I state the .mil domain, everyone is blocked—even those browsers on fixed IP-address machines that I know are registered in the DNS as army.mil. In IIS 4.0, what is the proper format for entering domain names in the IP Address and Domain Name Restrictions window of the Directory Security tab?
This answer has two parts. First, whatever domain name you enter in this window must be able to resolve from IP address to DNS. As a result, you can't restrict access to entire top-level domains (the highest subdivision of an Internet address signifying what kind of entity owns the domain—e.g., .com, .org) because they don't resolve to an IP address through DNS.
Second, using domain names to grant or deny access to IIS is probably not a great idea. When a browser contacts the IIS server, the server uses the client's IP address to do a reverse DNS lookup on every access to the server to see whether the server can grant permission. This process can take a while, so if you have to use this technique, be sure you have a caching DNS server nearby. Also, this technique in IIS isn't a rock-solid implementation. If you set up the IP Address and Domain Name restrictions box so that it reads By default, all computers will be denied access except those listed below and you use a domain name instead of an IP address in the excepted list, what occurs if IIS can't resolve the name? IIS might grant access anyway, even though you selected the deny all except check box. For more information about this problem, see the Microsoft article "IIS May Permit Clients with an Unresolved IP Address to Connect" (http://support.microsoft.com/support/ kb/articles/q241/5/62.asp).
A rock-solid solution would be to write an Internet Server API (ISAPI) filter that filters traffic to your site. In an ISAPI filter, the raw HTTP header is easily parsed, and you could redirect non-.mil domain visitors to a page that explains why they can't access the site. For a C++ programmer, writing an ISAPI filter is easy and well documented. If you don't want to write your own ISAPI filter, check out Flicks Software's AuthentiX (http://www.flicks.com): AuthentiX filters uses wildcards to filter by domain name.
My IIS server stopped and won't start up again. After trying many times to recover, I believe my metabase is corrupted. Unfortunately, no backup metabase exists. Do I have to start over?
You have one hope, and it's a good thing you asked. Most IIS administrators don't know this, but when you update the metabase, IIS makes a temporary backup of the metabase during the update process. The temporary backup is just that—temporary—and during the usual course of events, IIS deletes the metabase after the update is complete. However, if something went wrong during the update, which could be the cause of the corruption in the first place, the backup might still be present. This temporary metabase backup file, named metabase.bak, is in the \%systemroot%\system32\inetsrv folder. If you get lucky and find it there, use the following procedure to restore it:
- Stop IIS and all related services.
- Rename the current metabase metabase.badbadbad (or equivalent).
- Rename the good metabase (i.e., metabase.bak) metabase.bin.
- Restart IIS and all related services. (Reboot just to be sure everything gets loaded properly.)
If this process doesn't get you going, you're looking at completely uninstalling Microsoft Internet Explorer (IE) and the Microsoft Windows NT 4.0 Option Pack, then deleting metabase.bin and reinstalling from the ground up. For information about this problem and the restoration process, see IIS Informant, March 2000, and the Microsoft article "How to Manually Restore the Metabase When No Proper Backup Exists or the MMC Won't Start" (http://support.microsoft.com/support/ kb/articles/q234/4/29.asp).
I've created a secure page on my IIS 4.0 server that users must use HTTP over Secure Sockets Layer (HTTPS) to access. The problem is that when users click the links to go back to the main page, they're still in the Secure Sockets Layer (SSL) connection. How can I return them to the main menu and drop the SSL link?
When you create a secure connection, IIS will maintain it until you explicitly disconnect it. To disconnect a secure connection, enter a fully qualified name on the return link (e.g., <a href="http://yourservername.com/yourhomepage">) instead of a relative link (e.g., <a href = "/yourhomepage"). If you use the relative link, the HTTPS protocol will still be active. Specify HTTP in the link to force the server to create a normal HTTP connection.
One of my sites has virtual directories that individually authenticate using Basic authentication and NTFS access control. I created specific domain user accounts that require access to specific virtual directories. I granted these users Read permissions on the individual NTFS directories supporting the virtual directories, which works well: With Basic authentication, the Web site prompts for a logon, I use the domain account name and password, and I'm in. The problem is that the Microsoft Management Console (MMC) shows the Stop sign with an Access Denied error for each virtual directory. The only other users with access to the physical directories are the Domain Administrators group and the Administrators local group of the IIS server. Any ideas about what user or group the server is looking for? Everything seems to work fine, but I really don't like seeing those Stop sign errors in my MMC.
The last time I saw those Stop signs, it was because the virtual directory setting pointed to nonexistent directories, but that's not your problem. As you say, permissions are the most likely culprit. However, the Stop sign suggests that the System account doesn't have access to something that it needs. As a result, you might need to grant access to the System account.
When I was researching this problem, I conducted a few simple tests that yielded some interesting results. The experiment was to see what would happen when I created a virtual directory that was mapped to a folder I wasn't authorized to access through NTFS permissions. On an NT server running Service Pack 6a (SP6a) and MMC 1.1, I created a folder called TESTFOLDER on an NTFS drive. I then created a virtual directory called TEST that I mapped to TESTFOLDER. I created a user named Joe but didn't add him to any groups or give him any special rights. In each case, I varied the permissions on TESTFOLDER as indicated and obtained the results you see in Table 1 (in conducting the tests, I was logged on with Administrator rights).
Interestingly, if you create the virtual directory without error and then change the permission back to only Joe, you might expect the Stop sign condition to reappear. However, the sign doesn't reappear, which leads me to hypothesize that the Stop sign condition occurs only when an internal error of some sort has occurred, such as an incomplete or incorrect entry in the metabase.
I'm using Microsoft FrontPage 2000 on an IIS 4.0 server with SP6a installed. Authors are unable to access their sites unless they're members of the Administrator group. I'm using Basic authentication and directing users to individual folders based on their logon names. Short of making the users Administrators, what can I do to fix this problem?
IIS has many features that help administrators manage a Web server. However, FrontPage is a departure from a centralized administration strategy in that Microsoft designed it to allow Web site administration from the client side. As a result, many questions arise when you install FrontPage Server Extensions on your server.
When you create a FrontPage Web site within IIS, FrontPage also creates several local groups on the NT server hosting the IIS server:
<Websitename> Authors <Websitename> Browsers <Websitename> Collaborators <Websitename> Admins
(Note that you can prevent the wizard that creates the FrontPage Web site from creating these groups by clearing the Create local machine groups check box.)
You can populate these local groups with users or global groups and use NTFS permissions to grant them various levels of access to the FrontPage Web site. The difference between this process and traditional NT user and group management is that if you make someone an administrator for a FrontPage Web site, that administrator has the ability to control membership in other groups for that FrontPage Web site, even if he or she doesn't have the authority to use the User Manager tool (or User Manager for domains) on the IIS server itself. Furthermore, designating a user or group as a Web Site Operator on the Operators tab in the MMC doesn't limit this control. In other words, the FrontPage Web site administrator is a unique form of administrative delegation that doesn't integrate well with preexisting systems.
Another oddity of FrontPage administration is that it's an all-or-nothing prospect. If you're a FrontPage Web site administrator, you can administer the entire FrontPage Web site. Whatever permissions FrontPage grants to you apply sitewide, which isn't acceptable in cases in which sensitive material needs to be more closely guarded. In this event, you have two choices—creating a new FrontPage Web site as a subweb or manually maintaining the permissions:
- Creating a subweb—By creating a subweb, you have a new administrative entity that you can manage separately. However, creating a subweb can pose challenges because the process also creates new groups in User Manager to maintain. Creating an integrated design with FrontPage presents further challenges.
- Maintaining permissions manually—Instead of creating a subweb, you can elect to maintain permissions manually. Note that you must inform FrontPage of your intent by going to the MMC, right-clicking your Web site, and selecting Properties. Click the Server Extensions tab, and select the Manage permissions manually check box, as Screen 1 shows.
IIS servers with many FrontPage Web sites can automate the process of creating Web sites for new clients. Interestingly, FrontPage has a built-in lightweight mode that can provide connectivity to FrontPage clients, but it doesn't have the built-in security handling I mentioned above. For more information about customizing FrontPage Server Extensions, see the Micosoft article "Adapting FrontPage Server Extensions for Large Web Presence Providers" (http://officeupdate.microsoft.com/frontpage/wpp/serk/adadv_11.htm).
Now, back to the original question. In addition to the settings on the individual Web sites, a set of shared routines exists at C:\program files\
common files\microsoft shared\web server extensions\40. FrontPage 2000 Server Extensions installation creates this folder. According to the Microsoft security document "How FrontPage Authenticates on IIS" (http://officeupdate.microsoft.com/frontpage/wpp/serk/scwin_5.htm), this folder holds a set of FrontPage Server Extension DLLs that by default receive set permissions so that anyone can access them.
I performed tests on two IIS servers by installing the server extensions on a clean installation of NT and IIS and on a live server that has tightened security. After the installations, I checked the permissions of the various files and folders under the newly created C:\program files\common files\microsoft shared\web server extensions\40. The check revealed that for the most part, these files and folders inherited the permissions of the parent folder. On the fresh installation, Everyone Full Control (which is the NTFS default) was still in force. On the more secure server, Administrator Full Control was the only permission on most of the contents. In this case, the only user with access to the FrontPage Web sites would be someone logged on as an Administrator. The server extensions installations didn't loosen the security on the shared folders to provide access for all users, as the documentation had suggested. In addition, running the Check FrontPage Web utility from the MMC and electing to tighten permissions when prompted didn't change the settings.
The point here is that if, on your server, you've tightened permissions on the C:\program files folder, which contains the Web Server Extensions folder, then users might not have access to the FrontPage DLLs that permit them to author, browse, and administer the site. Also, keep in mind that when using Basic authentication, authors must have the right to log on locally. Furthermore, when you manage FrontPage permissions, you need to use the client-side tools to ensure that FrontPage, IIS, and NT are all working together.
There's a lot to know about FrontPage Server Extensions. IIS administrators would be well advised to read up on the details before installing the extensions. You can find some of those details at http://officeupdate.microsoft.com/frontpage/wpp/serk/apndx04.htm.
IIS Administrator has almost-monthly articles about FrontPage (see especially Marnie Hutcheson, "FrontPage Server Extensions Make IIS Administration Easier," January 2000). Other valuable resources include
- http://www.microsoft.com/technet/iis/frontpg.asp
- http://msdn.microsoft.com/workshop/languages/fp/2000/ fp2ksecuritywp.asp
- http://msdn.microsoft.com/workshop/c-frame.htm#/workshop/ management/default.asp
- Chapter 8 of the IIS 5.0 Resource Guide (Note that although this answer relates to IIS 4.0, the same problems are applicable to IIS 5.0.)
