IIS Insider - January 2002

  • Article

By Brett Hill

Location of the Web Anonymous Users Account's Password

Q: We would like to grant the Web Anonymous Users account rights to read information on another system; however, we don't know the password for the account. How can we obtain the password?

A: The IUSR_<computername> account is called the Web Anonymous Users account and is created during the installation of IIS. The password is stored in the local SAM (or Active Directory in the event of a Windows 2000 domain controller) and also in metabase. Since it is stored in the metabase, you can extract the password for the IUSR and the IWAM accounts with a .vbs script, as follows:

Dim IIsObject Set IIsObject = GetObject ("IIS://localhost/w3svc") WScript.Echo "AnonymousUserName = " & IIsObject.Get("AnonymousUserName") & vbCrlf & _ "AnonymousUserPass = " & IIsObject.Get("AnonymousUserPass") &vbCrlf; &vbCrlf; &;_ "WAMUserName = " & IIsObject.Get("WAMUserName") & vbCrlf & _ "WAMUserPass = " & IIsObject.Get("WAMUserPass") Set IIsObject = Nothing

Note This script will show the IUSR and IWAM account passwords that are set at the master level properties for the web services. If you have configured anonymous authentication to use a different user account for a web site or directory, you will need to modify the script accordingly to show your updates.

How To Move the Metabase from One Computer to Another

Q: Is there any documentation available to know the machine dependent keys in IIS 4.0/5.0? If in case I have to move my metabase from one machine to another, what case should I take? I read about the IISSync Utility, but that's not going to solve my problem. I am looking for some tool which is similar to MergeINI file.

A: IIS 4 and IIS 5 both use metabase.bin located in %systemdir%/system32/inetsrv to store the IIS configuration information. The metabase is keyed to the computer on which IIS is installed so you can't simply move it from one system to another. As mentioned in the November 2001 IIS Insider column (https://www.microsoft.com/technet/community/columns/insider/iisi1101.mspx), you can use Metaedit 2.2 (https://download.microsoft.com/download/iis50/Utility/5.0/NT45/EN-US/MtaEdt22.exe) to export the metabase from IIS 4 or IIS 5 and then import those setting to another system. You must still take care to ensure that your settings are correct on the imported system. For example, if the home directory of your web sites reside on Drive D, and you import your web sites using Metaedit to a new system on Drive E, IIS will not be able to locate the content.

Another utility for metabase migration is IIS Export. This is a very functional migration tool that can be located at https://www.adsonline.co.uk/IISExport. This shareware utility will copy files, permissions, and store the metabase in a database so that the configuration can be applied to multiple systems.

Finally, there is the IIS Migration Tool. This utility is part of the Windows 2000 Resource Kit.

Resources for Troubleshooting the SMTP Service

Q: I'm trying to find information on the SMTP service for IIS 5.0. The default setup isn't sending out mail and I need help in troubleshooting.

A: The SMTP service on IIS 5 is an enhanced version of the IIS 4 SMTP service. You'll find very useful information in a number of places. In addition to the Online help files installed with your server, check out the following:

  • How to Configure the IIS SMTP Service to Relay SMTP Mail (Microsoft Knowledge Base article Q230235

But my personal favorite is actually a chapter from Running Microsoft Internet Information Server published by Microsoft Press. While this book (which is required reading for all IIS administrators) is on Internet Information Server 4, there is a great deal that is applicable to IIS 5, including the chapter on SMTP.

Finally, there is also a module on how to configure the SMTP service in the Microsoft Training course 2295a – Implementing and Supporting Microsoft Internet Information Services 5.0.

How To Run Applications Not In The Context of the System Account

Q: I have an IIS server that runs a custom mpeg player application. The application streams the mpeg data through a special card that decodes and streams the data to projectors. This process works well when the mpeg source is on the local disk. Unfortunately I need to be able to pull the mpegs from a Unix server. It would appear that when IIS loads the mpeg player application loads it as SYSTEM which has no rights on the NFS (Unix server) share. I need to get IIS to start the mpeg player application as a user other than SYSTEM. I have tried changing the user account that IIS services use however, this leads to further problems. Do you have any ideas of how I can get round this or of what I am doing wrong?

A: Processes are always executed in the "context" of an account. As you indicated, INETINFO runs as a process launched by the SYSTEM account, so Inetinfo runs in the context of the SYSTEM account. The SYSTEM account is not a typical user account. One of the characteristics of the SYSTEM account is that it does not have network access, so, applications that are running as SYSTEM, won't be able to access network resources. It is possible, in some cases, to configure a service to run as a process launched by a specified user account, however that is an unsupported configuration for IIS.

Ideally, an application on an IIS server will switch "contexts" to use the security credentials of the user that is invoking the application (For detailed information on this, refer to the following two books: Designing Secure Web-Based Applications for Microsoft Windows 2000 by Microsoft Press and Programming Windows Security by Addison Wesley).

However, you may be able to solve your problem by configuring your application to run Out of Process. You configure this setting on the web site or directory properties in the IIS snap-in. In Internet Information Server 4, you set the check box "Run in separate memory space (isolated process)" and in IIS 5 you set the Application protection to Medium or High. When so configured, applications will run in the context of the IWAM_<servername> account rather than the SYSTEM account. Since this is a normal user account, you can assign permissions to remote network resources and applications running in this context will then have access to those resources.

Recommended Folder Structure When Hosting Multiple Sites

Q: What are the issues involved in the choice and physical folder structure of home directories, especially when hosting multiple sites? Should Company A, Company B, etc., go under the Inetpub folder or should they go under wwwroot? In other words, is wwwroot the root of all web sites or is it the root only of the default web site (as installed)? How does this affect access to script folders, etc.?

A: Here are a few guidelines that should clear this up. When IIS is installed, you will have a directory structure similar to this:

Drive Root

Inetpub

Adminscripts

Ftproot

Iissamples

Scripts

Wwwroot

It seems that because the name wwwroot contains "root," it infers that all web content should be placed there, however, that is not the case. This folder is the home folder for the Default Web Site, and you should think of it as having the name "DefaultWebRoot".

Consequently, as a best practice, you should place new web sites in a folder other than the default wwwroot folder. If not, then the content for all your web sites will become available from the default web site. Additionally, your content should not be on the system drive for security reasons.

The scripts folder deserves special consideration. By default the scripts folder has Everyone – Full Control and allows Scripts to be executed, so you must tighten security for this folder. I suggest relocating the folder to the same drive as your new webroot and renaming the Scripts folder to some other name in order to thwart attacks that inspect servers for the availability of a folder named "Scripts" and if found, attempt to upload a payload.

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.