What is going on with RC4 in Kerberos?
Howdy everyone! The cat is out of the bag when it comes to Microsoft’s forward outlook on RC4 usage in Kerberos. In the past few months, we have published the following. Beyond RC4 for Windows authentication Detect and remediate RC4 usage in Kerberos How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 As you can see, the writing is on the wall for RC4. However, we also understand that many folks still have dependencies on RC4 for one reason or another. My goal with this blog post is to help clarify things for those folks. I know that not everyone is interested in the nitty gritty of how everything works and just want quick answers, so I am going to start with those. Frequently Asked Questions (FAQ) If this FAQ does not answer your questions about RC4 dependencies in your environment, please feel free to reach out to stillneedrc4@microsoft.com with your question and information on how you are still leveraging RC4. Is RC4 being removed from Windows? As of January 2026, there are currently no plans to remove RC4 from Windows. However, DES has been removed from Windows Server 2025 and Windows 11 24H2 and newer versions. For additional information please see Removal of DES in Kerberos for Windows Server and Client | Microsoft Community Hub I have a machine running a mission critical service that only supports RC4. What do I do? If you have defined the DefaultDomainSupportedEncTypes registry key on all relevant Windows Key Distribution Centers (KDCs), then you should not expect any breaking changes. Alternatively, if you have defined the msds-SupportedEncryptionTypes attribute for the service account and the bitmask includes RC4 then no action needs to be taken. I have a Windows Server 2003 deployment that we are working to migrate away from, but I need them to work in the meantime. What do I do? As I'm sure you already know Windows Server 2003 left end of life in 2015 . The highest priority should be migrating to a version of Windows that is currently receiving security updates. Thus, this machine is treated the same as any other machine that needs RC4 as Windows Server 2003 does not support AES-SHA1. I am seeing RC4 usage in my environment through Event Id 4768 and Event Id 4769 in the Security Event Logs on my KDC. Will I be broken by these changes? The existence of Event Id 4768 and Event Id 4769 in the Security Event Log is not necessarily an indication that things will break in isolation. While in the initial deployment phase of the 2026 January Cumulative updates (often referred to as audit mode), I recommend looking in the Windows System Event Log for the newly added Event Id 201, 202, 206, and 207. We specifically created these new events to identify interactions that are at risk as part of the RC4 default disablement plan. If you see any of those new events generated in the Windows System Event Log, then you are at risk for breaking changes upon moving to enforcement mode. I have an old service account that doesn't have AES-SHA1 keys. Will I be broken? Maybe. At-risk service accounts will be referenced in Windows System Event Log with Event Id 202, or Event Id 207. As for remediation, there are a few options available to this specific problem. The best recommendation would be to reset the account password on a modern Windows KDC. During a password change, new keys are generated automatically with all the available Kerberos Encryption Types. If that is not possible, then either defining the DefaultDomainSupportedEncTypes or configuring the msds-SupportedEncryptionTypes on the target service account to include RC4 would be your best bet. How does DefaultDomainSupportedEncTypes work? When making a service ticket request, the KDC will search for the target service accounts msds-SupportedEncryptionTypes Active Directory (AD) attribute on the target service account. If that attribute is either 0 or undefined, then the assumed encryption type value will be applied. The assumed encryption type is what the KDC assumes that all accounts running supported Windows versions in an AD domain support. The DefaultDomainSupportedEncTypes registry key controls what the KDC will apply as the assumed encryption types. By default, the assumed encryption types are 0x27 (DES, RC4 and AES-SHA1 session keys). On Windows Server 2025, this default value is 0x24 (RC4, and AES-SHA1 session keys) because DES has been removed from Windows Server 2025. If you would like to define the assumed encryption types, you MUST ensure that all accounts within the domain support the configured value. While reviewing this configuration, it's worth investigating if DES is necessary in your environment. For additional information, please see: DES Detection · microsoft/Kerberos-Crypto Wiki. The configuration of the supported Kerberos encryption types through the DefaultDomainSupportedEncTypes registry keys is almost identical to the msds-SupportedEncryptionTypes bitmask. For example: 0x18 in msds-SupportedEncryptionTypes means AES128-CTS-HMAC-SHA1-96 and AES256-CTS-HMAC-SHA1-96 0x18 in DefaultDomainSupportedEncTypes means AES128-CTS-HMAC-SHA1-96 and AES256-CTS-HMAC-SHA1-96 CAVEAT: The bitmask of 0x20 is ONLY honored when applied to DefaultDomainSupportedEncTypes. More additional details on the Supported Encryption Type bitmask please see [MS-KILE]: Supported Encryption Types Bit Flags | Microsoft Learn What is happening with the January 2026 Cumulative Updates? With the January 2026 Cumulative Updates, we are beginning to change the default behavior of the assumed encryption types on a KDC. We will be removing RC4 as one of the assumed encryption types. We have added new auditing to help detect RC4 usage that is currently permitted through unconfigured assumed encryption types. On installing the April 2026 Windows Cumulative Updates on supported DCs, we will be moving to an enforcement phase where usage of RC4 through the assumed encryption types will now be blocked. Enforcement mode can be rolled back to audit mode. On installing the July 2026 Windows Cumulative Updates, the behavior will be identical to April 2026, however you will no longer roll back to audit mode. For additional reading I recommend reading the How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 - Microsoft Support in its entirety. Closing things out Security hardening is never easy, and we empathize with the IT professionals who are working to harden their environment. Migration and upgrades are not always an easy process, and we at Microsoft want to help make this process as smooth as possible. As mentioned in other blog posts, we have a few Kerberos RC4 identification scripts that are available on GitHub at Microsoft/Kerberos-Crypto. And to help us understand your RC4 dependencies please feel free to drop us a mail at stillneedrc4@microsoft.com.What's the deal with Kerb3961?
Howdy, everyone! I wanted to write this blog post to discuss the new Kerb3961 library introduced in Windows Server 2025 / Windows 11 24H2. It is (hopefully) making encryption type (etype) usage within Kerberos much easier to anticipate and understand. Let's start with... What is Kerb3961? Kerb3961, named after RFC3961, is a refactor of the Kerberos cryptography engine in its own library. This library is now the authoritative source of: Etype selection Etype usage Etype management For the average IT administrator, the part that is going to be most interesting is #1. The Kerb3961 policy engine is what will authoritatively determine what etypes are available given different Kerberos key usage scenarios. Whereas in previous Windows releases, there were instances of hard coded etype usage due to technical limitations at the time of implementation. Kerb3961 still leverages existing Kerberos etype configuration group policy: Network security Configure encryption types allowed for Kerberos - Windows 10 | Microsoft Learn. However, it no longer honors the legacy registry key path of: HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Lsa\Kerberos\Parameters REG_DWORD SupportedEncryptionTypes As a reminder, the group policy mentioned above is used to configure the supported encryption types for a machine account. The machine then propagates this information into Active Directory (AD) where it is stored in the msds-SupportedEncryptionType attribute for the account. It has no effect on non-etype related Kerberos settings such as those outlined in Registry entries about Kerberos protocol and Key Distribution Center (KDC) with the exception of the DefaultDomainSupportedEncTypes registry key. The biggest change is the reduction of hard-coded etype usage. We have heard the frustrations of customers who are trying to eliminate RC4 usage, and the seemingly unexplainable instances of RC4 usage with their environments. This new library removes these hard-coded dependencies and aggregates all those decisions into one place. With the goal of: More secure Kerberos operations by default More predictable Kerberos etype usage More stable etype additions More stable etype removals For example, if we had not done this refactor, the DES deprecation and on-going work towards RC4 deprecation would not be possible. Why did this need to happen? Kerberos was added to Windows in the early 2000's as a part of beginning the move away from NTLM and into modern cipher usage. Over these decades, there have been incredible strides in security hardening that the original developers could not have foreseen. As a result, some of the design decisions made during that initial implementation impacted our ability to reliably change the way Kerberos operates. This can be seen in things like: Kerberos changes for CVE-2022-37966 Kerberos changes for CVE-2022-37967 Additionally, with the long tail of code in this area and the etype that has been historically used, it had become a near impossibility to add or remove a cipher due to how the etypes were directly associated in Kerberos. What does this mean going forward? The Kerb3961 library has key implications going forward. The biggest one is the removal of hard-coded cipher usage and a stronger adherence to the administrators’ configured encryption types. The environment will operate as configured. Meaning IT administrators can have a high degree of confidence that their configurations will be honored. This increases the amount of knowledge required by administrators. Misconfigurations, previously hidden by loose adherence to the configured etypes, will now be exposed. For more information about Kerberos etype selection, refer to the Kerberos EType Calculator. What needs to be done? To configure an environment requires understanding what etypes are used within an environment. To help aid in this endeavor, we have improved Key Distribution Center (KDC) auditing. 4768(S, F) A Kerberos authentication ticket (TGT) was requested. - Windows 10 | Microsoft Learn 4769(S, F) A Kerberos service ticket was requested. - Windows 10 | Microsoft Learn We have also published two PowerShell helper scripts that leverage these new events. The goal of these scripts is to allow for easier identification of both etype usage and account key availability. These scripts are published on the Microsoft Kerberos-Crypto GitHub repository, where, going forward, we will be using scripts and information published there to better interface with the community. We acknowledge that substantial changes can introduce regressions and friction points for those with mature environments. It is our goal to allow for a smooth adoption of these new features and prevent any unnecessary pain for our already overworked and under-appreciated system administrators. Please be sure to leverage Feedback Hub to share your experiences with us. If you would like to see any of these features early, we highly recommend leveraging the Windows Insider Program and opting into Continuous Innovation and sharing feedback directly with the development team. We understand that this can be challenging, and Microsoft is committed to ensuring that the knowledge needed to make an informed decision about what is right for your environment.
Collecting Debug Information from Containerized Applications
Howdy everyone! It's your favorite Debug Engineer, Will Aftring back again, this time talking about containers. This blog post will assume that you have a fundamental understanding of Windows containers. If that isn't the case, then then I highly recommend reading Get started: Run your first Windows container. Many developers and IT Admins are in the midst of migrating long standing applications into containers to take advantage of the myriad of benefits made available with containerization. NOTE: Not all applications are able to equally take advantage of the benefits of containerization. It is another tool for the toolbox to be used at your discretion. But moving an existing application into a container can be a bit tricky. With this blog post I hope to help make that process a little bit easier for you.Understanding Lock Contention in Windows Performance Analyzer (WPA)
Hi everyone, this is Will Aftring with the Windows Debug team. I was debugging an application performance issue and thought “this is a great example of lock contention”. For this post we will be using the Windows Performance Analyzer (WPA) to review data collected with the Windows Performance Recorder (WPR). For the sake of keeping this post focused I won’t go in depth on WPR but there are plenty of resources on how to get started. Getting Started Windows Performance Recorder | Microsoft Docs
