Forum Widgets
Latest Discussions
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.
Microsoft 365 Apps for Enterprise Security Baseline 2412; when available?
https://learn.microsoft.com/en-us/intune/intune-service/protect/security-baseline-v2-office-settings?pivots=v2306 is currently available in Intune. Microsoft already released the 2412 version via the Microsoft Security Compliance Toolkit. Unfortunately, this version is not available in Intune nyet. When can we expect that version to become available in Intune?
TLS 1.1 is set as a recommended value in the latest security baseline
In the latest security baseline for Windows 11 24H2, the following item is set to "Use TLS 1.1 and TLS 1.2," but could you please explain the reason for this? Download Microsoft Security Compliance Toolkit 1.0 from Official Microsoft Download Center Windows Components\Internet Explorer\Internet Control Panel\Advanced Page Turn off encryption support Enabled: Use TLS 1.1 and TLS 1.2 Generally, I believe TLS 1.1 should no longer be used, and that using "TLS 1.2 and TLS 1.3" would be better from a security standpoint.
Microsoft Zero Trust Assessment v2: Operationalizing Security with Precision
In an era where cyber threats evolve faster than ever, organizations can’t afford blind spots. Zero Trust is no longer optional it’s the foundation of modern security. With the release of the Microsoft Zero Trust Assessment v2, enterprises now have a powerful tool to measure, prioritize, and remediate security gaps with actionable intelligence. What Is Zero Trust Assessment v2? The Zero Trust Assessment is a security posture evaluation tool designed to help organizations operationalize Zero Trust principles. It automates checks across hundreds of configuration items aligned with: Secure Future Initiative (SFI) Zero Trust pillars: Identity, Devices, Applications, Data, Infrastructure and Networks Industry standards: NIST, CISA, CIS Microsoft’s internal security baselines Insights from thousands of real-world customer implementations How Does It Work? The assessment follows a structured, automated workflow: 1. Data Collection & Configuration Analysis Scans your Microsoft 365 environment and connected workloads. Evaluates identity configurations (e.g., MFA enforcement, conditional access policies). Reviews device compliance (e.g., Intune policies, OS hardening). Pulls telemetry from Azure AD, Microsoft Defender, and other integrated services. 2. Automated Testing Against Standards Runs hundreds of tests mapped to Zero Trust principles. Benchmarks your settings against: NIST Cybersecurity Framework CISA Zero Trust Maturity Model Microsoft security baselines Flags misconfigurations and policy gaps. 3. Risk Scoring & Prioritization Assigns risk levels based on: Impact (how critical the gap is) Effort (complexity of remediation) Provides a prioritized list of actions so you can focus on what matters most. 4. Actionable Recommendations Generates clear remediation steps not vague advice. Links to Microsoft Learn and security documentation for quick implementation. Suggests policy templates and automation scripts where applicable. 5. Comprehensive Reporting Delivers a detailed report with: Trends over time Risk heatmaps Compliance scores Enables executive dashboards for leadership visibility. Integration with Microsoft Security Tools Zero Trust Assessment v2 doesn’t operate in isolation it integrates seamlessly with Microsoft’s security ecosystem: Microsoft Defender for Endpoint Detects device vulnerabilities and feeds compliance data into the assessment. Microsoft Intune Ensures device configuration policies align with Zero Trust principles. Microsoft Sentinel Correlates assessment findings with threat intelligence for proactive incident response. Azure AD Conditional Access Validates identity policies like MFA and session controls. Microsoft Purview Extends Zero Trust to data governance and compliance. This integration ensures that remediation steps can be automated and enforced across your environment, reducing manual effort and accelerating security posture improvement. Sample Remediation Workflow Diagram Below is a simplified view of how remediation flows after an assessment: This closed-loop process ensures continuous improvement and operationalization of Zero Trust. Key Benefits Speed: Automates what used to take weeks of manual audits. Accuracy: Aligns with global standards and Microsoft’s own security posture. Operationalization: Moves Zero Trust from theory to practice with actionable steps. Future-Ready: Tests will soon be available enabling continuous improvement. Why This Matters Blind spots in identity or device security can lead to breaches, financial loss and reputational damage. Zero Trust Assessment v2 helps you: Respond faster to evolving threats. Reduce risk with prioritized remediation. Build resilience by embedding Zero Trust principles into daily operations.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/Microsoft Policy Analyzer 4.0 crashes after apply April updates
Good morning community !! After apply security/.NET patches corresponding to April, the policy analyzer is not working anymore... On details See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** Deleted because system do not permit to publish it ************** Loaded Assemblies ************** mscorlib Assembly Version: 4.0.0.0 Win32 Version: 4.8.9032.0 built by: NET481REL1 CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll ---------------------------------------- PolicyAnalyzer Assembly Version: 4.0.2004.13001 Win32 Version: 4.0.2004.13001 CodeBase: file:///C:/Personal/PolicyAnalyzer/PolicyAnalyzer/PolicyAnalyzer_40/PolicyAnalyzer.exe ---------------------------------------- System.Windows.Forms Assembly Version: 4.0.0.0 Win32 Version: 4.8.9032.0 built by: NET481REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System Assembly Version: 4.0.0.0 Win32 Version: 4.8.9032.0 built by: NET481REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Drawing Assembly Version: 4.0.0.0 Win32 Version: 4.8.9032.0 built by: NET481REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.Configuration Assembly Version: 4.0.0.0 Win32 Version: 4.8.9032.0 built by: NET481REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System.Xml Assembly Version: 4.0.0.0 Win32 Version: 4.8.9032.0 built by: NET481REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- Accessibility Assembly Version: 4.0.0.0 Win32 Version: 4.8.9032.0 built by: NET481REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll ---------------------------------------- System.Core Assembly Version: 4.0.0.0 Win32 Version: 4.8.9032.0 built by: NET481REL1 CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box. It was working fine since patching apply. I tried to uninstall patches, but the error still remains Any clue to fix this? Thank you !!
[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!
