Windows Server Hack [Electronic resources] نسخه متنی

Hack 56 Map the Metabase

Here are some helpful maps to help you navigate
the complexities of the metabase.

While basic IIS configuration can be done using Internet Services
Manager, sometimes you need to roll up your sleeves and look under
the hood. Under IIS's hood you'll
find the metabase, the key repository of IIS configuration
information. The metabase contains hundreds of settings, from how a
web server performs to the format used for logging visits to sites.
Both Windows 2000 and Windows Server 2003 let you edit the metabase
directly, but the tools you use are different because the format of
the metabase is different in each platform [Hack #54].

Before you start mucking about in your metabase, you need to know
your way around, because its structure is quite complex. The goal of
this hack is to give you a bird's-eye view of how
the metabase is organized, so you can find things more quickly and
avoid making mistakes that could confuse your server.

Surprisingly enough, you won't find this information anywhere on Microsoft's web site, even though it is crucial to metabase exploration.

Once you know the lay of the land, you can start hacking the metabase
[Hack #57] with a certain level of
confidence.

Logical Structure

The logical structure is
the easiest to consider
first, because it's much the same for both IIS 5 and
IIS 6. The important thing to keep in mind is that the metabase
hierarchy reflects the way you manage IIS web sites, directories, and
files using Internet Services Manger. For example, when you want to
log visits to a site on your server, you can use Internet Services
Manager to enable the Log Visits setting at the site level (for all
web content on your site), at the virtual-directory level (for
content stored in a single virtual directory), or at the page level
(for monitoring traffic to individual pages). Most configuration
settings can also be configured globally for the entire IIS machine.
As a result, when you are navigating the properties sheets of
Internet Services Manager, you'll see the following
hierarchical progression:
ServerSiteDirectoryFile.

The logical structure of the metabase is organized similarly and uses
a location attribute to identify where a setting lies within the
hierarchy. The top of this hierarchy is called LM,
which stands for Local Machine (i.e., the server
itself). Each metabase key then has a location attribute that
identifies where the key resides. As a simple example, the
Path key located at
LM/W3SVC/1/ROOT contains the string value
C:\Inetpub\wwwroot and identifies the location
of the content for the Default Web Site. Figure 6-3
shows where this key is located in the IIS 5 metabase using MetaEdit,
the tool used for editing the metabase on that platform. Note that
the metabase is organized hierarchically, using keys in a fashion
similar to the way the Windows Registry is displayed in RegEdit.

Figure 6-3. Path key for Default Web Site in the IIS 5 metabase

To understand the location LM/W3SVC/1/ROOT,
let's break it down: LM is the
local machine itself, W3SVC means
we're looking at web sites (not FTP, SMTP, or NNTP),
1 is the site ID for the Default Web Site, and
ROOT contains configuration settings (keys) that
apply to all virtual directories and files within the web site. The
site ID is a number generated for each web site on the server to
uniquely identify the site internally.

Location map for IIS 5

Now, here is the big picture of how the IIS 5
metabase is logically organized, omitting some of the deeper levels:

LM
LM/IISADMIN
LM/IISADMIN/EXTENSIONS
LM/IISADMIN/PROPERTYREGISTRATION
LM/Logging
LM/Logging/Custom Logging
LM/Logging/Microsoft IIS Log File Format
LM/Logging/NCSA Common Log File Format
LM/Logging/ODBC Logging
LM/Logging/W3C Extended Log File Format
LM/MimeMap
LM/W3SVC
LM/W3SVC/1
LM/W3SVC/1/Filters
LM/W3SVC/1/IIsCertMapper
LM/W3SVC/1/ROOT
LM/W3SVC/2
LM/W3SVC/2/filters
LM/W3SVC/2/root
LM/W3SVC/Filters
LM/W3SVC/Info

Not so complicated after all, is it? The main locations under
LM are pretty self-explanatory. For example,
IISADMIN contains configuration settings for the
IISAdmin service, Logging defines the settings for
the different logging formats supported by IIS, and
MimeMap has a copy of the MIME mappings that
define how IIS responds to client requests for files with particular
extensions. Everything under W3SVC relates to the
World Wide Web Publishing Services on the machine, which you can see
is hosting two web sites: the Default Web Site (site ID
1) and a custom web site (site ID 2). If
your server is running additional services, such as FTP,
you'll also find locations for those within the
hierarchy.

Of course, before you can successfully hack the metabase, you need to
know how to find the site ID for a given web site and vice versa. In
IIS 6, this is easily done. Select the Web Sites node in Internet
Services Manager and look under the Identifier column in the pane on
the right. This displays the site ID for each web site running on the
server.

Finding the site ID under IIS 5 is a little trickier. If you want to
find the site ID for a particular site, open its properties sheet in
Internet Services Manager, choose the Web Site tab, and click the
Properties button in the Logging section at the bottom. If you have
W3C Extended Log File Format configured (the default), then the site
ID is embedded in the name of the folder in which your IIS log files
are saved. In our example, these folders are
%SystemRoot%\System32\LogFiles\W3SVC1 for the
Default Web Site and %SystemRoot%\System32\LogFiles\W3SVC2
for the custom web site. Figure 6-4
shows the Extended Logging Properties dialogue box for the custom web
site.

Figure 6-4. Finding the site ID for a web site in IIS 5

Of course, if you have dozens of web sites running on your machine,
this is a rather slow approach. As a workaround you can use
findweb.vbs, one of the sample administrator
scripts included in the Inetpub\AdminSamples
folder on IIS 5. Drop to a command prompt and type
cscript findweb.vbs
sitename, where
sitename is the descriptive name of your
site in Internet Services Manager. Be sure to use quotes if there are
spaces in the site name. The output of the script will include the
web site numberanother name for the site ID. For more
information about using scripts to administer IIS, see [Hack #59].

What about the reverse? Given a site ID within the metabase, how do
you find the descriptive name of the web site as displayed in
Internet Services Manager? One way is to use MetaEdit to view the
contents of the ServerComment key in the location
LM\W3SVC\n, where
n is the site ID for the web site. The
data value for this key is the descriptive name of the site in
Internet Services Manager.

Location map for IIS 6

IIS 6 is logically organized similarly to IIS 5, but with a few
differences:

.
/
/LM
/LM/IISADMIN
/LM/IISADMIN/EXTENSIONS
/LM/IISADMIN/PROPERTYREGISTRATION
/LM/Logging
/LM/Logging/Custom Logging
/LM/Logging/Microsoft IIS Log File Format
/LM/Logging/NCSA Common Log File Format
/LM/Logging/ODBC Logging
/LM/Logging/W3C Extended Log File Format
/LM/MimeMap
/LM/W3SVC
/LM/W3SVC/1
/LM/W3SVC/1/Filters
/LM/W3SVC/1/IIsCertMapper
/LM/W3SVC/1/ROOT
/LM/W3SVC/388907640
/LM/W3SVC/388907640/filters
/LM/W3SVC/388907640/root
/LM/W3SVC/AppPools
/LM/W3SVC/AppPools/DefaultAppPool
/LM/W3SVC/Filters
/LM/W3SVC/Info

Here, we see that LM is the third level instead of
the root. The root level (.) contains keys for
versioning (timestamp and change number) and history major version
number [Hack #54]. The next level
(/) contains an AdminACL key
used for protecting the metabase against unauthorized modification.
Beyond that, everything under LM is pretty much
the same as in IIS 5, with the obvious exception of
/LM/W3SVC/AppPools and locations beneath it, which
contain information about application pools when IIS 6 is running in
worker process isolation mode.

Another thing to notice is that the site ID for the custom web site
is 388097640 instead of 2.
While IIS 5 assigns site IDs to new web sites serially
(1, 2, and so on), IIS 6
assigns what looks like a random number as a web
site's site ID. Actually, it's not
random at all; it's a pseudorandom number derived
from scrambling the descriptive name of the web site. So, if you have
two web servers, each with a custom site named My Company
Site, they'll both be assigned the same
site ID in IIS 6. The reason for doing it this way is to ensure that
web farms with multiple IIS machines that host copies of sites have
identical site IDs for mirrored sites. If you prefer, you can disable
this feature via the Registry Editor; simply add a new
REG_DWORD value to the
HKLM\SOFTWARE\Microsoft\InetMgr\Parameters key,
give the new value the name
IncrementalSiteIDCreation, and assign it a value
of 1. Restart IIS to jog the change into effect.
This might be useful in a service provider environment, for example,
if you have several IIS machines that host thousands of web sites and
you don't want to worry about having two users
create sites with the same descriptive name.

Finally, be aware that while the basic logical structure of the
metabase is almost identical in IIS 5 and IIS 6, there are many new
metabase keys in IIS 6 that have no counterpart in IIS 5. Also, some
IIS 5 keys have been retired or renamed in IIS 6. A full discussion
of these items is obviously beyond the scope of this book;
thankfully, I have another for you which does discuss this stuff at
length: IIS 6 Administration
(Osborne/McGraw-Hill).

Physical Structure

On IIS 5, the physical structure of the metabase is hidden within the
proprietary format of the binary metabase.bin
file, so you need to know only the logical structure
(location of keys) to find your way around the metabase using
MetaEdit. Things are different in IIS 6, however, because here the
metabase is a plain text file (MetaBase.xml)
that is formatted in XML and adheres to strict constraints laid down
by the schema (MBScehma.xml). In the XML syntax
for the metabase, the location of a key is given by its location
attribute within the XML tag for the key. For example, the
Path key previously discussed for the Default Web
Site in IIS 5 looks like this in the IIS 6 metabase:

<IIsWebVirtualDir Location = "/LM/W3SVC/1/ROOT" 
Path = "c:\inetpub\wwwroot"
>
</IisWebVirtualDir>

If you know a little XML, you can see that
IIsWebVirtualDir is an element whose attributes
include Location and Path,
contained within a pair of opening and closing tags. To be accurate,
IIsWebVirtualDir is itself a property called
KeyType, and I've left out some
other attributes to make the basic structure clear. Anyway, by
editing this section of the MetaBase.xml file
directly, using a text editor such as Notepad, you can easily change
the default path for the home directory of the Default Web Site.

XML map for IIS 6

So, now let's see the big picture of what the IIS 6 metabase
looks like in terms of XML tags instead of location. This is
important to know, because while the location map described earlier
really defines the hierarchical structure of metabase keys, the
actual physical metabase file is formatted in XML and
that's what you have to look at when you edit it.
Anyway, here's the XML for an IIS 6 machine
configured with two web sites (keys that can be repeated are
indicated with ellipses):

<?xml version ="1.0"?>
<configuration xmlns="urn:microsoft-catalog:XML_Metabase_V54_0">
<MBProperty>
IIS_Global
IIS_ROOT
IIsComputer
IIsConfigObject...        
IIsLogModules        
IIsCustomLogModule...
IIsLogModule...
IIsMimeMap
IIsWebService        
IIsWebServer        
IIsFilters        
IIsCertMapper        
IIsWebVirtualDir        
IIsWebServer        
IIsFilters        
IIsWebVirtualDir        
IIsApplicationPools        
IIsApplicationPool        
IIsFilters        
IIsFilter        
IisCompressionScheme...        
IIsCompressionSchemes        
IIsWebInfo        
IIsConfigObject        
IIsWebServer        
IIsWebVirtualDir
IIsWebServer        
IIsWebVirtualDir        
</MBProperty>
</configuration>

As you can see from the duplicate sections beginning with
IIsWebServer, two web sites are running on this
machine. If you examine the details of these sections,
you'll find they have identical
KeyType attributes but different
Location attributes. Also, note that unlike the
location map, which accurately reflects the hierarchical structure of
metabase keys, the XML map shows that the MetaBase.xml
file is almost flat, with all KeyType
attributes nested equally within
<MBProperty> tags, which themselves are
nested within global <configuration> tags.

Of course, the metabase can get much more complicated if you have
additional web sites, directories, and services installed. But now
that you know the basic lay of the land, you should be able to find
your way about. Just don't forget to back up the
metabase before you start hacking away at it!