Knowledge Base

Kerberos support on Windows 2000-based server clusters

Article ID: 235529

Article Last Modified on 12/4/2007

APPLIES TO

Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Service Pack 3

This article was previously published under Q235529

SUMMARY

This article describes the Kerberos authentication support for Windows 2000-based server clusters that has been added in Windows 2000 Service Pack 3 (SP3). With versions of Windows 2000 earlier than SP3, the Cluster service does not publish Computer objects for virtual servers in Active Directory. This means that virtual servers authenticate only by using NTLM or NTLM version 2. With Windows 2000 SP3, you can configure virtual servers to permit clients to authenticate by using the Kerberos authentication protocol. If this is enabled, a Computer object is created for each corresponding Network Name resource.

Kerberos authentication for the Network Name resource on which Microsoft Exchange 2000 depends is not supported on a server cluster. Exchange 2000 was not tested with the expectation that a cluster virtual server would support Kerberos authentication; this configuration may not function properly. Future versions of Exchange Server may take advantage of Kerberos authentication for server clusters.

Important: Note that Kerberos is supported on a SQL Server cluster.

For more information about Kerberos authentication for Windows 2000 SP3, click the following article number to view the article in the Microsoft Knowledge Base:

302389 Description of the properties of the cluster Network Name resource in Windows Server 2003

For more information about how to use Kerberos authentication in SQL Server, click the following article number to view the article in the Microsoft Knowledge Base:

319723 How to use Kerberos authentication in SQL Server

MORE INFORMATION

The following sections describe how to turn on Kerberos support and describe some known issues that occur with Windows 2000 SP3 server clusters and Kerberos.

How to Turn On Kerberos Support on an Existing Cluster That Has SP3 Installed

To turn on Kerberos so that a computer object is created for an existing virtual server:

Note In this section "network name cluster resource" refers to the clustered resource name for the network name as displayed on the General tab in the properties of the network name clustered resource.

On each node in the cluster, verify that the cluster service account has been granted the "Act as part of the operating system" user right on the local nodes.

To do so, follow the instructions that are described in "Cluster Service Account Does Not Have Proper User Rights on Local Node" section of the following Microsoft Knowledge Base article:

307532 How to troubleshoot the cluster service account when it modifies computer objects
Verify that the cluster service account has proper permissions in Active Directory. To do so, follow the instructions in the following Microsoft Knowledge Base article:

302389 Description of the properties of the cluster Network Name resource in Windows Server 2003
Apply SP3 to all nodes in the cluster.
Start Cluster Administrator, select the corresponding Network Name resource for which you want to turn on Kerberos support, and then take that resource offline.
Open a command prompt on one of the cluster nodes, and then type the following command:

cluster res "network name resource" /priv requirekerberos=1:dword
From Cluster Administrator, bring the Network Name resource online.

You can also use this procedure to turn on the RequireDNS property. To do so, substitute RequireDNS where RequireKerberos is specified. If you use the RequireDNS property, you can make sure that the resource goes online only if the virtual server's DNS records are successfully registered. If the RequireDNS property is set to 1, the DNS HOST (A) record for the virtual server must be registered. If it is not, the Network Name resource does not come online. If the DNS server accepts dynamic updates but the record is not updated, this behavior is considered a failure. If the DNS server does not accept dynamic updates (older versions of DNS) or if there are not any DNS servers that are associated with the resource's associated network, the Network Name resource still comes online.

Typically, if a Network Name resource does not come online after you turn on Kerberos support, the cluster service account may not have the correct permissions to Active Directory. If the resource does not come online, see the following Microsoft Knowledge Base article for more information about troubleshooting steps and how to verify the cluster service account has Write access to Active Directory:

307532 How to troubleshoot the cluster service account when it modifies computer objects

NOTE: If this particular installation of Windows 2000 is an upgrade from Microsoft Windows NT 4.0, review the "Cluster Service Account Does Not Have Proper User Rights on Local Node" in Q307532. Windows NT 4.0 does not grant the "Act as part of the operating system" right to the cluster service account. Therefore, if you upgrade to Windows 2000, this right is not granted. This right must be applied for the new Kerberos functionality to work. New installations of server clusters in Windows 2000 grant this right to the cluster service account during cluster Setup.

How to Set the RequireKerberos Property Before You Apply SP3

