IIS 7.0 : Managing IIS Manager Extensions

In addition to the programmatic and command line options, the IIS 7.0 administration stack also provides a GUI management tool. IIS Manager, which replaces the legacy MMC snap-in from previous IIS versions, has been completely redesigned to provide end users with an intuitive task-based GUI experience for managing the server. The tool, shown in Figure 1, also serves as a foundation for remote IIS 7.0 management, providing secure HTTPS-based remote connectivity and delegated site management. 

In the spirit of IIS 7.0, IIS Manager provides its own extensibility platform, which enables you to add new UI management features and extensively customize the appearance and functionality of the interface. This completes the extensibility picture of the IIS 7.0 administration stack, enabling new configuration sections and administration extensions added at the configuration system layer to also have corresponding UI management experiences for the end user. These UI extensions also benefit from the remote management and delegation capacities that the tool provides. The tool handles all of the network connectivity, authentication against Windows or non-Windows credential stores, and delegated management, enabling your UI extension to focus on the actual management task without taking into account whether it’s being used for local or remote management.

Figure 1. IIS Manager.

How IIS Manager Extensions Work

A UI extension’s primary job is to provide the UI experience for managing the particular configuration section or performing any management task. Each UI extension typically consists of the following:

• The client-side UI module. This is the client-side component that provides the UI experience, including new UI pages and other customizations of the tool’s interface. It invokes the corresponding module service to carry out the required management tasks.

• The server-side module service. This is the server-side component that provides the underlying management functionality, typically invoking Microsoft.Web.Administration APIs to access the IIS 7.0 administration stack.

The separation between the client UI functionality and the server management functionality is necessary to enable support for remote management. The client-side component is always instantiated on the client, which may be running on the same physical machine as the server being managed or on a remote machine that is connecting to the server through IIS Manager’s management service. The module service is the server-side component, which carries out the underlying management tasks and is always instantiated on the server. This way, the management functionality in the UI extension does not need to concern itself with remote management, because it is always local to the server.

Both the client-side and server-side components are implemented as strongly named .NET assemblies, both of which must be installed into the server’s Global Assembly Cache (GAC) and registered in the server’s configuration. Because of this, both assemblies must be signed by the developer before they can be installed.

IIS Manager uses its own server-level configuration file, Administration.config, which is different from the server-level configuration file used by the Web server (ApplicationHost.config). It is also located in the %windows%\System32\Inetsrv\Config directory. IIS Manager substitutes this file for the root Framework Web.config file when reading its own configuration. This configuration contains the registration information for all of the IIS Manager extensions.

<moduleProviders>
    <!-- Server Modules-->
    <add name="Modules"
type="Microsoft.Web.Management.Iis.Modules.ModulesModuleProvider,
Microsoft.Web.Management.Iis, Version=7.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
    <add name="Handlers"
type="Microsoft.Web.Management.Iis.Handlers.HandlersModuleProvider,
Microsoft.Web.Management.Iis, Version=7.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" />
    ...
</moduleProviders>
<!-- For all Sites -->
<location path=".">
    <modules>
        <add name="Modules" />
        <add name="Handlers" />
        ...
    </modules>
</location>

In the excerpt shown here, two UI features that manage IIS 7.0 Web server modules (the "Modules" feature) and Web server handler mappings ("Handlers") are registered and are enabled by default for delegated management of all Web sites.

The <moduleProviders> section defines all of the IIS Manager extensions that are registered on the system and specifies the associated fully qualified type names of the corresponding module provider. Each module provider is responsible for providing the type information for the client-side UI modules and the corresponding server-side module service components at run time. This information is then used by IIS Manager and the management service to initialize the right components.

The <modules> section provides a mechanism to selectively enable the UI modules for a particular site. By default, all of the UI modules are enabled for all sites by being added at the "." level.

Note

In remote management scenarios, the client machine does not need to have the UI extension registered on the server. When IIS Manager makes a remote connection to the server, it can automatically download the client components of the UI extensions registered on the server and display their UI features on the client.

Installing IIS Manager Extensions

Installing IIS Manager extensions is fairly simple. To do so, follow these steps:

1. Install the client and server .NET assemblies in the server’s GAC.

2. Register the module provider type in the Administration.config configuration file and optionally enable it for delegated site management.

