Forum Discussion
Server 2025 Security Baseline breaks Failover Cluster
Hello everyone,
while testing the Server 2025 Security Baseline with our Hyper-V Hosts in a Failover Cluster, we noticed the Cluster Service (ClusSvc) was unable to start correctly. It failed with Event 7024 - "A specified authentication package is unknown". From testing and the event logs, we noticed that the .dll file "CLUSAUTHMGR.DLL" was unable to load. After setting "Allow Custom SSPs and APs to be loaded into LSASS" to "Disabled", we were able to start the service again. I assume that the cluster auth manager .dll is not recognized as a trusted Microsoft SSP/AP and therefore blocked as "custom" when enabling this setting.
Has anyone tested this using Hyper-V clusters and/or made similar observations?
(P.S.: Before debugging, we should have googled, since apparently we are not the only one to have this issue: https://jigsolving.com/failover-cluster-service-wont-start-server-2025/
3 Replies
hoanghunggMicrosoft
Thanks for flagging this! One thing I’m trying to reconcile — the baseline doesn’t enforce the setting to block custom SSPs/APs on Member Server instances, so not totally sure why you are hitting this issue. Would love to understand more about the environment where this is happening.
Hi hoanghungg, it seems that was a mistake on our part - enforcing and mixing up some settings that are part of the Client Security Baseline made their way into our Member Server Security Baseline GPO.
Nevertheless, it's good to see this getting attention, as we would be happy to be able to enforce this on Member Servers, too!
Hi PhilippZiemke,
The security baseline setting is blocking certain custom authentication packages, like CLUSAUTHMGR.DLL, which is needed by the Cluster Service. Disabling the "Allow Custom SSPs and APs" setting seems to fix it because it allows these packages to load. It’s a known issue with the security baseline, and the workaround you found is correct. If you want to keep the security baseline enabled, you might need to find a way to explicitly allow that .dll or modify the security settings to avoid blocking trusted packages like this one.
For that you’ll need to adjust the local security policy or group policy settings. One option is to modify the "LSA Protection" settings and configure it to allow trusted packages. You can also add the specific .dll file to an allowlist or change the Group Policy to enable custom authentication packages. If you're using a GPO, you can update it to permit this specific .dll. You’ll likely need to modify the “Security Options” in Group Policy or registry settings to ensure it is recognized as a trusted package. Make sure to test the changes in a controlled environment before applying them to production.
Hope it helps, Let me know how it goes.
