IIS Insider - November 2003

  • Article

By Brett Hill

How To Verify IIS Lockdown Tool Has Been Run

Q: How do I verify that the IIS Lockdown Tool has been run on a Windows 2000 Server?

A: It is one thing to tell if the tool has been run and another to tell if it is still in force. In other words, when you first run the Lockdown tool, certain files and settings are created that tell you that certainly the Lockdown tool was run on the server. However, just as easily as you can run the tool, you can undo it. Consequently, if you want to ascertain that the tool is actually in force, it is insufficient to test only that the tool has been run on a server.

If any one of the following is true, the Lockdown tool has been run:

  • The local groups Web Anonymous Users and Web Applications are present. These groups are created if the tool is run, but not removed if the tool is run again to undo the lockdown.
  • Log files oblt-log.log and oblt-rep.log are present in <%systemroot%>\system32\inetsrv. To test if the lockdown is still in force, check for the existence of the files oblt-undo.log and oblt-undone.log. If these files are absent, of if they are present and the date and time stamps are earlier than oblt-log.log, then the lockdown is in place.
  • The registry key HKLM\Software\Microsoft\IIS Lockdown Wizard is present

In addition, the Microsoft Baseline Security Analyzer can let you know if the Lockdown tool has been run on local or remote IIS server, but cannot let you know if the tool was undone.

Does IIS 5.1 Installation Require the Windows XP Professional CD-ROM?

Q: When installing IIS 5.1 on Windows XP Professional from the Control Panel with Add/Remove Windows Programs, does the procedure require insertion of the Windows XP Professional installation CD-ROM? Most Notebook PC purchases come with a recovery disk but not the original Windows XP Professional Installation CD-ROM. Is IIS installation still possible?

A: I ran across this same problem the other day when trying to install NTBACKUP on Windows XP Home Edition. NTBACKUP is not installed by default on Windows XP Home Edition, but is on the CD-ROM; however, the CD-ROM was not provided. In your case, if the application you want (IIS 5.1) is not installed on the computer by the manufacturer (and in the case of IIS 5.1, it probably isn't), then you will need access the CD-ROM in order to install it. In some cases these files are loaded onto the hard drive for you. If not, you will have to contact your manufacturer to obtain the CD. In many cases, they will provide you a copy of the CD on request.

Be Wary of File Extensions when Running URLScan on a Web Server

Q: We recently installed URLScan 2.5 on your IIS 5 server. It is working very well overall, but we have a pretty serious problem that prevents us from deploying it on a production server. We cannot access our home page with URLScan installed. This seems unusual since there is nothing in the URL that that should trigger any URLScan rules.

A: URLScan behavior is controlled by the urlscan.ini file which is found in the <%systemroot%>\system32\inetsrv\urlscan folder. The ini file has quite a few settings, one of which sounds like it could be the culprit.

In the Options setting at the top of the urlscan.ini file is a switch named UseAllowExtensions which is set to 0 or 1. If set to 0, then you specify extensions you specifically wish to deny in the [DenyExtensions] section of the urlscan.ini. Any file extensions listed in the [DenyExtensions] section will be rejected by URLScan.

A bit of a twist comes into play when UseAllowExtensions is set to 1. In this case, you must specify each and every extension you wish to permit. (Personally, I much prefer this setting as it is more secure to specify what you will allow, and reject everything else, than to allow everything, except what you specifically reject.) So, if you set URLScan to reject all file extensions except for those you specifically allow, then what file extension is present when you type https://servername? When UseAllowExtensions is set to 1, as far as URLScan is concerned, https://servername does not have a valid file extension. This would cause exactly the problems you are seeing.

The fix to this is to add a . to the [Allow Extensions] section. This entry (called the null extension') tells URLScan to permit URLs that do no have specific file extensions such as requests for directory listings or the root of a web site.

Submit your questions to the IIS Insider. Selected questions along with the answers will be posted in a future IIS Insider column.

For a list of previous months questions and answers on IIS Insider columns, click here.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.