Remember that the client and server assemblies that comprise the IIS Manager extension must be strongly named, that is, signed by the developer.

To register the module provider type, you have to add its fully qualified type to the <moduleProviders> collection and list the selected name of the module in the <modules> collection inside the Administration.config configuration file. To do this, you need to know the fully qualified type name of the module provider class, which is typically provided by the extension’s developer.

Caution

You must trust the source of the code before installing the extensions on your server because the extensions may execute with administrative privileges when you launch IIS Manager on your computer.

Securing IIS Manager Extensions

Just like administration extensions to the configuration system, IIS Manager extensions pose a relatively high risk because they contain code that may run with administrative privileges on the server. As such, if they are malicious or are compromised, they are not restricted in the damage that they can do.

Table 1 lists the programs that load IIS Manager extensions and the privilege under which they are executed.

Table 1. Programs That Load IIS Manager Extensions

Program	Execution Privilege
IIS Manager GUI (Inetmgr.exe)	Caller (typically Administrator for local server administration)
Web Management Service (Wmsvc.exe)	Local Service (NT Service\wmsvc) Authenticated user (if using Windows Authentication)

When you use IIS Manager locally to manage the server, it runs with the identity of the user that launched the tool. Because local administrators typically do this—it is required for much of the server-level administration such as creating sites and changing server-level configuration—the extensions in the tool run with administrative privileges.

When you use the Web Management Service to administer the server remotely, it runs with the Local Service account (mapped to NT Service\wmsvc by service isolation) or under the impersonated identity of the authenticated user if Windows Authentication was used for the remote connection. As such, administration extensions run with administrative privileges only if the remote user is an Administrator on the machine and Windows Authentication was used to authenticate. When non-Windows authentication is used, the extension will still have access to a number of server resources that the NT Service\wmsvc SID has access to. This affords more protection in case the administration extension is somehow compromised by a remote attack. Of course, the remote management service is locked down and requires authentication to access its functionality, so only users that are specifically granted the right to administer the server remotely and are allowed to use the specific extensions can execute them.

Because IIS Manager supports delegated management of Web sites, users that do not have administrative privileges on the server can be allowed to remotely (or locally) manage their Web site configuration. This management is controlled to a large extent by the configuration delegation, but IIS Manager provides an additional mechanism for controlling what UI features are available to site administrators. This is important when you consider that new administration extensions can expose UI features that go beyond configuration and in some cases do not implement their own delegation control.

In these scenarios, the server administrator needs to prevent site administrators from having access to those UI features. This can be done from the Feature Delegation feature available when connected to the server as a server administrator, as shown in Figure 2. You can completely hide the feature from nonadministrative users by setting its delegation state to "Not Delegated". Or, configure it so that its contents can be viewed but no changes to the underlying state can be made by setting the state to "Read Only". However, keep in mind that the administration extension has the responsibility of properly implementing delegation support. So if in doubt, use the "Not Delegated" option.

Figure 2. Feature Delegation.

When a remote client uses IIS Manager to connect to the server, IIS Manager compares the module providers available on the server with what is available on the client. If a new extension is available on the server, IIS Manager prompts the client to download and install that extension. If the client accepts, IIS Manager installs the extension in the user’s profile (it is not installed to the GAC) and loaded inside IIS Manager, which may be running as an Administrator on the client machine (even though the client may be using nonadministrative credentials to connect remotely to the server). Because of this, it is critical for the server administrator to trust the source of the extension and for the client to trust the server. Otherwise, a malicious extension can be used to compromise the security of the client machines that are using IIS Manager to connect to the server.

You can take advantage of the publisher certificate–based trust model provided by IIS Manager to insure that all extensions you install on your server are signed by a publisher that you trust. You can also configure the clients to trust this specific publisher, thereby ensuring that the code downloaded to their machines is safe. In other words, do not install extensions coming from unknown or untrusted publishers or from unknown or untrusted Web servers!

Caution

Do not install administration extensions that come from untrusted publishers, especially when you are connected to a server you do not trust.

Even if you do not accept the download of the extension, your remote administration session will continue working properly, and you will be able to use all of the existing management functionality except for the extension you choose not to download. Next time you connect, you will have an opportunity to download it again.

Note

If for whatever reason the extensions you downloaded have become corrupted or are no longer wanted on your client, you can purge the extension download cache by using the Inetmgr.exe /reset command.