The cluster identity may lack permissions required to update the object

Hi Lucas,

The information about cloning the passive node is the "smoking gun." Cloning a domain-joined cluster node is a critical violation of Microsoft supportability and Active Directory mechanics. This action is almost certainly the root cause of the password synchronization failure you are seeing on PWGIRSQL2. To analyze the Root Cause (SID and Machine Password Duplication), when you cloned PWGIRSQL2 to create PWGIRSQL3, you didn't just copy the files; you copied the Machine Account Password and potentially the Local Security Identifier (SID) (unless you ran Sysprep properly). Here came the conflict__:__ Active Directory relies on a secure channel password that rotates automatically (usually every 30 days). If PWGIRSQL3 (the clone) updated the machine password with the Domain Controller, PWGIRSQL2 (the source) now has an "old" password locally that the Domain Controller no longer recognizes. Since the Cluster Service runs on top of these OS credentials, when PWGIRSQL2 tries to talk to the Cluster Name Object (CLPWGIRSQL$) in AD to update the CNO password, the authentication fails because the secure channel of the node itself is broken or confused by the duplicate identity artifacts.

You cannot simply "fix" the cloned node while it is live in the cluster. You must remove the compromised node to restore stability. Here is my suggestion:

Step 1: Validate the Healthy Node (PWGIRSQL1) Ensure that your primary node (PWGIRSQL1) is hosting all resources (SQL Server, etc.) and is functioning correctly.

Step 2: Evict the Problem Node (PWGIRSQL2) Since PWGIRSQL2 is the source of the clone and is throwing errors, it is "tainted."

Open Failover Cluster Manager.

Right-click PWGIRSQL2 -> More Actions -> Evict.

This removes the node from the cluster configuration so it stops trying to corrupt the CNO credentials.

Step 3: Fix the Trust Relationship on PWGIRSQL2 (or Reinstall)

Option A (Reinstall - Recommended): Format PWGIRSQL2 and install the OS fresh. This guarantees no lingering SID duplication issues.

Option B (Re-join): Remove PWGIRSQL2 from the domain (join a Workgroup), reboot, deleting the computer account in AD, and then re-join the domain. This forces a new SID and machine password.

Step 4: Repair the Cluster Name Object (CNO) Now that the "bad" node is gone, perform the repair action we discussed earlier on the surviving node (PWGIRSQL1).

Right-click Cluster Name -> More Actions -> Repair Active Directory Object.

This ensures the CNO (CLPWGIRSQL$) is perfectly synced with the surviving authoritative node.

Step 5: Re-add PWGIRSQL2 Once PWGIRSQL2 is fresh (reinstalled or fully re-joined) and showing "Ready" in validation, add it back to the cluster using the Add Node wizard.

Important Warning regarding PWGIRSQL3: If PWGIRSQL3 was created via cloning without running Sysprep /generalize, it is also a time-bomb. It is highly recommended to eventually evict it and reinstall it properly from an ISO, rather than a clone. For now, prioritize fixing PWGIRSQL2 to regain redundancy.

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

VP

Hi Lucas Peñaloza,

How was your issue? Is everything OK? If the issue has been resolved, don't forget to accept the answer so that other people sharing the same problem would benefit too. If you need more assistance, feel free to reach out.

VP

Hi Vphan!!!.

Yes,

We know that the process we are using is not the correct one!!!.

But we have no alternative!!!.

We are working with an obsolete infrastructure and cannot implement new infrastructure.

Originally, the production cluster consisted of 2 nodes. We added a third node solely to maintain high availability while we updated the operating systems of the other nodes and ultimately the cluster.

We will implement what is indicated here!

We'll be in touch.

Hi Lucas,

Understood. In legacy environments, operational continuity often forces us to engineer "unorthodox" solutions to maintain uptime during migrations. Since you are locked into this path and proceeding with the eviction of PWGIRSQL2 while relying on the cloned PWGIRSQL3 to maintain High Availability, there is one critical technical constraint you must navigate to avoid a total cluster blackout.

When you rebuild or re-introduce PWGIRSQL2, you must not clone it from PWGIRSQL3 or use the same source image that created PWGIRSQL3 unless that image was properly generalized with Sysprep /generalize. If PWGIRSQL3 (currently active) and the newly reintroduced PWGIRSQL2 share the exact same Machine SID (Security Identifier) within the same domain, Active Directory will identify them as the same security principal. This will cause the Kerberos Ticket Granting Ticket (TGT) to fail for whichever node authenticated last, causing the Cluster Service (clussvc.exe) to terminate immediately on one or both nodes due to authentication failure. You can verify the machine SID on PWGIRSQL3 by running whoami /user in an administrative command prompt; ensure the new PWGIRSQL2 has a distinct final RID (Relative Identifier) in its SID before joining it to the cluster.

Furthermore, since you are performing an OS upgrade in a mixed-mode state (likely a Cluster OS Rolling Upgrade), ensure you do not run the PowerShell command Update-ClusterFunctionalLevel until all nodes, including the rebuilt PWGIRSQL2, are running the target operating system version and the cluster is fully stable. Triggering the functional level update while the cluster is in this fragile, "identity-compromised" state is irreversible and could permanently corrupt the cluster database (ClusDB) if the nodes cannot negotiate the new feature set correctly. Focus on stabilizing the identity of PWGIRSQL2 via a clean OS install/domain join first, then let the cluster replication heal the CNO permissions.

VP

Vphan;

We removed the computer PWGIRSQL2, from the domain!!!.

Then, from PWGIRSQL1, ran Cluster Validation and it Never End!!!.

Can I cancel It?

Thanks!!!.