Windows 11 24H2 Sec Baseline → Broken SSO to on‑prem (Root cause: PKINIT SHA‑1 baseline)
Hi all, I ran into an issue with Entra-joined devices using Windows Hello for Business (Cloud Kerberos Trust) that might help others working with Windows 11 24H2 security baselines. Scenario Windows 11 25H2 devices Entra-joined (not hybrid) Intune-managed Windows Hello for Business (WHfB) enabled Cloud Kerberos Trust configured On-prem AD (Windows Server 2019/2022 DCs) Access to SMB shares / on-prem applications Symptoms SSO to on-prem resources fails Users get credential/PIN prompt instead of SSO Error message: “The system cannot contact a domain controller to service the authentication request” Client-side observations: klist → no tickets (initially) After enabling Cloud Kerberos Trust: klist get krbtgt → works klist get cifs/server.domain → fails Error: 0xc000a100 / 0x3bc4 Hash generation for the specified version and hash type is not enabled on server Root Cause The issue was caused by a Windows 11 24H2 security baseline setting related to Kerberos/PKINIT. The 24H2 baseline introduces a policy for configuring hash algorithms for certificate-based Kerberos authentication (PKINIT). This setting allows environments to disable SHA-1 and require SHA-2 algorithms. [applepie.se] Important detail: This configuration only works if the domain controllers fully support PKINIT with SHA-2, which effectively requires Windows Server 2025 domain controllers across the environment. If SHA-1 is disabled while running: Windows Server 2019 or 2022 DCs Mixed environments then PKINIT authentication fails, which directly impacts: Windows Hello for Business Cloud Kerberos Trust Any passwordless Kerberos-based authentication Why this is difficult to troubleshoot Cloud Kerberos Trust appears correctly configured AzureADKerberos object exists PRT is valid Network connectivity is fine However: Kerberos tickets are not issued correctly Service tickets (CIFS, HTTP, etc.) fail Errors are misleading and point to KDC/hash issues No explicit warning is provided in baseline guidance that mixed environments will break Resolution Revert the baseline change and allow SHA-1 for PKINIT again. Policy location: Computer Configuration → System → Kerberos / KDC → Configure hash algorithms for certificate logon Ensure: SHA-1 is set to Allowed/Default After reverting: Kerberos ticket issuance works SSO to on-prem resources is restored Recommendation Do not disable SHA-1 for PKINIT unless: All domain controllers are Windows Server 2025, and PKINIT SHA-2 support has been fully validated Treat this setting as future hardening, not production-safe for mixed environments today. Takeaway If you experience: WHfB + Cloud Kerberos Trust SSO failures klist get errors with hash generation issues Missing or failing Kerberos service tickets check the PKINIT hash configuration from the 24H2 security baseline first.
Start strong with MCSB v2
Cloud adoption is accelerating, but so are threats. Organizations often rush to deploy workloads without a clear security baseline, leaving critical gaps that attackers can exploit. Enter Microsoft Cloud Security Benchmark (MCSB) v2, now in public preview, designed to help you start well-protected and evolve securely. What Is Microsoft Cloud Security Benchmark v2? MCSB v2 is a comprehensive set of best practices and controls for securing cloud resources across Azure and hybrid environments. It aligns with: Industry standards: NIST, CIS, ISO Microsoft Secure Future Initiative (SFI) Zero Trust principles This benchmark provides prescriptive guidance for identity, network, data, and workload security helping organizations establish a strong foundation before customizing for their unique needs. Security Domains in MCSB v2 The benchmark organizes guidance into security domains, each representing a critical area of cloud security: Identity Management MFA enforcement, Conditional Access, privileged identity management. Network Security Segmentation, firewall rules, private endpoints. Data Protection Encryption at rest and in transit, key management. Asset Management Resource inventory, tagging, and governance. Logging & Monitoring Centralized logging, alerting, and SIEM integration. Incident Response Playbooks, automation, and escalation workflows. Application Security Secure coding practices, vulnerability scanning. Compliance & Governance Policy enforcement, regulatory alignment. Security Control Structure Each control in MCSB v2 follows a structured format for clarity and implementation: Control ID: Unique identifier for tracking. Control Name: Descriptive title (e.g., “Enable MFA for all users”). Control Category: Maps to a security domain. Control Objective: What the control aims to achieve. Implementation Guidance: Detailed steps for configuration. Azure Policy Mapping: Built-in policy definitions for automation. References: Links to Microsoft Learn and industry standards. This structure ensures consistency, traceability and ease of adoption across large environments. Integration with Azure Policy & Defender for Cloud One of the most powerful aspects of MCSB v2 is its native integration with Azure governance and security tools: Azure Policy Pre-built policy initiatives mapped to MCSB controls. Enables policy-as-code for automated enforcement across subscriptions. Supports compliance dashboards for visibility and reporting. Microsoft Defender for Cloud Monitors compliance against MCSB controls in real time. Provides secure score and recommendations for remediation. Integrates with workflows for alerting and automation. How to Get Started Review the Benchmark Explore the full guidance here: https://learn.microsoft.com/en-us/security/benchmark/azure/overview Apply Built-In Policies Use Azure Policy initiatives mapped to MCSB controls for quick enforcement. Monitor Compliance Leverage Microsoft Defender for Cloud to track adherence and remediate gaps. Tune for Your Needs Start with the baseline, then customize based on workload sensitivity and business requirements. Best Practices for Organizations Enable MFA and Conditional Access for all identities. Segment networks and enforce least privilege. Encrypt data at rest and in transit using Azure-native capabilities. Enable Defender for Cloud for continuous posture management. Automate compliance with policy-as-code. Cloud security isn’t static. Threats evolve, and so should your defenses. MCSB v2 gives you a future-ready foundation that scales with your business and integrates with Microsoft’s security ecosystem.
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/
[Updates] GPOs Configure Automatic Updates vs. Specify deadlines for automatic updates and restarts
Dear all, we have about 500 Windows servers in our Standalone WSUS environment. I would like to change local GPOs for the (new) non-AD-members, so the compliance related to Windows Updates is improving. Mostly we are using GPO Cofigure Automatic Updates with AU options 4 (schedule the install) as of today. As far as I know, the new GPO “Specify deadlines for automatic updates and restarts” ignores the Configure Automatic Updates GPO with all the AU options (See https://learn.microsoft.com/en-us/windows/deployment/update/wufb-compliancedeadlines), so they can not be combined together. Question 1: Is it true? Do you have some up-to-date information about that? Reading through the update baselines https://www.microsoft.com/en-us/download/details.aspx?id=101056, as far as I can see, the Configure Automatic Updates GPO will be not supported in the future and some related GPO settings are not even recommended due to this reason because they might not work as intended. Question 2: Is it true? Do you have some up-to-date information about that what is still supported? Question 3: Do you know a deadline to deprecate the Configure Automatic Update GPO by Microsoft? (We are planning to have some scheduler settings to begin the installation of Windows Updates and as I can see, “Specify deadlines for automatic updates and restarts” can not do that (it can only schedule the restart) and Configure Automatic Update GPO seems to be moved out from support slowly.) I also checked this material but could not find a focused material for Windows Updates only, especially for servers: https://www.microsoft.com/en-us/download/details.aspx?id=55319 Question 4: Do you have where to find such a material for Windows Updates only or who to ask for them? (Mostly for Windows Server 2016, 2019 and 2022). Many thanks upfront for your answers.DSC SecurityPolicyDsc: "Could not infer CimType from the provided .NET object"
Hello Everyone, I'm encountering a persistent issue while applying security baseline settings using the SecurityPolicyDsc module on Windows Server 2022. Despite providing valid settings (like Accounts_Limit_local_account_use_of_blank_passwords_to_console_logon_only = 'Enabled'), the DSC execution fails with the following error: Could not infer CimType from the provided .NET object. The PowerShell DSC resource '[SecurityOption]LimitBlankPasswords' with SourceInfo '<file path>::SecurityOption' threw one or more non-terminating errors while running the Test-TargetResource functionality. What I've done so far: Verified the syntax and parameters using only one setting at a time Downgraded SecurityPolicyDsc to 2.9.0.0 (as 2.10.0.0 has known CimType issues) Confirmed MSFT_SecurityOption.schema.mof exists in the module directory Ensured no null or invalid values are passed Used explicit paths in Start-DscConfiguration Ran under PowerShell 5.1 on Windows Server 2022 (Azure VM, domain-joined) Despite all this, the error persists — even for a minimal configuration like: Configuration SecurityTest { Import-DscResource -ModuleName 'SecurityPolicyDsc' Node 'localhost' { SecurityOption LimitBlankPasswords { Name = 'LimitBlankPasswords' Accounts_Limit_local_account_use_of_blank_passwords_to_console_logon_only = 'Enabled' } } } SecurityTest -OutputPath "C:\Temp\SecurityTest" Start-DscConfiguration -Path "C:\Temp\SecurityTest" -Wait -Verbose -Force Any guidance or workarounds would be greatly appreciated. If there’s a known fix or update planned for SecurityPolicyDsc, I’d be happy to test that as well. Thanks in advance!
DSC Error for 2022 Security Baseline
Hello Everyone, I am trying to find out more about this error but no luck....... I have converted the GPOs to DSC for Windows Server 2022 - Member Server using Windows Server-2022-Security-Baseline-FINAL and have applied it to a test VM which is currently domain joined, initially I was getting too many dsc errors so I tried to narrow down and do a small batch of configurations and I still get the same error with the following message DSC Error : Could not infer CimType from the provided .NET object. The PowerShell DSC resource '[SecurityOption]SecuritySetting(INF): LSAAnonymousNameLookup' with SourceInfo 'C:\onedsc\PasswordComplexityConfig.ps1::33::9::SecurityOption' threw one or more non-terminating errors while running the Test-TargetResource functionality. These errors are logged to the ETW channel called Microsoft-Windows-DSC/Operational. Refer to this channel for more details. Could not infer CimType from the provided .NET object. Does anyone have any insight what could be wrong here?and how do I go about correcting it ThanksWindows 10/11 22h2 Security Baseline missing in Intune
Hi, can you please enlighten when the Windows 10/11 Security Baseline will be updated to 22H2? The current baseline is of November 2021, I am sure that there are new recommedations in the new baseline ( Windows 10, version 22H2 Security baseline - Microsoft Community Hub ) that would be helpful while managing Windows in a more modern way. As an example, currently missing the 22H2 option "Allow Administrator account lockout" to manage it without the need of a GPO.Question Regarding Server 2022 Domain & Controller MSCT baselines
I have a basic 'Newbie' question regarding the MSCT baselines. I see the GPO for 'MSFT Windows Server 2022 - Domain Controller' and also 'MSFT Windows Server 2022 - Member Server'. I just want to confirm that we should only apply the 'MSFT Windows Server 2022 - Domain Controller' policies to our DC's, and not the Member Server policies as well. While this seems obvious, I just want to make sure.Security Baselines for Linux
Currently only Windows OS is in scope of the Security Baseline assessments. Are there any plans to expand it for Linux (RedHat) as well? I mean our organization has deployed Defender on Linux, so it might be possible Microsoft will support this on Linux OS'es as well. Thanks, Dragi
