Creating Secure Administrative Policies for Server Clusters

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

To provide adequate and manageable security for sever clusters, you need to implement appropriate administrative practices and policies. The most important secure administrative policy is to permit only trusted, specially designated workstations to access the Cluster service. Any compromise on computers used to administer the cluster can compromise the cluster. For example, if a workstation from which administrative tools are run can be accessed by unauthorized users, these users can run unreliable or malicious code on the cluster without the knowledge of the cluster administrator. For this reason, it is important to audit both administrative access to the server cluster and changes to the Cluster service account.

The following sections describe best practices for securely administrating a server cluster.

Note

  • To change the password of the Cluster service account without taking any nodes offline, it is essential that each node in the cluster have the same Cluster service account.

Verifying Permissions for the Cluster Service Account

The nodes in a server cluster use authenticated communication mechanisms to ensure that only valid members of the cluster can participate in intra-cluster protocols. Authentication of the communication is based on the Cluster service account. The Cluster service creates and maintains files, devices, registry keys, and other objects in the operating system. The default security setting of these objects ensures that unauthorized users cannot impact the cluster configuration or the applications running on the cluster. Making these security settings less restrictive can lead to the cluster being compromised and application data being corrupted.

For the server cluster to function properly, the Cluster service account must have certain permissions associated with it. During cluster installation, some of these rights are granted directly to the Cluster service account while others are inherited when the Cluster service account is made a member of the local Administrators group. The Cluster service account must have rights that allow it to perform the following actions:

  • Act as part of the operating system.

  • Back up files and directories.

  • Adjust memory quotas for a process.

  • Increase scheduling priority.

  • Log on as a service.

  • Restore files and directories.

  • Debug programs.

  • Manage auditing and security logs.

  • Impersonate a client after authentication.

In Windows Server 2003, the Cluster service can publish virtual servers as computer objects in Active Directory. To ensure correct operation, the Cluster service account needs appropriate permissions to manipulate these objects in the Active Directory Computers container.

Note

  • Although the Network Name resource publishes a computer object in Active Directory, that computer object must not be used for administrative tasks such as applying Group Policy settings. The only roles for the virtual server computer object are to support Kerberos authentication, and for cluster-aware services that can use Active Directory (such as Message Queuing) to publish service provider information.

Administering Clusters

Cluster administrators can grant permissions to groups or individuals to manage the cluster. There is no fine level of control: Either a user has credentials to administer the cluster, or the user does not. Because of the high degree of impact administrators can have on your system’s security, granting administrative credentials to a user must be done with careful consideration.

The security descriptor for the Cluster service contains the accounts that are authorized to administrate the cluster. By default, a cluster node’s local Administrators group is added to the Cluster service security descriptor. The service accounts LocalSystem and NetworkService are also added to the security descriptor. The local Administrators group and the two accounts cannot be removed from the security descriptor. Be aware that adding a domain user or global group to the local Administrators group gives cluster administrator permissions to that group or account. If a node is evicted from a cluster, or if the last node is removed, the Cluster service account is not removed from the local Administrators group. When you remove a node from the cluster, you must manually remove the Cluster service account from the local Administrators group.

Cluster administrators can manage all aspects of the cluster configuration, including:

  • Taking resources offline and bringing resources online.

  • Adding and removing nodes from the cluster.

  • Adding and removing resources from the cluster.

In addition, cluster administrators are able to shut down the Cluster service on nodes, provided they are also member of the local Administrators group. Apart from the local Administrators group on a node, all other members of the cluster security descriptor must be either domain user accounts, built-in local accounts such as System or NetworkService, or global groups. This ensures that the account is an identical, well-defined, and authorized account on all nodes in the cluster.

The Cluster service account does not need to be a member of the Domain Admins group, because the Cluster service account does not need domain administrator permissions. As a general security guideline, give all accounts the minimal possible permissions.

If you are deploying multiple clusters in a single domain, you can make administration easier by using the same Cluster service account on all nodes. However, you must balance ease of management against the potential security risks associated with using a single account for many clusters. If the account is compromised, the scope of the impact might exceed the benefits you gain by increasing the ease of management. With Windows Server 2003, the Cluster service account password on multiple clusters can be changed at the same time, as long as every node in the cluster is using the same Cluster service account.

Cluster administrators and the Cluster service need to use different accounts to administer the cluster. This allows more specific auditing and allows policy settings (such as password expiration) to be applied to the Cluster service account and the accounts used to administer the cluster.

If you plan to deploy multiple clusters that have different Cluster service accounts, create a global group or universal group that implements all the policy settings described earlier in this section. Then place each Cluster service account into the group. This eases management of the Cluster service accounts by providing a single container for all Cluster service accounts, and a single point of management for changing account policy settings. For example, you could put all cluster nodes and the Cluster service accounts into a single organizational unit (OU) in Active Directory.

Your OU model depends on your Active Directory implementation. If your Windows Server 2003 clusters reside in a Windows NT 4.0 domain, OUs and universal groups are not available.

Follow these guidelines for ease of use and best security:

  • If there are multiple clusters in a single domain, use the same Cluster service account on all nodes to make administration easier.

  • If you have password expiration policy settings on your Cluster service account, do not use this account for other services.

  • Do not use the Cluster service account for SQL Server or Exchange 2000 if you have password expiration policy settings. When multiple services use the same account, coordinating the password change across the Cluster service and other services is complex and can cause the entire cluster or service to become unavailable during a password rotation. It is recommended that you use a dedicated account, which can be maintained independently, for each service.

  • With Windows Server 2003, the Cluster service account password can be changed online without taking down the cluster, but only if the Cluster service account is not used by other services.

Caution

  • Be sure to change the Cluster service account password before it expires. The cluster will stop functioning when the password expires, because intra-cluster communication can no longer be successfully authenticated.