If you set the RequireKerberos property before you upgrade and if you have upgraded one node to SP3, client computers may encounter authentication problems to cluster resources while the rest of the nodes in the cluster are being upgraded to SP3. This behavior can occur in the following circumstances:

The RequireKerberos property is set to 1 on a Network Name resource.
A cluster node is upgraded to SP3.
The Network Name resource is hosted on the upgraded node, which causes a computer object to be created in Active Directory.
The Network Name resource is moved to a non-SP3 cluster node either because the upgraded node fails or resource's group has been moved.
A client that connects to the cluster node by using the Network Name resource receives a Kerberos ticket to the virtual server because of the presence of the computer object.
The Network Name resource that is hosted on the non-SP3 cluster node does not support Kerberos authentication and the client cannot authenticate.

If you have set the RequireKerberos property to 1 before you applied SP3, you must set the property value type to DWORD. If you do not do so and you install SP3, the Network Name resource does not go online. To recover from this situation, you can delete the Network Name resource, and then recreate it; however, if this issue occurs with the Cluster Name resource, you have to reinstall the cluster.

To set the RequireKerberos property before you upgrade to SP3, run the following command:

cluster res "network name resource" /priv requirekerberos=1:dword

To verify that the RequireKerberos property is a DWORD value, run the following command:

cluster res "network name resource" /priv

If a "D" appears in far left column for the RequireKerberos=1 property, this property is a DWORD value. After you verify the property, follow the instructions in the "How to Turn On Kerberos Support on an Existing Cluster That Has SP3 Installed" section of this article to turn on Kerberos support.

How to Rename a Virtual Server That Has Kerberos Support Turned On

You can use one of the two methods that are described in this section to rename a virtual server when Kerberos authentication is turned on. If you change the Network Name resource in Cluster Administrator, the Network Name resource fails because the computer object is not renamed. However, Windows Server 2003-based server clusters can change the name of the corresponding computer object.

You may find that Method 1 is easier to complete, but this method assumes that no child objects are associated with the computer object in Active Directory. Message Queuing (also known as MSMQ) is an example of a program that creates child objects. If you use Method 2, you must use ADSIEdit.msc, which is included in Windows 2000.

Method 1

If you perform this method, you temporarily turn off Kerberos support for the virtual server, delete the corresponding computer object, and then turn on and re-create the computer object:

Use Cluster Administrator to take the corresponding Network Name resource offline.
Open a command prompt on one of the cluster nodes, and the type the following command:

cluster res "network name resource" /priv requirekerberos=0
Start Active Directory Users and Computers, and then locate to the Computers organizational unit.
On the View menu, click Users, Groups, and Computers as Containers, and then verify that no child objects exist.

NOTE: If child objects are present, contact the program vendor that put these child objects there, and then ask them to verify that there is a way to re-create the child object after the virtual server's computer object has been deleted and re-created. If you cannot re-create the child object, use Method 2.
Delete the Network Name resources of the corresponding computer object from Active Directory Users and Computers.
While the corresponding Network Name resource is still offline, use Cluster Administrator to display the Parameters page of the Network Name resource, and then change the name of the virtual server.
Open a command prompt on one of the cluster nodes, and the type the following command:

cluster res "network name resource" /priv requirekerberos=1
Use Cluster Administrator to bring the Network Name resource online.

Note Microsoft only supports running Microsoft Distributed Transaction Coordinator (MSDTC) on cluster nodes as a clustered resource. Microsoft does not recommend running MSDTC in stand-alone mode on a cluster. Microsoft does not support this configuration. When you use MSDTC in a non-clustered resource on a Microsoft Cluster Service (MSCS) cluster, transactions could be orphaned. This results in data corruption if a cluster failover occurs.

Method 2

If you perform this method, you use ADSIEdit.msc to rename the computer object in Active Directory so that it matches the Network Name resource in Cluster Administrator. Install ADSIEdit.msc on any member server or domain controller. To install ADSIEdit run the Setup program in the Support folder on the Windows 2000 CD-ROM.

Start Cluster Administrator, and then take the corresponding Network Name resource offline.
In Cluster Administrator, display the Parameters page of the Network Name resource, and then change the name of the virtual server.
Start ADSIEdit.msc, expand the domain, and then locate the Computers organizational unit.
Right-click the corresponding Network Name resource's computer object, and then click Rename.
Rename the common name (also known as the CN) of the object, and then press ENTER.
Right-click on the corresponding Network Name resource's computer object, and then click Properties.
In the Select a property to view box, click DisplayName.
In the Select which properties to view box, click Both.
On the Edit Attribute line, type the new name of the virtual server.
Repeat Steps 5 to 7 for DNSHostName (in full DNS format) and SamAccountName (which is appended with a $).
In Cluster Administrator, bring the Network Name resource online.

