Windows Server 2025 — Kerberos PAC Validation and Failover Cluster Authentication

1. What is happening?

When you introduce the first Windows Server 2025 node into an existing Failover Cluster that was previously running Windows Server 2016/2019 (or a mixed older environment), Kerberos authentication between that node and Active Directory (and sometimes between nodes) can start failing.

The cluster usually continues to run in a degraded state, but you see authentication errors that did not exist before the 2025 node joined.

This is not primarily a duplicate SID problem (although the error message looks similar).

2. Typical Symptoms

After the Windows Server 2025 node joins the cluster you may observe:

  • Kerberos authentication failures involving the new node and Active Directory

  • Intermittent or degraded cluster operations

  • Errors logged almost exclusively on the Windows Server 2025 node(s)

  • Messages similar to:

    There is a partial mismatch in the machine ID. This indicates that the ticket issued by user NULL SID has either been manipulated or it belongs to a different boot session. Failing authentication.

  • Tools that check machine SIDs report that all nodes have unique SIDs

  • The cluster worked correctly before the 2025 node was added

3. Root Cause (simple explanation)

Windows Server 2025 enforces strict Kerberos Privilege Attribute Certificate (PAC) validation.

This is the final stage of security hardening started with the April 2024 updates that addressed CVE-2024-26248 and CVE-2024-29056. Older Windows versions could still accept certain tickets under compatibility rules. Windows Server 2025 no longer does.

During an in-place upgrade path (2016 → 2019 → 2025) the following frequently happens:

  1. The machine account password stored locally (LSA secrets) drifts from the password stored in Active Directory.
  2. Cached Kerberos tickets from previous boot sessions or older OS behaviour remain on the node.
  3. The Netlogon secure channel is no longer perfectly healthy.
  4. Windows Server 2025 rejects the resulting tickets because of the stricter PAC checks.

The result is authentication failures even though:

  • The computer object still exists in Active Directory
  • The machine SID is unique
  • The node appears domain-joined

4. Why “SID uniqueness” checks are misleading

Commands such as wmic, Get-ADComputer, or third-party SID tools only verify that the machine SIDs are different.

Kerberos trust health depends on completely different things:

  • Health of the Netlogon secure channel
  • Synchronization of the machine account password
  • Integrity of the LSA secrets
  • Validity of the Kerberos tickets currently held
  • State of the computer object in Active Directory

Unique SIDs are necessary but not sufficient.

5. Proven Resolution (recommended path)

The correct and least disruptive fix is to force the affected node to re-establish a clean trust relationship with Active Directory before or immediately after it joins the cluster as Windows Server 2025.

Perform the following steps node by node from an elevated PowerShell session on the Windows Server 2025 node.

Step 1 — (Optional but recommended) Drain the node

PowerShell

# From another cluster node or management station
Suspend-ClusterNode -Name "NodeName" -Drain

Step 2 — Repair the Netlogon secure channel

PowerShell

Test-ComputerSecureChannel -Repair -Verbose

This is often the single most effective command.

Step 3 — Reset the machine account password

PowerShell

# Preferred form (provide domain credentials that can reset computer objects)
Reset-ComputerMachinePassword -Server "AnyReachableDC" -Credential (Get-Credential)

# Alternative (works in many cases when the current context still has partial trust)
Reset-ComputerMachinePassword

Step 4 — Clear all cached Kerberos tickets

PowerShell

klist purge
klist -li 0x3e7 purge   # also clears the SYSTEM account tickets

Step 5 — Restart the node

PowerShell

Restart-Computer -Force

Step 6 — Resume the node and verify

PowerShell

Resume-ClusterNode -Name "NodeName"

6. Verification after the fix

Run these checks on the repaired node:

PowerShell

# Secure channel health
Test-ComputerSecureChannel -Verbose

# Should return True
nltest /sc_query:YourDomain

# Fresh tickets should appear after reboot
klist

Also confirm in the System event log that Event ID 6167 (LsaSrv) related to machine ID mismatch has stopped appearing.

Cluster communication and authentication should now succeed under the stricter PAC validation rules of Windows Server 2025.

7. Last-resort remediation

If the four commands above do not permanently resolve the issue (rare, but documented), the machine identity itself is too corrupted. In that case:

  1. Evict the node from the cluster.
  2. Run Sysprep (Generalize) and rejoin the domain.
  3. Add the node back to the cluster.

This regenerates a completely new machine account and LSA secrets. It is significantly more disruptive and should only be used when the supported repair path fails.

8. Prevention for future upgrades

When performing rolling upgrades to Windows Server 2025:

  • Prefer resetting the secure channel before the node is upgraded or immediately after the OS upgrade completes and before rejoining the cluster.
  • Avoid long periods of mixed OS versions in the same cluster when possible.
  • After any in-place upgrade, proactively run Test-ComputerSecureChannel -Repair as part of the post-upgrade checklist.

Summary

Item Reality
Is this a real issue? Yes — observed during 2016/2019 → 2025 rolling upgrades
Main trigger Stricter PAC validation in Windows Server 2025 + residual trust state from in-place upgrades
SID uniqueness checks Not sufficient for diagnosis
Recommended first action Test-ComputerSecureChannel -Repair + Reset-ComputerMachinePassword + ticket purge + reboot
Last resort Sysprep + domain rejoin

The repair sequence above is the proven, Microsoft-supported method for restoring machine-account Kerberos trust and is the correct first response when this specific symptom appears after introducing Windows Server 2025 into a Failover Cluster.

Sources