WSFC: Access denied when creating a Cluster with active Security Baseline Settings

Question

WSFC: Access denied when creating a Cluster with active Security Baseline Settings

Holster 10

We Setup 2 new Windows Server 2025 and wanted to use Windows Server failover Cluster for our application. Additionally we' re applying Security Baseline Policy für Server 2025 - Member Server, Defender Antivirus & Credential GuardWhen trying to setup the Cluster, it fails at the first step "Select Servers" with "You do not have administrative privileges on the server "xxx" (Server Node B)

we tried to move one Clustenode outside the OU where the MS Baselines do not apply and where able to select the second node successfully. Interessting enough Node B (without Baselines) was able to add Node A (with Baselines) but not wise versa.

excluding the Baseline Policies is not an option for us. so far we tried the following settings without any success:

Allow Custom SSPs and APs to be loaded into LSASS --> enabled

Access this Computer from network --> NT Authority\System, NT Authority\Authenticated Users, Builtin\Administrators

Deny Access to this computer from network --> [empty]

Restrict Unauthenticated RPC Clients --> disabled

WinRM Client Settings:

Allow Basic authentication --> enabled

Allow unencrypted traffic --> enabled

Disallow Digest authentication --> disabled

WinRm Service Settings:

Allow Basic authentication --> enabled

Allow unencrypted traffic --> enabled

Disallow WinRM from storing RunAs credentials--> disabled

any idea which of the many security Baseline Policy Settings could be the culprit here?

0 comments

1 answer

Your answer

Answer 1

Hello @Holster

The behavior strongly suggests that one of the Windows Server 2025 security baseline authentication/remote administration settings is blocking the Failover Cluster Manager's remote validation, rather than an actual lack of administrator permissions.

The fact that Node B without the baseline can add Node A, but Node A with the baseline cannot add Node B, is particularly useful. It points to a restriction affecting outbound/remote authentication from the hardened node.

I would not enable Basic authentication or unencrypted WinRM as a workaround. WSFC doesn't require weakening those settings, and doing so defeats part of the purpose of applying the baseline.

First, confirm whether Credential Guard/credential delegation is involved. Windows Server 2025 enables Credential Guard by default on eligible domain-joined member servers, and Microsoft's baseline further hardens credential protection and delegation.

Check the effective policy on both nodes rather than only the configured GPO:

gpresult /h C:\Temp\gpresult.html
Get-CimInstance -ClassName Win32_DeviceGuard `
  -Namespace root\Microsoft\Windows\DeviceGuard

Also test clustering outside the GUI:

Test-Cluster -Node NodeA,NodeB -Verbose

Then check Event Viewer > Windows Logs > Security/System on both nodes for authentication failures at the same timestamp. Kerberos/NTLM failures, credential delegation failures, or RPC access-denied events should identify which policy is actually responsible.

Another important check, especially if these Server 2025 VMs were created from a template, is whether the nodes have duplicate machine SIDs. Microsoft has documented that newer Windows Server security protections can cause Kerberos/NTLM authentication failures and specifically lists Failover Clustering failing with "Access denied" as a symptom of duplicate SIDs.

I would therefore compare that possibility before changing the baseline further.

Also confirm that the account creating the cluster has the required permissions and that the Cluster Name Object (CNO) can be created in AD, although your failure at the Select Servers stage makes CNO creation less likely to be the immediate issue. Microsoft documents the AD account requirements separately.

So my troubleshooting order would be: effective GPO → Credential Guard/delegation → Kerberos/NTLM events → duplicate SID check → Test-Cluster. Since removing the baseline from Node B changes the behavior, comparing gpresult between the two nodes should also narrow down the exact setting without disabling the entire baseline.

Microsoft recommends testing and customizing the Server 2025 baseline where application or operational requirements conflict with individual settings; the baseline isn't intended to mean that every setting must remain unchanged for every server workload.

Sharing these references with you:

Windows Server 2025 Security Baseline

Credential Guard Overview

Failover cluster accounts overview

Microsoft: Kerberos/NTLM failures due to duplicate SIDs

Please "Accept the Answer" if this information helped you. This will help us and others in the community.