The cluster identity may lack permissions required to update the object

To resolve the issue where the cluster identity may lack permissions required to update the computer object, you should check the following:

1. Permissions for Cluster Identity: Ensure that the cluster identity (in your case, 'CLPWGIRSQL$') has the necessary permissions to update computer objects in Active Directory. You may need to work with your domain administrator to verify and adjust these permissions.
2. Password Synchronization: Verify that the password for the cluster name account matches the password stored in Active Directory. If there is a mismatch, you may need to reset the password for the cluster name account.
3. Active Directory Object Repair: If permissions are correct but the issue persists, consider using the "Repair Active Directory Object" option in the Failover Cluster Manager. This option will help synchronize the Active Directory password for the cluster name account.
4. Cluster Validation: Run a cluster validation (excluding the storage section) to check for any misconfigurations that might affect the cluster's ability to update the computer object.
5. Event Logs: Review the system and cluster logs for any additional error messages that might provide more context about the failure. Look for Event IDs 1069 and 1207, as they often indicate issues with cluster resources.

By following these steps, you should be able to identify and resolve the permission issues affecting your cluster identity.

References:

• Troubleshoot password issues with the cluster name account
• Can't bring a network name online in a failover cluster

Hi VPHAN!!!.

We believe that the problem occurs during the Cluster Update Process.

It is a cluster of 2 nodes.

To update the cluster, We cloned the Passive Node!!!.

Then We renamed the cloned node and added it to the cluster!!!.

Name                 ID    State

----                 --    -----

PWGIRSQL1            1     Up

PWGIRSQL2            2     Up

PWGIRSQL3            3     Up

PWGIRSQL3 is the New Node.

But in Node PWGIRSQL2:

The computer object associated with the cluster network name resource 'Cluster Name' could not be updated in domain 'telecom.arg.telecom.com.ar' during the

Password change operation.

The text for the associated error code is: The specified network password is not correct.

The cluster identity 'CLPWGIRSQL$' may lack permissions required to update the object. Please work with your domain administrator to ensure that the cluster identity can update computer objects in the domain.

What do you think?

Good morning Lucas Peñaloza,

FYI, this error shows a breakdown in the secure channel between the cluster's computer account (CLPWGIRSQL$) and Active Directory, specifically during the periodic password update process. The cluster name object (CNO) in Active Directory has a password that the cluster service automatically rotates; when the stored password on the cluster nodes becomes desynchronized from the one in AD, or when the CNO lacks the necessary permissions to update its own attributes, this exact error occurs.

First, verify the cluster identity's permissions in Active Directory. The account CLPWGIRSQL$ must have Reset Password and Write permissions on its own computer object. Using Active Directory Users and Computers with advanced features enabled, locate the computer object for CLPWGIRSQL$, open its Properties > Security > Advanced. Ensure the account itself is listed with at least Reset Password and Write permissions. If not, you or your domain administrator must restore these permissions, which can be done by right-clicking the cluster object in Failover Cluster Manager and selecting Repair Active Directory Object. This action re-engages the default permission grant.

If permissions are correct, the password itself is likely mismatched. The most direct fix is to use the cluster repair function. In Failover Cluster Manager, navigate to the cluster name resource under Cluster Core Resources. Right-click the cluster name resource (usually named Cluster Name) and choose More Actions > Repair Active Directory Object. This will attempt to reset the password and re-sync the permissions. If the option is grayed out, you may need to bring the cluster name resource offline first.

Should the repair action fail, manually reset the computer account password from a domain controller. Open an elevated Command Prompt and run:

text

netdom resetpwd /s:<DomainController> /ud:<Domain>\<AdminAccount> /pd:*

You will be prompted for the admin password. Alternatively, you can use PowerShell on a domain controller: Reset-ComputerMachinePassword -Server <DomainController> -Credential <DomainAdminCredential>. After resetting, restart the cluster service on all nodes and bring the cluster name resource back online.

Additionally, check for duplicate computer objects in AD that might be causing conflict, and ensure the cluster computer account is not disabled. Monitor the cluster logs and AD events for subsequent errors, particularly Event ID 1069 for resource failures and Event ID 1207 for cluster network name updates.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to ACCEPT ANSWER then. Should you have more questions, feel free to leave a message. Have a nice day!

VPHAN

Hi VPHAN!!!.

Thank you for your information!!!!.

I need to contact the Domain Administrator and perform these validations.

Now in the case of, to use cluster repair function, The cluster will present drawbacks????.

Thanks!!!.

Good day Lucas Peñaloza,

I hope you''ll find something useful in the following explanation, and if it helps you get more insight into the issue, it's appreciated to accept the answer.

Using the Repair Active Directory Object function in Failover Cluster Manager is a safe, supported, and non-destructive operation when performed correctly. However, there are important operational considerations to be aware of to avoid downtime.

Potential Drawbacks & Mitigations:

1. The repair process will temporarily take the Cluster Name resource offline. This means client connections relying on the cluster network name (e.g., \\ClusterName\Share) will be briefly interrupted. SQL Server client connections using the SQL Server Network Name will drop and must reconnect. Schedule the repair during a maintenance window. Before starting, manually bring the Cluster Name resource offline in a controlled manner to gracefully inform connected clients.
2. The repair action requires that the cluster nodes can communicate with each other and with a domain controller. If there are underlying network or cluster communication issues, the repair may fail or hang. You can run Test-Cluster to validate cluster health before attempting the repair. Ensure all nodes have network connectivity to a domain controller.
3. The function resets the Reset Password and Write permissions for the cluster computer object (CLPWGIRSQL$) to the default. If your environment uses custom permissions on this object, they will be reverted to the defaults. So you need to document any custom permissions before the repair. They can be reapplied afterwards if necessary.

For the procedure to be safe, I recommend:

Pre-Check: In Failover Cluster Manager, under Cluster Core Resources, note which node currently owns the Cluster Name resource.

Initiate Repair:

Right-click the Cluster Name resource.

  Select More Actions > Repair Active Directory Object.
  
     If the option is grayed out, you must first right-click and choose Take Offline. Confirm, then the repair option should become available.
     
     Monitor: The resource will go offline, perform the repair (which resets the password and permissions in AD), and then come back online. This typically takes 30-60 seconds.
     
     Verification: After the repair, check the cluster events for a successful operation (Event ID 1207 or similar). Also, verify the cluster name resource is online and that clients can connect.
     

If the repair function fails or you can't afford any resource downtime, the alternative is the manual password reset method using netdom resetpwd or PowerShell's Reset-ComputerMachinePassword from a domain controller. This can be done without taking the cluster resource offline, but it requires direct domain controller access and may need to be coordinated with the domain administrator.

Should you have any questions, feel free to ask.

VP