Designing a Secure Administrative Strategy for Server Management Tools

---

The most secure way to manage a server is through local access to the server, but this is not always practical for most organizations. Business requirements for availability or concerns about employee productivity may necessitate remote management tools. After all, who wants to trek to the server room every time you need to change something on the server?

There are two methods for remotely managing your servers: in-band and out-of-band. In-band remote management is the standard method you use to manage your server over a network. It involves the use of tools that you are familiar with for managing networks, like the Microsoft Management Console or Telnet. Out-of-band remote management is also known as headless management; it allows you to manage your network without a keyboard, monitor, or working network card, or even if the computer is hung, in some cases. Headless management is known as Emergency Management Services (EMS) in Windows 2003 Server and additional hardware and software may be required to enable the feature.

Note

We will discuss EMS in the section “Designing for Emergency Management Services” later in this chapter.

When evaluating tools for administering your servers, you will need to determine what security capabilities each has, changes to security infrastructure like firewalls and routers, authentication, and means for securing network traffic from the tool. We will first look at designing for security with the in-band management tools.

Using Microsoft Management Console

The Microsoft Management Console (MMC) is the standard administrative tool in Windows Server 2003. The MMC is really a framework to host various management tools. It provides administrators with a standard environment from which they can manage their servers and network.

The tools that are added to the MMC are called MMC snap-ins, and you can create custom combinations of the console by adding the snap-ins that you need to administer your servers. The MMC console can be executed through the mmc.exe program, which will bring up a blank console that can be populated with various administrative snap-ins as shown in Figure 10.1. MMC can be used to manage a local server or a remote server.

Figure 10.1: The MMC console

Once you have a blank console, you can add management snap-ins to it by clicking the Console menu and choosing Add/Remove Snap-in from the Console menu. Each snap-in is different, so you will need to read the documentation on each one, which can usually be found under the Help menu. You will need to verify the remote management capabilities and the security features of the snap-in you want to use for remote management.

Snap-ins are essentially independent management tools that integrate into the MMC, so the security provided can vary greatly from one snap-in to another. The MMC uses a technology called the Component Object Model (COM), which provides standard interfaces for the developer to create an administrative snap-in for the server or application. Since each snap-in is different, you will need to refer to the documentation for the snap-in you want to use to determine when it will be appropriate or inappropriate for securely managing your server. For example, you should see if there are options for encrypting the transmission of data and passwords or whether you need to provide your own through an IPSec session with the server or other means. You will need to determine whether the snap-in supports the following security options:

Encryption capabilities Does the snap-in support encryption internally and what strength is the encryption? If it does not support encryption, you need to determine how to encrypt its network traffic or not use it for network management.

Authentication capabilities Are passwords encrypted or passed as clear text, what authentication protocols can be used, does the snap-in support integration with Windows authentication or do you have to manage a separate password database and policies for the application, and does the management tool support two-factor authentication, like smart card authentication?

Network communications technology What protocols does the snap-in support for network communication? Since most snap-ins will support TCP\IP, you should determine the ports that it uses for communication in case you will need to manage a server through a secured router or firewall. Some common ports for management tools include 3389 for the Remote Desktop Protocol (RDP), 135 RPC for DCOM–based applications like many MMC snap-ins, 23 for Telnet, 22 for Secure Shell (SSH), 80 for HTTP, and 43 for HTTPS.

Based on the information you discover about the snap-in, you will then determine if it is the best tool to use to manage the server.

For example, many snap-ins use the network version of COM, which is called Distributed Component Object Model (DCOM). DCOM uses remote procedure calls (RPCs) to communicate between the client and server. DCOM supports encryption by using the Packet Privacy option in the dcomcnfg tool used to configure DCOM. This encryption supports the RC4 public key encryption algorithm with a symmetric key strength of up to 128 bits. DCOM also supports the use of other algorithms implemented through the cryptoAPIs of Windows. DCOM authentication is integrated into Windows and supports NTLM and Kerberos authentication. Because it uses RPCs, it can support various network protocols, but generally you will be using TCP/IP. The TCP port 135 and UDP port 135 used for RPCs would need to be opened on the firewall if you will be using the tool through a firewall. Due to the danger to the security of your network of these ports being opened (all RPC traffic uses these ports, so it would be difficult to differentiate between programs), your security administrator may not allow you to use the tool directly through the firewall. You could use the tool over a VPN connection to avoid this issue. The protocol used could provide features for security; for example, a snap-in that uses HTTP as a protocol could use SSL and be set up to navigate firewalls without a VPN.

Note

