Most configuration settings for IIS reside in a storage facility or data repository called metabase . The metabase is organized into a hierarchical structure that mirrors the structure of the IIS installation. From the physical point of view it is a single file: -C:\WINNT\system32\inetsrv\MetaBase.bin, however it cannot be edited with the current IIS version (from IIS version 6 onwards, the metabase will be an XML “editable” file for processing with the use of an ordinary text editor). In IIS 5.0, to access the specific metabase content, you can only use the IIS Admin Base Object that is a COM object that enables your application to manipulate IIS configuration. It is not a ProgId object (hence it cannot be used, for example, with the “CreateObject” of a VBScript command), neither allows you to invoke objects via IDispatch – it is therefore inaccessible for script languages. Instead, the IIS Admin Base Object can be used to modify (using programming languages, e.g. in C++ applications) the metabase. The SDK Platform provides a wealth of information on using the IIS Admin Base Object to develop applications for IIS manipulation  . In addition, IISAdmin provides an interface named ADSI to administer IIS Admin Objects. And like each ADSI provider, it is available from the level of script languages – This is a simple example of VBScript that employs the IIS Admin Object:
Set IIsObject = GetObject(“IIS://localhost/w3svc”)
Set IIsObject = Nothing
Similarly, the SDK Platform also provides detailed information about this object . There is a metabase manipulation script that is far more sophisticated than the one above. It runs under Windows 2000 and requires the installation of IIS. The file is called ADSUTIL.VBS and is usually located in the C:\Inetpub\AdminScripts directory. If you want to execute this script quickly via WSCRIPT.EXE and don’t want to type any parameter you will be prompted in a suitable window to set the CSCRIPT.EXE as a default script interpreter. The ADSUTIL.VBS syntax is very simple: it takes the operation name as the first parameter, the selected location within the metabase as the second parameter and the value as the third parameter to loop the whole set. For more information about the ADSUTIL.VBS utility, see the Microsoft site   and the IIS Server tutorial given under the C:\WINNT\Help\iisHelp\iis\htm\adminsamples directory. The same directory gives details of other administration scripts included in the C:\Inetpub\AdminScripts directory. Similar to the ADSUTIL.VBS but a much more powerful tool for metabase manipulation is the MDUTIL.EXE file utility that is included on the Windows 2000 CD-ROM as a zipped file. In order to install it on your computer, simply insert the Windows 2000 installation CD and execute a simple command:
expand -r d:\i386\mdutil.ex_ c:\winnt
[Figure 1. Installing the MDUTIL.EXE tool]
Although both the MDUTIL and ADSUTIL use a similar syntax, certain metabase elements may be named differently – this is because the MDUTIL uses the IIS Admin Base Object (which, as we remember, is not supported by the scripts, including ADSUTIL) .
MetaEdit is a very convenient metabase editing tool. To install it, first download the MTAEDT22.EXE installation file that is available on the Microsoft Knowledge Base site . Once you have installed it, you will be in the license window. Click Yes if you agree with the terms of the license agreement and after a while you will see the application program of the Visual Basic application. There is no important option to select, so you can simply press Enter all the way through. However I suggest that if during the installation you are prompted to overwrite a newer DLL with an older one, click Enter. On completion of the installation you will see a message “MetaEdit 2.2 (x86) Setup was completed successfully”. The program you have installed is located in the Administrative Tools menu (the administration tools). Once have you run the program, you will see a familiar Explorer-like window split in two panes. The left pane holds the two top metabase keys:
- LM (Local Machine) – configuration data that is associated with all IIS elements is stored here
- Schema – it contains so called “schema” that is the references that are necessary for the IISAdmin to manage information contained in the LM key. You must not modify this information!
You can expand metabase keys as you wish and read information they contain but use caution whenever you edit the metabase directly. Configuring properties in the metabase incorrectly can cause problems, including the unrepairable failure of the IIS.
[Figure 2. A portion of default MetaEdit settings]
A hierarchical arrangement of the metabase is clearly seen; in addition, most of the metabase keys contain the property “KeyType” which has a specific importance. The property list seen in the right pane has the following columns:
- Id this is the number identifier of the property; it is a unique attribute of the property
- Name is a name of the property; certain properties may have no name assigned
- Attributes mean property attributes; “Inh” is the most important attribute for article, since it is an advantage which makes the inheritance of key values intuitive (metabase subkeys embedded in keys with properties will inherit these properties)
- UT (User Type) indicates an application of the property, for example, a server, files, WAM (Web Application Manager), ASP applications.
- DT (Data Type) is related to the kind of data (for example, numeric, character, list of characters, binary data etc.)
- Data, i.e. the data itself.
Among properties is one called “Key Type” (ID = 1002) that is the name of the metabase object (class) that defines that key. Similar to the meaning used in object-oriented programming languages, the class means a set of attributes collected in a specific location and describing a single specific object. Each key in the metabase is an instance of an object whilst the inheritance of properties is a consequence of subkey embedding. For more details about the metabase hierarchical structure and classes refer to the SDK Platform  . Here, the following classes are of great concern: IIsWebService, IIisWebServer and IIsWebVirtualDir. It is also worth mentioning the IIsWebDirectory and IIsWebFile classes – which include properties of an individual Web directory and a file respectively. Listed below are selected class attributes that are important from the IIS customization and tuning point of view.
IIS 5.0 version has been enhanced by the addition of a so-called connection pooling, a technique used for sharing TCP sockets among many sites  . This enhancement allows IIS to employ all available IP addresses – including those not having any site configured. Therefore, a single Windows 2000 server cannot run other IIS services that use the same port numbers concurrently – even if the IP addresses designed for them are not utilized by IIS. An example is Apache running with IIS on the same server. Since IIS with connection pooling enabled occupies port 80 on all IP addresses, (not only those used for sites based on IP addresses), the Apache server will be forced to use another port number – for the sake of user’s convenience. By default, socket pooling is enabled, but you can disable it by setting the DisableSocketPooling appropriately in the IIsWebService and IIisWebServer classes. In order to disable connection pooling for all IIS based sites, in the c:\inetpub\adminscripts\cscript directory execute the command:
adsutil.vbs set w3svc/disablesocketpooling true
and then restart the W3SVC service. After doing this, you can run Apache on the same Windows 2000 server that runs the IIS – making port 80 available to both these services (of course, under different IP addresses).
If you are about to restrict access to your Web pages using Windows password and account facilities, then you must consider the risk that you may introduce by sending passwords in cleartext over the Internet. However, if you have configured the HTTPS service, you may eventually apply “Basic Authentication” to it. But there are a couple of catches: –
- User privileges to log on to the Web server. When a user connects to a Web site using Basic authentication, IIS gets the username and password, calls the Windows API LogonUser and impersonates the user. This function provides a mode of authentication – interactive logon is the default (LOGON32_LOGON_INTERACTIVE). Giving users this privilege allows them to log on to the Web server if they have physical access to the server (i.e. also to the ASP sites) or to another remote computer. For example access to SQL, utilizing the user’s own account, not an extra one, which may be embedded in the ASP script. However this causes a problem – users must have “Log on locally” privileges on the server, which is not necessarily the most secure option. Another option is to allow the user to access the server under the authentication in the call to LogonUser – via the LogonMethod attribute.
- password pass through. The Web browser prompts a user to enter his credentials and after the site has authenticated the user, the credentials are used for each subsequent page of the website. This is a normal solution to free the user from the need to renew authentication each time he wishes to browse the site. If the user authentication is secured by an encrypted connection, there is no problem. However if the user goes beyond a secure area, or a given site has unsecured elements, (which is definitely not recommended), the browser will continue to send the username and password in clear text over the Internet! This is a serious security risk. A solution is to set the so called “realm” property for various portions of a Web site for security purposes. By default, the realm used in IIS is the name of the domain – but you can set your own realm on any metabase key as desired. The realm will be valid for the key (node) of the respective directory and for all elements (directories and files) of the key.
[Figure 3 “A standard Realm setting…”]
[Figure 4 “… and a modified one”]
Both settings can be modified as required, using the ADSUTIL.VBS. With the LogonMethod, the following options are available (below please find the logon notions specified for LogonUser):
- 0 (default setting) IIS will use interactive authentication, therefore the user must have the “Log on locally” privileges on the Web server, by which IIS can make requests for secured resources on a remote computer on behalf of the user (for example, ASP pages or named components);
- 1 – authentication for application (LOGON32_LOGON_BATCH). This logon type is intended for batch servers, where processes may be executed on behalf of a user without their direct intervention. This means without the need to have the “Log on locally” permits, but rather the “Logon on as a batch job” right (used, for example, by COM+ applications). Similarly to the default setting, applications might use cache credentials
- 2 – network authentication (LOGON32_LOGON_NETWORK); this logon is intended for users having the right to log on to servers via the network (Access this computer from the network). This function does not cache credentials for this logon type.
- 3 – network authentication that preserves the credentials (LOGON32_LOGON_NETWORK_CLEARTEXT) – this logon type is not included in the SDK Platform document . The user is only required to have the network authentication privilege (see 2, above), but the server is allowed to accept user’s credentials, call LogonUser, verify that the user can access the Web server across the network and still communicate with other servers (similarly to the 0 and 1 situations).
Figure 5 illustrates exemplary settings for logon authentication. For more details on Web site authentication, please refer to the Knowledge Base 
[Figure 5 “LogonMethod and Realm” settings]
If you decide to move your Web site content to a different server, click the Home Directory tab, and then select A share located on another computer and define the IIS account to be used for network connections. Or you may alternatively enable the UNCAuthenticationPassthrough parameter in the metabase (for more details, see Microsoft Knowledge Base . With this parameter enabled, the account used in “Connect As” will be overridden by the credential of the actual user logging on. Basic authentication with this parameter enables administrators to control ACLs for specific users, but this process increases overheads on the Web server.
This article completes the three-part series on “Installing and Securing IIS Servers”.
If you would like us to email you when Bronek Kozicki releases another article on WindowSecurity.com, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy!
Bronek Kozicki has worked as a Network Administrator for the last eight years. Five years were devoted to Windows NT-based systems. He deals with administering SQL Server databases, applications, network security issues and efficiency of Internet Servers. He writes server solutions (chiefly extensions of the IIS services – the SMTP and the W3SVC) in the C++ language. Besides programming, he is concerned with teaching advanced C++ uses such as: methodology, idioms, programming styles and the modern features of the language. He was a member of WinSecurity Magazine’s editorial board where he was chief editor of the Microsoft Knowledge Base pages. At the moment he works as a Network Administrator in Getin SP S.A., a company providing Internet services. He spends his free time with his wife, going for walks or to the cinema, or reading books, preferably science fiction. He is the world champion in preparing hot chocolate with froth or cappuccino.