NOTE: After you use ADSIEdit to rename the virtual server's computer object, you may have to wait for replication to occur for all domain controllers to receive the changes.

You Must Install the High Encryption Pack

You must install the 128-bit High-Encryption pack on all nodes of the cluster. For more information about the High-Encryption pack and to download the High Encryption pack, see the following Microsoft Web site:

http://www.microsoft.com/windows2000/downloads/recommended/encryption/default.mspx

If you do not install the High Encryption pack, you cannot bring the Kerberos-enabled Network Name resource online and the following data is logged in the cluster diagnostic log (Cluster.log):

0000032c.00000628::2001/11/29-22:33:22.703 Network Name VirtualServerName: Can't acquire crypto context for encrypt. status 2148073497.
0000032c.00000628::2001/11/29-22:33:22.703 Network Name VirtualServerName: Unable to store resource data. status 2148073497

The 2148073497 decimal status value converts to the 0x80090019 hexadecimal value, which indicates NTE_KEYSET_NOT_DEF.

Multiple Network Names Resources Do Not Come Online

If you have multiple Network Name resources in which Kerberos support is turned and you try to bring them online at the same time, a race condition may occur and some of the Network Name resources may initially fail. Because the resource restarts by default, you may not notice that the Network Name resources has failed. If this issue occurs, the following data is logged in the cluster diagnostic log:

Failed to enable TCB privilege, status C0000061 (STATUS_PRIVILEGE_NOT_HELD)
Failed to add credentials to LSA for computer account Cluster status 1314

NOTE: This error is the same error that occurs if the cluster service account does not have the "Act as part of the operating system" right. Use the procedure that is described in the following Microsoft Knowledge Base article to verify that the correct rights have been assigned:

307532 How to troubleshoot the Cluster service account when it modifies computer objects

Message Queuing Server Clusters and Windows 2000 SP3

Upgrades from Windows 2000 SP1 and SP2

If you upgrade a Message Queuing server cluster to SP3, a separate utility named Msmqprop.exe automatically runs during the upgrade. This utility automatically scans the cluster and sets the RequireKerberos property to 1 on any Network Name resource that the Message Queuing resource is dependent on. For Msmqprop.exe to run, the Cluster service that is installed on Windows 2000 must be running either SP1 or SP2 (not RTM). Msmqprop.exe creates a log file in the Windows_folder folder named Msmqprop.log, which indicates all of the actions that it runs.

Permissions on the Computer Object

Windows 2000 Message Queuing server clusters with Service Pack 3 require permissions in the domain. The cluster service account must have the "Create Child Objects" permission to the virtual server's computer object. This additional permission is required because Message Queuing creates child objects underneath the virtual server's computer object. To add these permissions, perform these steps on the domain controller:

Start Active Directory Users and Computers from the Administrative Tools folder.
On the View menu, click Advanced Features.
Expand the domain, and then double-click on the virtual server's computer object that Message Queuing will be dependent on.
Click the Security tab, and then click Add.
Expand the domain, double-click the cluster service account, and then click OK.
Click the cluster service account, click to select the for Create All Child Objects check box, and then click OK.

The cluster service account now has permissions to create child objects on the virtual servers computer object which allows the creation of the Message Queuing object. If there are multiple domain controllers, you may have to wait for replication to occur for the changes to be applied to all domain controllers.

New Installation of a Message Queuing Server Cluster

To create a Message Queuing server cluster by using Kerberos authentication by running Windows 2000 SP3:

Install Windows 2000 on all nodes in the Cluster.

For a step-by-step guide to perform this task, visit the following Microsoft Web site:

http://technet.microsoft.com/en-us/library/Bb727114.aspx
Turn off all nodes except Node_A.
Configure the shared disk from Node_A.
Use Control Panel to install and configure Microsoft Cluster service and Message Queuing on Node_A.

NOTE: Install Message Queuing by using the Add/Remove Programs tool but do not create a Message Queuing cluster resource for Message Queuing at this time.
Turn on the other nodes in the cluster.
Use Control Panel to install and configure Microsoft Cluster service and Message Queuing on the remaining nodes in the cluster