You can install many of the MMC snap-ins that you use to manage Windows Server 2003 in the adminpak.msi file located in the Windows\system32 directory. You can also use this file to install the tools on a client like Windows XP Professional or Windows 2000 Professional.

Real World Scenario: Using MMC to Manage Windows Server 2003

We have Windows Server 2003, Exchange Server 2003, and SQL Server 2000 installed to support various applications on the network. We could support these applications by walking to the server room every time we need to reset a password, create a user, manage the database, or create a mailbox.

We have decided to support convenience and provide access to the servers inside our company by installing the proper MMC snap-ins on client workstations in the organization. This will allow more than two administrators to connect to a server at a time. Our security policy does not require the encryption of connections internally in our organization, but we require strong password authentication for our administrator accounts.

In following Design Scenario, you will design for secure server management with MMC.

Real World Scenario: Designing for Secure Server Management with MMC

Expo, Inc. wants to manage its servers using various MMC snap-ins to create user accounts and manage the Exchange e-mail servers, Microsoft SQL Server machine, DHCP, and DNS. The administrators will need to manage servers that are in various cities. They also will need to traverse firewalls that exist between branch offices and the corporate office.

1. Question: What would you need to determine if a par ticular snap-in would work for Expo, Inc.? Answer: You would need to consider the por t number s for allowing traffic to pass through the fi rewall, the encryption capabilities, authentication capabilities of the snap-in, and the ver sions of Windows that the snap-ins will run on.

Using Remote Desktop for Administration

Remote Desktop for Administration (Remote Desktop for short) provides a graphical user interface to remote computers over a local area network (LAN) and wide area networks (WANs). All application processing happens on the server; just the display, keyboard commands, and mouse motions are sent over the network to and from the client. The Remote Desktop does all of this through the Remote Desktop Protocol (RDP).

Note

Remote Desktop for Administration was known as Terminal Services in Windows 2000.

Using Remote Desktop has become one of the most popular ways to remotely manage Windows servers on a network. Remote Desktop provides the following features for administering Windows Server 2003 and Windows 2000 servers:

• Remote reboots of servers

• Encryption of up to 128 bits in strength

• Support for low-bandwidth connections

• Support for two remote administrators sharing remote sessions for collaboration

• Access to session 0 on Windows Server 2003, which is the session that you would interact with if you were sitting at the local console

• Local printing, clipboard mapping, and serial device redirection

• Support for smart card redirection (Only supported in Windows 2003)

• Roaming disconnect support, which means that if your connection is disconnected, pro

• grams will continue to run, which will prevent interrupted installs or long running tasks.

Remote Desktop for Administration is installed on a Windows Server 2003 machine by default, but don’t worry about it being a security risk because it is disabled by default. To enable it, follow these steps:

1. Open the System Properties dialog box through the Control Panel.

2. Click the Remote tab to show the settings for Remote Desktop and Remote Assistance.

3. Check the Allow Users To Connect Remotely To This Computer check box to enable Remote Desktop for Administration, as shown in Figure 10.2.

Figure 10.2: Enabling Remote Desktop for Administration

When you enable Remote Desktop, you will be warned that any accounts that do not have a password will not be able to create a Remote Desktop session with the server, as shown in Figure 10.3.

Figure 10.3: Warning about users without a password

You will have the option of connecting through the Remote Desktop client in Windows or through the web version of the Remote Desktop, which provides an ActiveX control that will allow you to connect over an HTTP connection. You would need to install Internet Information Services (IIS) on each server that you want to support Web-based Remote Desktop connections. You will then need to take precautions for securing IIS, which were discussed in Chapter 7, “Designing Security for Internet Information Services.”

By default, Remote Desktop for Administration requires 128-bit encryption for the connection. This is supported by the Remote Desktop client in Windows XP and Windows Server 2003. If you have an older version of the terminal service client, you will not be able to connect to a Windows Server 2003 machine with the default settings for RDP. You can configure RDP by navigating to Administrative Tools and clicking the Terminal Services Configuration utility. Expand the Connections folder and then right-click the RDP-Tcp protocol and select Properties. On the General tab, select the Client Compatible option to support clients that do not support 128-bit encryption, as shown in Figure 10.4.

Figure 10.4: Setting the encryption level for the RDP protocol

Real World Scenario: Using Remote Desktop for Administration

We have many servers in our environment and connect to them from various Windows operating systems and locations. We need the flexibility to remotely manage the servers from Windows 98 or greater operating systems or from different locations. We don’t want to mess with having to install the proper tools on the client for the problem to be fixed. We also require that all remote administration traffic be secure.

We choose to use Remote Desktop for Administration because it provides for secure access to servers by authenticating the administrators and encrypting the traffic between the client and the server. It also simplifies access to the management tools because we do not have to worry about installing them or compatibility issues with the operating system we happen to be using.

It is recommended that you use the highest possible encryption for remote management tools, so you should leave the RDP protocol setting set to High and upgrade the client tools if possible. Only change this option if it is necessary to support an older client that cannot be updated. For example, you may have a Remote Desktop client that runs on a Linux workstation or a Windows CE device that does not support 128-bit encryption and cannot be upgraded.

You will need to also consider allowing administrators to connect to the console session of the Windows Server 2003 machine. Using the console session is the same as if you were physically sitting in front of the server. You can connect to the console session by launching the mstsc.exe (Remote Desktop client) with the /console switch or launch the Remote Desktop MMC snap-in and choose to connect to the console. This means that you can view all messages and use applications that only work with the console session. Whenever you connect to the console session, the physical console will lock for security so that nobody can watch what the remote administrator is doing by physically sitting at the console.

You can connect up to two simultaneous remote administrators with Remote Desktop for Administration. You will need to coordinate administrative efforts or you may risk damaging something. You can configure the RDP protocol if you do not have mechanisms in place to prevent competing administrators. You can verify if there are other administrators connected by using the Terminal Services Manager tool in the Administrative Tools folder. You will want to coordinate the efforts of the administrators to ensure that they do not cause damage to the server by trying to run a tool like Disk Management at the same time. Because only two simultaneous remote administration connections are allowed, administrators may find that they are unable to establish a remote connection to the server if two different administrator accounts are connected or have disconnected from the server but not logged out. You will need to address these concerns in your security designs.

In the following Design Scenario, you will design for security in situation in which Remote Desktop for Administration is used.

Design Scenario: Designing for Secure Server Management with Remote Desktop for Administration

Expo, Inc. would like to save money by centralizing most of the administrative functions at its corporate headquarters in Los Angeles. The company wants to be able to use local contractors on an as-needed basis to manage the hardware locally.

During the design phase, you spoke to the CSO and the network administrator:

CSO Remote administration traffic must be secure. We don’t have time to evaluate each administration tool individually for its security features.

Network Administrator We use different OSes through the day and we don’t want to have to install the administrative tools on the clients before we can use them; besides, the snap-ins are not supported on the Pocket PC 2003 devices that the current administrators have.

1. Question: What tool would you recommend for performing remote management in Expo, Inc. and why? Answer: You would use Remote Desktop for Administration because it supports strong authentication and encryption. It also will encrypt all communications for any tool because the tool runs locally on the server but sends only screen, mouse, and keyboard information in encrypted RDP packets. This would meet the CSO’s requirements.

   You only need to use the Remote Desktop client to communicate with the server and use any tools installed on the server. This means you won’t have to install utilities and you won’t have compatibility problems with the OS. This meets the network administrator’s requirements.

Using Remote Assistance

Remote Assistance uses the same technology as Remote Desktop, but it was designed to allow someone to connect to a Windows computer to provide assistance. When a Remote Assistance session is established, both users will see the same screen and can chat with each other through the Remote Assistance chat program. You can even allow the remote user to take control of your computer, with your permission of course. This differs from Remote Desktop, where only one user can be logged in at a time. Remote Desktop is primarily used to manage the computer by administrators, where Remote Assistance is used by help desk staff to help users solve their problems. Remote Assistance does not use the RDP protocol, like Remote Desktop, but is based on the technologies and protocols of Microsoft Netmeeting.

Remote Assistance is installed on Windows XP and 2003 servers and clients by default but is disabled by default.

To enable Remote Assistance, follow these steps:

1. Open the System Properties dialog box through the Control Panel.

2. Click the Remote tab to show the settings for Remote Desktop and Remote Assistance.

3. Check the Turn On Remote Assistance And Allow Invitations To Be Sent From This Computer option, as shown in Figure 10.5.

   
   Figure 10.5: The Remote tab of the System Properties dialog box

Once you select this option, you will be able to click the Advanced button to reveal the Remote Assistance Settings dialog box, shown in Figure 10.6.

Figure 10.6: The Remote Assistance Settings dialog box

You will then be able to choose to allow your computer to be controlled remotely. If you do not want to allow remote control, you can turn off this setting but still chat with the user and allow them to see the desktop of your computer. You will also be able to control how long an invitation for remote assistance will remain open. By default, it is set to 30 days. You may want to shorten it for security reasons.

Remote Assistance is generally used in organizations to provide a means for the help desk to support a user without needing to send someone to the user’s workstation. This can help increase the productivity of the support staff. The utilization of this service can present some security issues that you will need to include in your security design.

Real World Scenario: Using Remote Assistance to Support Users

We have users we need to support in two locations but a very small help desk staff. The help desk staff needs to be as productive as possible when solving users’ problems. They also don’t have time to travel between locations extensively. Many of our users’ problems are due to misconfigured applications or lack of the proper skills to use certain features of a program.

The Remote Assistance feature of Windows XP or Windows Server 2003 helps immensely in maximizing the help desk’s time. They spend less time traveling and more time helping users, meaning we can operate well with the staff we currently have and do not need new hires to keep up with a growing workload. Remote Assistance allows the help desk staff to guide users through difficult procedures instead of trying to talk them through it on the phone or sending someone to their desktop.

The first of the security issues is that you will need to determine if you should change your firewall configuration to support Remote Assistance. Remote Assistance requires that TCP port 3389 be opened on a firewall to pass through it. You will also need to determine if you will allow Remote Assistance by enabling it on the clients that you want to support it. This can be done by navigating to Start Control Panel System and clicking on the Remote tab as shown above. You can enable Remote Assistance by using Group Policy if you want to enable it for a large number of clients in your organization.

You should also set up a password that the user would need to enter to connect to a Remote Assistance session. You will need to communicate the password to the person assisting you through some means, such as an e-mail (you can use S/MIME to encrypt the email), before they will be able to connect. You should make sure the password you choose is strong, especially if the invitation will be left open for a long period of time. You should set a short invitation period for Remote Assistance and use a password that is at least eight characters long and is a mixture of symbols, numbers, and letters.

In the next Design Scenario, you will look at making design decisions for the secure use of Remote Assistance.

Design Scenario: Designing for Secure Remote Assistance

Expo, Inc. wants to be able to use local contractors on an as-needed basis to manage the hardware locally. The company is also in the process of consolidating help desk functionality.

During the design phase, you spoke to the CSO and the help desk manager:

CIO We need to save money wherever possible. In addition to the consolidation for network administration, we are consolidating the help desk functions of different departments into one location at our central office.

Help Desk Manager Most of our calls for assistance involve working with users that are having trouble with an application or have a configuration problem. We usually end up getting frustrated with talking them through steps on the phone and send someone to their desktop. This will no longer be an option because we will be using contractors who will be billing the company. We need a mechanism to help the user visually and verify that the problem is really a hardware problem before we send someone to the aid of the user.

1. Question: What should you recommend for the help desk at Expo, Inc. and why? Answer: You should use Remote Assistance because the company needs a solution that will allow help desk employees to assist users remotely with having to send personnel to them. This is what Remote Assistant is designed to accomplish.

Using Command Line Remote Management Tools

Command line management tools are not the most convenient way to manage Windows Server 2003 most of the time, but there are situations where they can be effective remote management tools. The first is when you have very little bandwidth to communicate with the server over. Command line management tools are very lightweight in terms of bandwidth usage and can help you quickly accomplish the task. The second reason would be to support the maximum number of clients. Command line tools tend to be supported by many different platforms, so they are a good means to manage Windows Server 2003 from another operating system if no other options exist. We will discuss two command line tools: Telnet and Secure Shell (SSH).

Using Telnet

Telnet is a program that runs a command console on the client computer much like the command console in Windows Server 2003. The one difference is that the commands that you execute do not run on the client but on the server you are connected to. This is similar to the capability provided by Remote Desktop for Administration except it is command line only. Telnet provides a basic option for remote management from any operating system that supports TCP\IP. The capability that Telnet provides is called terminal emulation.

You can run Telnet by clicking Start Run and typing telnet to launch the client. You would then type open server_name to connect to the remote server running Telnet. You can then issue commands that run on the server, as shown in Figure 10.7.

Figure 10.7: Telnet to a Windows Server 2003 machine

Telnet is not considered secure in and of itself and should not be used alone on a network, especially over a WAN. It requires that you log on using a username and password, but they are passed in clear text over the network. Authentication is limited to passing the username and password in clear text without support for smart cards or other forms of authentication. Also, all commands and data are sent over the network without any forms of encryption. You will need to consider using another means of encryption, like establishing a VPN using L2TP and IPSec for providing a stronger means of authentication and encryption of network traffic or using an alternative to Telnet called Secure Shell (SSH).

Secure Shell

Secure Shell (SSH) is a technology that was developed by SSH Communications Security, Ltd. to provide for secure authentication and communications for remote shells and file transfers. SSH provides for strong authentication mechanisms, including the capability to use certificatebased authentication like smart cards. SSH guards against eavesdropping on packets and IP redirection by encrypting the communications between the server and client. If available, SSH is preferred over Telnet for providing remote administration through the command line.

---