Remote IIS 5.0 Administration
IIS 5.0 provides 2 remote administration options: the MMC Internet Information Services snap-in and Internet Services Manager (HTML). Find out which tool you can use and when.
April 1, 2002
Two interfaces for remotely controlling your Web servers
When you think "distributed computing," you probably picture distributing a task's workload among different servers. But if you're running from computer to computer to mirror administrative changes on multiple servers in an enterprise Web farm, your enterprise isn't truly distributed. In a truly distributed enterprise, you should also be able to distribute management tasks.
IIS 5.0 offers two remote administration options: the Microsoft Management Console (MMC) Internet Information Services snap-in and the Internet Services Manager (HTML) tool. Both tools are capable but have limitations. To choose the best tool for your situation, you need to know each tool's functionality and drawbacks.
Configuring the Internet Information Services Snap-in
The Internet Information Services snap-in is installed by default when you install IIS. To verify the snap-in's installation, open the Control Panel Add/Remove Programs applet and click Add/Remove Windows Components. Select the Internet Information Services Snap-in check box, click Details, then verify that the Internet Information Services Snap-in check box is selected. After installation, you access the Internet Information Services console by clicking Start, Programs, Administrative Tools, then double-clicking the Internet Services Manager icon.
You can open MMC in either of two modes: user mode or author mode. The primary difference between user mode and author mode is the extent to which you can change the appearance of an MMC console.
User mode. By default, when you double-click the Internet Services Manager icon in the Administrative Tools folder, MMC opens in user mode. This mode has limited permissions to change the look of the Internet Information Services console. For example, you can't add other snap-ins (e.g., the MMC Indexing Service snap-in) to the Internet Information Services console.
Author mode. Author mode lets you change the look of MMC consoles as well as add and delete snap-ins. To open MMC in author mode, you can right-click the Internet Services Manager icon and select Author. Alternatively, you can use the /a switch at a command prompt, as in the following example:
mmc /a %systemroot%system32inetsrviis.msc
The iis.msc part of the sample command specifies the file that retains the Internet Information Services console's configuration information (e.g., what snap-ins to open with).
When MMC is in author mode, you can easily add snap-ins to the Internet Information Services console. For example, to add the Indexing Service snap-in, simply open the Internet Information Services console, then choose Console, Add/Remove Snap-in. From the Standalone tab of the Add/Remove Snap-in dialog box, select Internet Information Services, then click Add. In the Add Standalone Snap-in dialog box, select the Indexing Service snap-in, then click Next to select which machine you want to manage: the local computer or the remote computer. Click Finish, click Close, then click OK.
If your enterprise consists of many servers running Microsoft Indexing Service, you might want to add an Indexing Service snap-in for each server. Then, when you need to remotely manage another server that's running Indexing Service (or any other service that has a snap-in), you can add the Indexing Service snap-in for that server.
Using MMC to Manage IIS Remotely
Use MMC for remote administration in intranet configurations when your Web servers use domain or Active Directory (AD) resources. Figure 1 shows MMC configured to manage IIS and Indexing Service on the remote machine LEONBR2000. Notice that the local machine (chumba) is preceded by an asterisk (*), whereas the remote machine has a different icon and is preceded by a double backslash (\) to signify a network location. Managing a remote machine through MMC is no different from managing the local box: The property pages for the remote box and the local machine are identical.
Because managing remote IIS machines is so easy with MMC, you might wonder what prevents malicious users from connecting to your IIS server and doing whatever they please. Ideally, your IIS machine is behind a firewall and you access it through a VPN (the setup of which is beyond the scope of this article). But even without firewalls and VPNs, remote administration isn't as simple as it seems on the surface. Windows 2000 is a secure OS, and only users in the Administrators group can fully administer IIS (either locally or remotely). Operators can perform some administrative tasks, but these tasks are limited to simple management actions such as changing logging options for a site or setting the content-expiration time. (For information about designating operators for your IIS sites, see Brett Hill, IIS Informant, "Delegating Operator Privileges to Web Masters," February 2002, InstantDoc ID 23578.)
When connecting to the remote machine in MMC, Windows automatically establishes the connection in the security context of the user who's running MMC. For example, if a user logs on to a domain as DOMAINLeonbr, the connection with the target server is established in the security context of the DOMAINLeonbr user. The connection succeeds only when the user has Operator permissions or is a member of the Administrators group.
But what happens if you want to remotely administer IIS from a machine that's not a member of the domain? In this case, using MMC to connect to the remote machine causes an Access Denied error. When the source machine isn't a member of the domain, Windows establishes a connection to the remote machine in the security context of the user logged on to the source machine. The target machine doesn't know who the user is and refuses the connection. One way to solve this problem is to create two users—one on the target machine, and the other on the source machine—with identical usernames and passwords. Another solution is to log on to the source machine as an administrator and make sure that the source and target machines' Administrator passwords match exactly. You might encounter a similar problem when you're trying to establish a connection from a machine that isn't a member of the domain and is connected to the network through RAS: Establishing a connection with the RAS server doesn't log you on to the domain, so the connection fails.
The benefit of remote administration through MMC is that administration tasks are transparent both for local and for remote machines. You can use MMC to connect to several different servers and manage them all from the same console. MMC also lets you connect to IIS 5.0 from IIS 4.0 and vice versa—an important benefit in a mixed IIS environment. Several problems arise with cross-version connections, however. See the Microsoft article "INFO: Known Issues Administering IIS 5.0 from the Windows NT 4.0/IIS 4.0 Internet Service Manager and Vice Versa" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q284930) for more information.
The drawback of remote IIS administration through the Internet Information Services snap-in is that it works only in a domain structure and only from platforms that support MMC. As a result, you can't use MMC to administer IIS from remote workstations on the Internet or from UNIX machines. The Internet Services Manager (HTML) tool doesn't have these limitations and allows truly remote IIS management from any browser anywhere on the Internet.
HTML Administration for IIS
Internet Services Manager (HTML) uses a Web site called Administration Web Site that consists of HTML and Active Server Pages (ASP) files dedicated to IIS management. Internet Services Manager (HTML) is a default IIS installation option, and its installation creates the Administration Web Site.
By default, the Administration Web Site listens on all available IP addresses. However, it chooses the TCP port to monitor at random from the range 2000 to 9999. You can't configure the port during installation, but you can determine which port the site has chosen by using either of two methods:
From the Internet Information Services console, open the Administration Web Site's Properties dialog box, then click the Web Site tab, which Figure 2 shows. The TCP Port box contains the port number.
From the Internet Information Services console, expand the Administration Web Site node, then switch to the Details view in MMC's right pane. A Port column in the right pane shows the ports for each service and site in the Internet Information Services console.
As a security measure, by default, the Administration Web Site accepts only connections made from the local machine (IP address 127.0.0.1). Although this measure increases the security of IIS administration, it doesn't let you perform remote administration. To change this restriction, open the Administration Web Site's Properties dialog box, click the Directory Security tab, which Figure 3 shows, then click Edit in the IP address and domain name restrictions area. In the IP Address and Domain Name Restrictions dialog box, which Figure 4 shows, you can select the Granted Access option to allow every machine to connect. However, a good rule of thumb is to leave the Denied Access option selected and to add only those IP addresses or computer names from which you'll administer IIS. With this approach, you don't leave the Administration Web Site wide open for anyone to connect to.
Authenticating to the Administration Web Site
As another security measure, the Administration Web Site denies anonymous connections. The site requires unauthenticated users to supply their credentials, so only operators and members of the Administrators group can connect. By default, the Administration Web Site uses Integrated Windows authentication, but you can change the authentication method. To do so, open the Administration Web Site's Properties dialog box, click the Directory Security tab, then click Edit in the Anonymous access and authentication control area. In the Authentication Methods dialog box, which Figure 5 shows, select the access that's right for your environment.
Integrated Windows authentication works seamlessly when you've configured AD to run in Win2K's native mode. If you use Microsoft Internet Explorer (IE) 4.0 or later to connect to the Administration Web Site, the client and server use the Kerberos 5.x authentication protocol to authorize you. (For information about Kerberos versus NT LAN Manager—NTLM— authentication, see the sidebar "Kerberos vs. NTLM.")
However, Integrated Windows authentication works only if the browser supports it and can fail if the connection is established over HTTP proxy. Only Basic authentication works with all browsers and over any number of proxies and gateways. But Basic authentication has a major drawback: The client passes credentials in clear text to the server. In addition, credentials are Base64 encoded, and malicious users can easily intercept the credentials while they're in transit. If you want to use Basic authentication, consider enabling Secure Sockets Layer (SSL) support in IIS. Enabling SSL encrypts all traffic between the browser and IIS; thus, passwords won't be transmitted in the clear. Of course, this security doesn't come cheap. Using SSL increases latency and can slow server performance.
IIS 5.0 offers an improved version of Basic authentication called Digest authentication. Digest authentication is similar to Basic authentication in that it works over proxy servers, but passwords are never actually transmitted. For Digest authentication to work, the user's browser must support it (i.e., the user must have IE 4.0 or later) and the domain server that runs Win2K must store a clear-text copy of the password. For more information about using Digest authentication, see the Microsoft article "Setting Up Digest Authentication for Use with Internet Information Services 5.0" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q222028).
Regardless of which authentication method you use, administering IIS remotely through the Internet Services Manager (HTML) tool is as simple as typing
http://LEONBR_HM:3182
in your browser, where LEONBR_HM is the computer name and 3182 is the port number. (Make sure that hosts other than Localhost can connect and look up the port number that your Administration Web Site uses.) Figure 6, page 10, shows the Administration Web Site. If you're connecting to IIS over the Internet, you need to supply a Fully Qualified Domain Name (FQDN) and a URL (e.g., http://www.braginski.com:3182).
Microsoft designed Internet Services Manager (HTML) to provide the same functionality as the Internet Information Services snap-in. However, you should be aware of a few differences. Because Internet Services Manager (HTML) is written in HTML, the tool doesn't support right-clicking a Web site or virtual directory to access its properties. Instead, you need to click Properties in the Administration Web Site's left pane to bring up property pages. Another difference is that although Internet Services Manager (HTML) lets you configure SSL if a server certificate is installed, the tool doesn't bring up the Key Manager to start a certificate-creation process. Despite these limitations, Internet Services Manager (HTML) is a nice complement to remote administration through MMC.
The Right Tool for the Job
IIS provides two ways to administer your Web servers remotely. In an enterprise consisting of many Web servers, connecting to all the Web servers from one MMC console might be the best option. If you're at home and you need to connect to one of your IIS machines, your best option is to connect to the server over the Internet and use the Administration Web Site to administer the machine. The choice of tool you make will always be unique to your environment.
About the Author
You May Also Like