security
466 TopicsWindows Server 2025 update with error 0x80073712
Hello Can I have some help? Windows Server 2025 Std, V 24H2, OS build: 26100.32522 The 2026-04 Security Update (KB5082063) (26100.32690) fails with the following error: Installation failed: Windows failed to install the following update with error 0x80073712: 2026-04 Security Update (KB5082063) (26100.32690). Thanks in advance MadUrantia176Views0likes2CommentsASP Classic stop working after Windows Server 2012 for x64-based System KB5073698
I hope this will be useful to others. We have a legacy application implemented using classic ancient ASP after the most recent windows server rollup update the ASP pages stop working, without any error message, the worker thread just crashed. It turned out that the network stack was hardened and the old ASP engine did not expect a failure on network operations. I did a short write up here with the solution https://www.linkedin.com/pulse/classic-asp-bug-took-four-days-solve-ridiculous-root-cause-pedruzzi-adw9e2026-04 Update Breaks Domain Logins
I have an Active Directory domain that is old (from 2000!) that has been upgraded and moved to newer versions of Windows Server and Active Directory. I have domain controller VMs running Windows Server 2025 Standard Edition. Unfortunately they installed the latest 2026-04 patches which my have changed the Kerberos encryption from RC4 to AES. This has resulted in my not being able to log into any Active Directory domain accounts and the domain controllers themselves. I can only log into workstations using the local account. Suffice to say this a nightmare. Any ideas how to fix it since I can't access the usual tools like Active Directory Users and Computers, Hyper-V won't connect to the VMs, etc. Thanks. SSolved4.1KViews2likes8CommentsPhase 2 of Kerberos RC4 hardening begins with the April 2026 Windows security update
Windows updates released in April 2026 and later begin the second deployment phase of protections designed to address a Kerberos information disclosure vulnerability (CVE‑2026‑20833). This second phase continues the shift away from legacy encryption types such as RC4 by moving toward stronger default ticket behavior. After installing the April 2026 update, domain controllers default to supporting Advanced Encryption Standard (AES‑SHA1) encrypted tickets for accounts that do not have an explicit Kerberos encryption type configuration. If your organization relies on service accounts or applications that depend on RC4-based Kerberos service tickets, now is the time to address those dependencies to avoid authentication issues before the Enforcement phase begins in July 2026. Microsoft recommends continuing to monitor the System event log for Kerberos-related audit events and identify and address misconfigurations or remaining dependencies, then enabling enforcement when warning, blocking, or policy events are no longer logged. See How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 and CVE‑2026‑20833 to learn more about the vulnerability, timelines, recommended preparation steps, and configuration options to ensure compliance before Enforcement mode begins in July 2026.5.9KViews1like1Commentntoskrnl.exe and build version not getting updated after applying KB5078740 on server 2025
I have installed the latest March patch kb5078740 on server 2025 which was upgraded from server 2022. the patch is showing installed but the ntoskrnl.exe and build version is still showing 10.0.26100.4652. Qualys is detecting it as patch not installed based on file version which should be 10.0.21600.32522. Please let me know how to fix this issue.462Views0likes0CommentsExperiences Creating a CA with ML‑DSA Using Microsoft Smart Card Key Storage Provider (ADCS / PQC)
Hi all, I’m exploring the possibility of using post‑quantum cryptography within an Active Directory Certificate Services (ADCS) environment in the Insider release 29550. Specifically, I’m interested in creating a Certificate Authority (CA) where the CA’s key material is generated and stored using a Microsoft Smart Card Key Storage Provider (KSP) with support for ML‑DSA. This is an option selectable in the "Specify the cryptographic options". Has anyone in the community successfully done the following: Created a CA using ML‑DSA: Micosoft Smart Card KSP as the cryptographic provider? If so, what smart card or hardware token did you use that supports ML‑DSA via the Microsoft Smart Card KSP? (e.g., specific vendor and/or model that exposes ML‑DSA support correctly to Windows) Is it actually possible to create a CA using ML‑DSA as the cryptographic provider? If yes, what are the key steps or gotchas? What changes when ML‑DSA is used as the CA key provider compared to traditional providers like RSA/ECC? Any differences in certificate creation, enrollment, templates, compatibility with clients, etc.? Is there any official documentation for using ML‑DSA or PQC with ADCS? Are there other post‑quantum cryptographic (PQC) options already supported or coming soon in ADCS?294Views0likes0CommentsBeyond RC4 for Windows authentication - Question regarding KB5073381
In KB5021131 MS recommends setting the value for DefaultDomainSupportedEncTypes to 0x38, in the new KB 5073381 it's 0x18. This removes the setting that forces "AES Session Keys" which should be fine if Kerberos Tickets can only use AES Encryption. But what about accounts that have RC4 enabled in their msds-supportedEncryptionTypes attribute? They could still use RC4 for Kerberos ticket encryption and would then also fallback to RC4 session ticket encryption. As far as I believe the DefaultDomainSupportedEncTypes was explicitly introduced to avoid this scenario. Or is there now some hard-coded mechanism that always ensures that Session Keys are AES encrypted?1.5KViews1like2CommentsBookmark the Secure Boot playbook for Windows Server
Secure Boot is a long‑standing security capability that works in conjunction with the Unified Extensible Firmware Interface (UEFI) to confirm that firmware and boot components are trusted before they are allowed to run. Microsoft is updating the Secure Boot certificates originally issued in 2011 to ensure Windows devices continue to verify trusted boot software. These older certificates begin expiring in June 2026. While Windows Server 2025 certified server platforms already include the 2023 certificates in firmware. For servers that do not, you will need to manually update the certificates. Unlike Windows PCs, which may receive the 2023 Secure Boot certificates through Controlled Feature Rollout (CFR) as part of the monthly update process, Windows Server requires manual action. Luckily, there is a step=by-step guide to help! With the Secure Boot Playbook for Windows Server, you'll find information on the tools and options available to help you update Secure Boot certificates on Windows Server. Check it out today!142Views0likes0Comments