Active Directory, DNS and Domain Controllers

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

Q. Is Kerberos authentication possible for services hosted on a cluster?

A. Yes, in Windows 2000 SP3 and above and Windows Server 2003, the cluster service publishes a computer object in Active Directory. This provides the infrastructure with sufficient state to allow Kerberos authentication against applications and services hosted in a virtual server.

For more information about Kerberos and how it works, see the TechNet web site (https://go.microsoft.com/fwlink/?linkid=67842).

Q. Can cluster servers also be domain controllers?

A. Yes, however, there are several caveats that you should fully understand before taking this approach. We recommend that Server cluster nodes are not domain controllers and that you co-locate a domain controller on the same subnet as the Server cluster public.

If you must make the cluster nodes into domain controllers, consider the following important points:

• If one cluster node in a 2-node cluster is a domain controller, all nodes must be domain controllers. It is recommended that you configure at least two of the nodes in a 4-node Datacenter cluster as domain controllers.

• There is overhead that is associated with the running of a domain controller. A domain controller that is idle can use anywhere between 130 to 140 megabytes (MB) of RAM, which includes the running of Windows Clustering. There is also replication traffic if these domain controllers have to replicate with other domain controllers within the domain and across domains. Most corporate deployments of clusters include nodes with gigabytes (GB) of memory so this is not generally an issue.

• If the cluster nodes are the only domain controllers, they each have to be DNS servers as well, and they should point to each other for primary DNS resolution, and to themselves for secondary DNS resolution. You have to address the problem of the ability to not register the private interface in DNS, especially if it is connected by way of a crossover cable (2-node only). For information about how to configure the heartbeat interface refer to article 258750 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkID=46549). However, before you can accomplish step 12 in KB article 258750, you must first modify other configuration settings, which are outlined in article 275554 (https://go.microsoft.com/fwlink/?LinkID=67844).

  If the cluster nodes are the only domain controllers, they must each be Global Catalog servers, or you must implement domainlets.

• The first domain controller in the forest takes on all flexible single master operation roles (refer to article 197132 at https://go.microsoft.com/fwlink/?LinkID=67847). You can redistribute these roles to each node. However, if a node fails over, the flexible single master operation roles that the node has taken on are no longer available. You can use Ntdsutil to forcibly take away the roles and assign them to the node that is still running (refer to article 223787 at https://go.microsoft.com/fwlink/?LinkID=67851). Review article 223346 at https://go.microsoft.com/fwlink/?LinkID=19807) for information about placement of flexible, single master operation roles throughout the domain.

• If a domain controller is so busy that the Cluster service is unable to gain access to the Quorum drive as needed, the Cluster service may interpret this as a resource failure and cause the cluster group to fail over to the other node. If the Quorum drive is in another group (although it should not be), and it is configured to affect the group, a failure may move all group resources to the other node, which may not be desirable. For more information regarding Quorum configuration, please refer to the article 280345 listed in the "Reference" section (https://go.microsoft.com/fwlink/?LinkID=67855).

• Clustering other programs such as SQL Server or Exchange Server in a scenario where the nodes are also domain controllers, may not result in optimal performance due to resource constraints. You should thoroughly test this configuration in a lab environment prior to deployment.

• You may want to consider making cluster nodes domain controllers (refer to KB article 171390 at https://go.microsoft.com/fwlink/?LinkID=67857 for more information), but if a domain controller is already local, or there is a reliable high-speed connectivity to a domain controller available, Microsoft does not recommend implementing them on cluster nodes.

  Note

  You must promote a cluster node to a domain controller by using the Dcpromo tool prior to installing Windows Clustering.

• You must be extremely careful when demoting a domain controller that is also a cluster node. When a node is demoted from a domain controller, the security settings and the user accounts are radically changed (user accounts are demoted to local accounts for example).

Q. Are virtual servers published in active directory?

A. Yes, in Windows 2000 SP3 and above and in Windows Server 2003, each virtual server has the option of being published in active directory.

Although the network name server cluster resource publishes a computer object in active directory, that computer object should NOT be used for administration tasks such as applying Group Policy. The ONLY role for the virtual server computer object in Windows 2000 and Windows Server 2003 is to allow Kerberos authentication and delegation and for cluster-aware, active directory-aware services (such as MSMQ) to publish service provider information.

Q. Is the cluster configuration stored in active directory?

A. No, at this time there is no cluster information other than the computer objects for virtual servers published in Active directory.

Q. Do Server clusters make domain controllers highly available?

A. No, domain controllers use replication across a set of servers to achieve high availability.

Q. How should my DNS server be configured to work with Server clusters?

A. The cluster service account needs to be able to publish records. In a secure, DNS backed zone, the DNS administrator can chose to restrict the access rights for users. The cluster service account must be granted permission to create records or alternatively, the records can be pre-created. If the records are pre-created, you should not set the zone to dynamic update.