Schannel Follow-up

Hello all! Nathan Penn back again with a follow-up to Demystifying Schannel. While finishing up the original post, I realized that having a simpler method to disable the various components of Schannel might be warranted. If you remember that article, I detailed that defining a custom cipher suite list that the system can use can be accomplished and centrally managed easily enough through a group policy administrative template. However, there is no such administrative template for you to use to disable specific Schannel components in a similar manner. The result being, if you wanted to disable RC4 on multiple systems in an enterprise you needed to manually configure the registry key on each system, push a registry key update via some mechanism, or run a third party application and manage it. Well, to that end, I felt a solution that would allow for centralized management was a necessity, and since none existed, I created a custom group policy administrative template. The administrative template leverages the same registry components we brought up in the original post, now just providing an intuitive GUI.

For starters, the ever-important logging capability that I showcased previously, has been built-in. So, before anything gets disabled, we can enable the diagnostic logging to review and verify that we are not disabling something that is in use. While many may be eager to start disabling components, I cannot stress the importance of reviewing the diagnostic logging to confirm what workstations, application servers, and domain controllers are using as a first step.

Once we have completed that ever important review of our logs and confirmed that components are no longer in use, or required, we can start disabling. Within each setting is the ability to Enable the policy and then selectively disable any, or all, of the underlying Schannel components. Remember, Schannel protocols, ciphers, hashing algorithms, or key exchanges are enabled and controlled solely through the configured cipher suites by default, so everything is on. It is important to know the original state if you ever need/want to back out the settings. To disable a component, enable the policy and then checkbox the desired component that is to be disabled. Note, that to ensure that there is always an Schannel protocol, cipher, hashing algorithm, and key exchange available to build the full cipher suite, the strongest and most current components of each category was intentionally not added.

Finally, when it comes to practical application and moving forward with these initiatives, start small. I find that workstations is the easiest place to start. Create a new group policy that you can security target to just a few workstations. Enable the logging and then review. If, for example you only want workstations using some form of TLS and you see the workstations still using SSL for things like RDP in the log, update their RDP configuration to use TLS 1.2. Then re-verify that the logs show they are only using TLS. At this point, you are ready to test disabling the other Schannel protocols. Once disabled, test to ensure the client can communicate out as before, and any client management capability that you have is still operational. If that is the case, then you may want to add a few more workstations to the group policy security target. And only once I am satisfied that everything is working would I schedule to roll out to systems in mass. After workstations, I find that Domain Controllers are the next easy stop. With Domain Controllers, I always want them configured the identically, so feel free to leverage a pre-existing policy that is linked to the Domain Controllers OU and affects them all or create a new one. The important part here is that I review the diagnostic logging on all the Domain Controllers before proceeding. Lastly, I target application servers grouped by the application, or service they provide. Working through each grouping just as I did with the workstations. Creating a new group policy, targeting a few systems, reviewing those systems, re-configuring applications as necessary, re-verifying, and then making changes.

Now, in the event that something was missed and you need to back out changes you have 2 options:

  1. Leave the policy enabled, and remove the checkbox from the components
  2. Disable the policy setting

Both of these options will re-enable the components the next time group policy processes on the system. (NOTE: Setting the “Not Configured” option will leave the component in the last configured state. I.e. if RC4 was disabled, it will remain disabled).

To leverage the custom administrative template we need to add them to our Policy Definition store. Once added, the configuration options become available under:

Computer Configuration -> Administrative Templates – > System -> Schannel

Each option includes a detailed description of what can be controlled as well as URLs to additional information.

You can download the custom Schannel ADM files by clicking here!

Additional Resources:

Demystifying Schannel:

Supported cipher suites by Windows operating systems:

Types of events that Schannel can produce:

Schannel SSP registry entries:



The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.