NOTE: Have Microsoft Cluster service join the existing cluster and install Message Queuing, but do not make a Message Queuing cluster resource for Message Queuing at this time.
Apply SP3 to Node_A, and then restart the computer.

Any group that was owned by Node_A will fail to another node in the cluster.
Apply SP3 to all other nodes in the cluster.
Run Comclust to configure a Microsoft Distributed Transaction Coordinator (MSDTC) resource on the cluster. For more information about how to use Comclust, click the following article number to view the article in the Microsoft Knowledge Base:

243204 Microsoft Distributed Transaction Coordinator (MSDTC) recovery techniques in Windows 2000 Cluster Server
Rename an existing group (other than the cluster group) that contains a disk resource to an appropriate name (for example, Message Queuing Group.
In Message Queuing Group, create an IP resource and a Network Name resource (Message Queuing Cluster Name), and then leave them offline.
From a command prompt on Node_A, run the following command:

cluster res "Message Queuing cluster name" /priv requirekerberos=1:dword
Verify that the RequireKerberos has been set correctly and that it is a DWORD value. To do so, the following command from a command prompt:

cluster res "Message Queuing cluster name" /priv

If "D" appears in the far left column for the RequireKerberos=1, property, this property is a DWORD value.
Bring Message Queuing Group online for Node_A.

NOTE: If Message Queuing Cluster Name does not come online, review the troubleshooting steps in the following Microsoft Knowledge Base articles:

302389 Description of the properties of the cluster Network Name resource in Windows Server 2003

307532 How to troubleshoot the cluster service account when it modifies computer objects
Start Active Directory Users and Computers, and then verify that a computer object was created for the Message Queuing Cluster Name resource.
Move Message Queuing Group to all nodes in the cluster to verify that Kerberos support is properly running on all nodes.
Follow the instructions in the "Permissions on the Computer Object" section of this article to give the cluster service account the proper permissions to create the Message Queuing object.
Create a Message Queuing resource in Message Queuing Group, and then bring this resource online.
Move Message Queuing Group to all nodes in the cluster to verify that the Message Queuing resource runs on all nodes in the cluster.

File Replication Service and Server Clusters

The File Replication Service (FRS) does not replicate with a file share that is on a server cluster under a virtual server's computer object. The FRS service only looks for subscription information under the node's computer object, and it does not scan the virtual server's computer object. Distributed File System (DFS) uses FRS to replicate data among multiple servers when a replication policy is enabled. If the DFS link with the replication policy is a virtual server, data is not replicated with any other partner. You may have to use another method (for example, a file copy script) to replicate the data.

Windows Installer Packages That Are Assigned to Computers with Group Policy Now Work

In earlier versions of Windows 2000, a Windows Installer package that is stored on a server cluster file share cannot be deployed because the computer account that receives the package only authenticates by using Kerberos and not NTLM. In Windows 2000 SP3, if you set the RequireKerberos property value to 1 for the Network Name resource that the file share resource is dependent on, the Windows Installer is deployed by using Group Policy. See the "How to Turn On Kerberos Support on an Existing Cluster That Has SP3 Installed" section in this article for more information about how to turn on Kerberos support.

How to Turn Off Kerberos Support for a Virtual Server

If you experience authentication issues after you turn on Kerberos support for the virtual server, you can turn off the support. To turn off Kerberos support, you must delete the corresponding computer object manually.

Start Cluster Administrator, select the corresponding Network Name resource for which you want to turn off Kerberos support, and then take that resource offline.
Open a command prompt on one of the cluster nodes, and then type the following command:

cluster res "network name resource" /priv requirekerberos=0
Start Active Directory Users and Computers, and then delete the corresponding computer object.
From Cluster Administrator, bring the Network Name resource back online.

Changing Domains with Kerberos Enabled

If you try to change the domain that the cluster nodes are members of after Kerberos has been enabled, the Network Name will fail to come online. To resolve this problem, set RequireKerberos=0 one time in the new domain, bring it online, and then set RequireKerberos=1 so that the Cluster Service will create a new computer object in the new domain. You may have to delete the record in DNS and verify that it is updated.

For general information about changing domains for cluster nodes, click the article number below to view the article in the Microsoft Knowledge Base:

269196 How to move a Windows NT 4.0 cluster server from one domain to another

REFERENCES

For more information, click the following article numbers to view the articles in the Microsoft Knowledge Base: