Deployment and Operational Management

  • Article

Applies To: Windows Server 2003 with SP1

Cluster administrators

Administrators can specify groups or individuals that are allowed to manage the cluster. Because NLB does not implement a cluster-wide administrative account, the cluster administrator must ensure that an appropriate administrative account with Administrator privileges has been enabled on all cluster hosts. This account is used by NLB management tools, such as NLB Manager and the NLB control program, wlbs.exe, to administer individual NLB hosts. To simplify this process and ensure uniform access on all hosts, it is preferable to use a single domain or global group account for this purpose.

Using the cluster administrative tools through a firewall

The NLB control program, wlbs.exe, should only be used on NLB hosts or, when remote control operations have been enabled, only on a trusted, internal computer within the firewall. By default, remote control operations are disabled, and they must only be enabled if the NLB cluster has been protected by a firewall that blocks UDP control ports 1717 and 2504. Otherwise, unauthorized remote control packets could be delivered to NLB hosts and thereby cluster operations.

The NLB Manager administrative tool can safely be used on trusted computers outside the firewall. This tool uses a secure method of communication to access NLB hosts. NLB Manager uses WMI interface to manage NLB hosts. Please refer to WMI/DCOM documentation to see what ports to unblock to allow WMI/DCOM access from outside the firewall. Nevertheless, make sure that this tool is only executed on a trusted, remote computer.

Using Kerberos Authentication in an NLB Cluster

NLB does not use its own cluster-wide authentication mechanism for cluster administration. Instead, NLB management tools use an appropriate administrative account, which must be enabled with administrative privileges on each NLB host. If a domain account is used for this purpose, it will use Kerberos authentication to control access to NLB hosts.

Using NLB to support VPN connections

NLB can be used to load balance virtual private network connections using the PPTP protocol in Windows 2000 and using both the PPTP or IPSec protocols in Windows Server 2003. When using IPSec, some client sessions may be disrupted when a new NLB host joins the cluster. This issue has been corrected in Windows XP SP1 and in Windows Server 2003.

Network Security

To coordinate their actions, all NLB hosts communicate with each other by periodically exchanging heartbeat messages on a common subnet, which is also used to receive incoming client requests. This subnet must be physically protected from intrusion. Otherwise, unauthorized heartbeat messages could be delivered to NLB hosts and disrupt cluster operations. Note that NLB heartbeat messages use a uniquely assigned Ethertype (0x886F) which is not normally routed across subnets. However, the cluster administrator must ensure that unauthorized computers and devices which could emit invalid NLB heartbeat packets are not placed directly on the NLB subnet. The effects of these disruptions are described below in the subsection "Rogue Servers".

Network Flooding

NLB cluster hosts may be affected by denial of service attacks, which flood the cluster with invalid network packets. These attacks can create additional CPU and network load on the cluster hosts and thereby delay the handling of valid client requests. In addition, they can cause NLB hosts to increase their memory usage up to parameterized limits. These limits are adjustable by setting registry variables on each NLB host, as described in the Windows 2000 Resource Kit. In extreme cases, a high volume of invalid network packets can disrupt extant client connections and require affected clients to reconnect to the cluster. Note that the Windows network protocol stack and server applications, such as Web servers, also may be affected by denial of service attacks.

Rogue Servers

Rogue NLB servers on an NLB subnet could emit heartbeat packets that disrupt cluster operations. Disruptions can include impeding NLBs convergence process such that cluster hosts cannot be added and recovery for a failed host cannot be completed. In addition, disruptions can block some or all of NLBs service to clients. NLB subnets must be physically protected from intrusion by unauthorized computers and devices.

Best practices

To summarize, best practices for NLB cluster administrators:

  • Cluster administrators should establish a common administrative account on all NLB hosts that have Administrator privileges. To simplify cluster management, it is preferable that a single domain or global group account be used for this purpose.

  • The NLB subnet must be physically protected from intrusion by unauthorized computers and devices to avoid interference from unauthorized heartbeat packets.

  • NLBs remote control mechanism is disabled by default. It should remain disabled unless the administrator can ensure that the NLB subnet has been physically protected from intrusion and that UDP control ports 1717 and 2504 have been firewalled to prevent unauthorized remote control.

  • If remote control has been enabled, remote control operations using the NLB control program wlbs.exe must only be performed from a trusted computer within the firewall.

  • NLB Manager provides a secure method for remote cluster management and should be used instead of wlbs.exe whenever possible. NLB Managers optional host list file should only be saved to a file that is accessible by user accounts (such as the NLB cluster administrators account) that have local Administrator privileges.