Отключить поддержку шифров 3des windows server 2019

Ноя
15
2018

RC4

To disable RC4 on your Windows server, set the following registry keys:

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 128/128]
        "Enabled"=dword:00000000

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 40/128]
        "Enabled"=dword:00000000

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersRC4 56/128]
        "Enabled"=dword:00000000

3DES

To disable 3DES on your Windows server, set the following registry key:

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168]
        "Enabled"=dword:00000000

If your Windows version is anterior to Windows Vista (i.e. XP, 2003), you will need to set the following registry key:

    [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168]
        "Enabled"=dword:00000000

See also

• Configure an IIS8 server
• Configure an IIS7 server
• Configure an IIS6 server
• Sweet 32: attack targeting Triple DES (3DES)

• Enable/disable encryption algorithm in Windows
• RC4 vulnerability
• IIS Crypto: Tool developed by Nartac that allows you to customize protocol and cipher support on Windows.

I have Windows 10 Pro (by upgrade from Win8.1) and tried customizing on my own cipher suites (especially for IIS) since Nartac IIS Crypto breaks Windows 10…

Part 1: So, I enabled the protocols I want and specifically set (amongst others) the Enabled key of «HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168» to «0». However, after restarting
three times (!!!) I can see that still my computer is negotiating (as a server) and offers «TLS_RSA_WITH_3DES_EDE_CBC_SHA» which I would like to disable… Why isn’t the registry key working? What can I do this to correct it?

Part 2: I also tried rearranging the cipher suite order from gpedit.msc «SSL Configuration», so I erased some cipher suites I didn’t want and rearranged others. After rebooting, my computer presented an «Other User» login screen and rebooted
on its own after about a minute!!! Anyway, I reverted (using the Windows 10 DVD) the registry change of gpedit (it was the key «HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCryptographyConfigurationLocalSSL0010002Functions») to
the default one and rebooted, so it worked. The question here is: Why doesn’t Windows accept erasing some ciphers from its list???

The changes that broke my Windows 10 were those:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA

instead of those default:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_RC4_128_MD5,TLS_RSA_WITH_NULL_SHA256,TLS_RSA_WITH_NULL_SHA,SSL_CK_RC4_128_WITH_MD5,SSL_CK_DES_192_EDE3_CBC_WITH_MD5

Part 3: How can I finally remove «TLS_RSA_WITH_AES_256_CBC_SHA» (and others) from server negotiation without breaking my Windows 10 (like in part 2…) Is there any way to do this?

PS: All 3 parts were successfully resolved on my previous Win8.1 using IIS Crypto, but now it simply doesn’t work!!! Why isn’t Windows 10 obeying registry keys? (like on part 1, when even though I disabled 3DES, it STILL offered it and connected!!!!!)

I have Windows 10 Pro (by upgrade from Win8.1) and tried customizing on my own cipher suites (especially for IIS) since Nartac IIS Crypto breaks Windows 10…

Part 1: So, I enabled the protocols I want and specifically set (amongst others) the Enabled key of «HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersTriple DES 168/168» to «0». However, after restarting
three times (!!!) I can see that still my computer is negotiating (as a server) and offers «TLS_RSA_WITH_3DES_EDE_CBC_SHA» which I would like to disable… Why isn’t the registry key working? What can I do this to correct it?

Part 2: I also tried rearranging the cipher suite order from gpedit.msc «SSL Configuration», so I erased some cipher suites I didn’t want and rearranged others. After rebooting, my computer presented an «Other User» login screen and rebooted
on its own after about a minute!!! Anyway, I reverted (using the Windows 10 DVD) the registry change of gpedit (it was the key «HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCryptographyConfigurationLocalSSL0010002Functions») to
the default one and rebooted, so it worked. The question here is: Why doesn’t Windows accept erasing some ciphers from its list???

The changes that broke my Windows 10 were those:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA

instead of those default:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_RC4_128_MD5,TLS_RSA_WITH_NULL_SHA256,TLS_RSA_WITH_NULL_SHA,SSL_CK_RC4_128_WITH_MD5,SSL_CK_DES_192_EDE3_CBC_WITH_MD5

Part 3: How can I finally remove «TLS_RSA_WITH_AES_256_CBC_SHA» (and others) from server negotiation without breaking my Windows 10 (like in part 2…) Is there any way to do this?

PS: All 3 parts were successfully resolved on my previous Win8.1 using IIS Crypto, but now it simply doesn’t work!!! Why isn’t Windows 10 obeying registry keys? (like on part 1, when even though I disabled 3DES, it STILL offered it and connected!!!!!)

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

Note:
This blogpost assumes all Web Application Proxies, AD FS servers and Azure AD Connect installations run Windows Server 2016.

Why harden

Hardening provides additional layers to defense in depth approaches. It changes the default behavior of products and services to make them more resilient to unauthorized changes and compromise.

Reasons why

Protocols, cipher suites and hashing algorithms are used to encrypt communications in every Hybrid Identity implementation. Typically, ciphers and algorithms to use are based on a negotiation between both ends of a communications channel. The purpose is to use the most secure protocols, cipher suites and hashing algorithms that both ends support. To use the strongest ciphers and algorithms it’s important to disable the ciphers and algorithms you no longer want to see used.

Microsoft recommends organizations to use strong protocols, cipher suites and hashing algorithms. For Azure Active Directory, they are changing the negotiation settings on their systems regularly, to avoid downgrades in encryption standards.

Possible negative impact (What could go wrong?)

When the systems of an Hybrid Identity implementation are improperly hardened, there will be no communication between Azure Active Directory and the systems of the implementation, and/or between the systems of the Hybrid Identity implementation.

This may affect authentications directly when using Active Directory Federation Services (AD FS) or Pass-through Authentication as authentication method in the Hybrid Identity implementation. This may cause diminished functionality, when Password Hash Sync (PHS) is used as the authentication method. Also, this may cause certificates to expire, monitoring to halt and/or backups to fail. It may also mean admins will no longer be able to (remotely) manage the systems.

When using the Remote Desktop Protocol (RDP) to manage the Windows Server installations of the Hybrid Identity implementation, the default security layer in RDP is set to Negotiate which supports both SSL (TLS 1.0) and the RDP Security Layer. Open Remote Desktop Session Host Configuration in Administrative Tools and double-click RDP-Tcp under the Connections group. If it is set to SSL (TLS 1.0) and you are running Windows Server 2008, make sure that you have installed TLS 1.1 and 1.2 support.

For Hybrid Identity implementations featuring Azure AD Connect’s Seamless Single Sign-on (3SO), do not disable RC4_HMAC_MD5 at this time, as this may break.

Getting Ready

To disable weak protocols, cipher suites and hashing algorithms on Web Application Proxies, AD FS Servers and Windows Servers running Azure AD Connect, make sure to meet the following requirements:

System requirements

Make sure all systems in scope are installed with the latest cumulative Windows Updates. Also make sure you run the latest stable version of Azure AD Connect.

Privilege requirements

Make sure to sign in with an account that has privileges to create and/or change and link Group Policy objects to the Organizational Unit (OU) in which the systems in scope reside.

Who to communicate to

When intending to make changes to systems in the Hybrid Identity implementation, make sure to send a heads-up to these people and/or teams in your organization:

• Load balancers and networking guys and gals
• The Active Directory team
• The people responsible for backups, restores and disaster recovery
• The people going through the logs, using a SIEM and/or a TSCM solution
• The monitoring team

One of the challenges you can easily avoid through communications is that multiple persons and/or teams make changes to the configuration. When it breaks, you don’t want to roll-back a bunch of changes, just the one that broke it. Make sure you have the proper freeze/unfreeze moments to achieve that.

Encryption methods are comprised of:

1. A protocol, like PCT, SSL and TLS
2. A key exchange method, like ECDHE, DHE and RSA
3. A cipher suite, like AES, MD5, RC4 and 3DES

Protocols

For the purpose of this blogpost, I’ll stick to disabling the following protocols:

• PCT v1.0
• SSL v2
• SSL v3
• TLS v1.0
• TLS v1.1

Note:
PCT v1.0 is disabled by default on Windows Server Operating Systems.
SSL v2 is disabled, by default, in Windows Server 2016, and later versions of Windows Server.

Cipher suites and hashing algorithms

For the purpose of this blogpost, I’ll stick to disabling the following ciphers suites and hashing algorithms:

• RC2
• RC4
• MD5
• 3DES
• DES
• NULL
• All cipher suites marked as EXPORT

Note:
NULL cipher suites provide no encryption.

Note:
The above list is a snapshot of weak ciphers and algorithms dating July 2019. Please consult the SSL Labs Documentation for actual guidance on weak ciphers and algorithms to disable for your organization.

Protocols, cipher suites and hashing algorithms and the negotiation order to use

For the purpose of this blogpost, I’ll stick with the following protocols, cipher suites and hashing algorithms, in the following negotiation order:

1. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
2. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
3. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
4. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
5. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
6. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
7. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
8. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
9. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
10. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
11. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
12. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
13. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
14. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

This list provides a preference to cipher suites that offer Perfect Forwarding Secrecy (PFS) with the elliptic curve Diffie-Hellman key exchange (ECDHE_*).

How to disable weak protocols

As the systems in scope may or may not be of Active Directory Domain Services, may or may not run Server Core and may or may not allow downloading 3rd party tools, but in all cases you can disable weak protocols using Windows PowerShell with the following scripts:

Note:
As SSL v2 is disabled and removed from Windows Server 2016, and up, and SSL v3 is disabled by default in Windows Server 2016, and up, these protocols do not need to be disabled on Windows Server 2016, and newer versions of Windows Server.

Enable TLS 1.2

To enable TLS 1.2, run the following Windows PowerShell script in an elevated PowerShell window on each of the Windows Server installations in scope of the Hybrid Identity implementation:

Note:
The DisabledByDefault registry value doesn’t mean that the protocol is disabled by default. It means the protocol isn’t advertised as available by default during negotiations, but is available if specifically requested.

$SChannelRegPath = «HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols»

New-Item $SChannelRegPath«TLS 1.2Server» -Force

New-Item $SChannelRegPath«TLS 1.2Client» -Force

New-ItemProperty -Path $SChannelRegPath«TLS 1.2Server» `
-Name Enabled -Value 1 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath«TLS 1.2Server» `
-Name DisabledByDefault -Value 0 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath«TLS 1.2Client» `
-Name Enabled -Value 1 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath«TLS 1.2Client» `
-Name DisabledByDefault -Value 0 -PropertyType DWORD

Configuring .Net applications to use TLS 1.1 and TLS 1.2

Now, we need to configure .Net applications to use either TLS 1.1 or TLS 1.2. This is important for built-in Windows functionality and 3rd party applications and services. Run the following Windows PowerShell script in the same elevated PowerShell window as the previous one:

$RegPath1 = «HKLM:SOFTWAREWOW6432NodeMicrosoft.NETFrameworkv4.0.30319»

New-ItemProperty -path $RegPath1 `
-name SystemDefaultTlsVersions -value 1 -PropertyType DWORD

New-ItemProperty -path $RegPath1 `
-name SchUseStrongCrypto -value 1 -PropertyType DWORD

$RegPath2 = «HKLM:SOFTWAREMicrosoft.NETFrameworkv4.0.30319»

New-ItemProperty -path $RegPath2 `
-name SystemDefaultTlsVersions -value 1 -PropertyType DWORD

New-ItemProperty -path $RegPath2 `
-name SchUseStrongCrypto -value 1 -PropertyType DWORD

Disable TLS 1.0 and TLS 1.1

To disable TLS 1.0 and TLS 1.1, run the following Windows PowerShell script in the same elevated PowerShell window as the previous Windows PowerShell script on each of the Windows Server installations in scope of the Hybrid Identity implementation:

New-Item $SChannelRegPath -Name «TLS 1.0»

New-Item $SChannelRegPath«TLS 1.0» -Name SERVER

New-ItemProperty -Path $SChannelRegPath«TLS 1.0SERVER» `
-Name Enabled -Value 0 -PropertyType DWORD

New-Item $SChannelRegPath«TLS 1.1Server» –force

New-Item $SChannelRegPath«TLS 1.1Client» –force

New-ItemProperty -Path $SChannelRegPath«TLS 1.1Server» `
-Name Enabled -Value 0 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath«TLS 1.1Server» `
-Name DisabledByDefault -Value 0 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath«TLS 1.1Client» `
-Name Enabled -Value 0 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath«TLS 1.1Client» `
-Name DisabledByDefault -Value 0 -PropertyType DWORD

Restart the server after these configuration changes.

How to disable weak ciphers and algorithms

The systems in scope may or may not be of Active Directory Domain Services, may or may not run Server Core and may or may not allow downloading 3rd party tools. In all cases you can disable weak cipher suites and hashing algorithms by disabling individual TLS cipher suites using Windows PowerShell.

Note:
The below lines of PowerShell do not change the negotiation order of the cipher suites and hashing algorithms. It merely disables individual combinations of unwanted cipher suites and hashing algorithms. This also eliminates the need to keep up with the cipher suites in Windows Server between Windows Server version releases and even between updates.
A win-win situation if you’d ask me!

Tip!
To get an overview of the current negotiation order, use the following line of PowerShell:

Get-TlsCipherSuite | Format-Table Name 

Use the following lines on Windows Server 2016 installations to remove weak cipher suites and hashing algorithms:

Disable-TlsCipherSuite -Name «TLS_DHE_RSA_WITH_AES_256_CBC_SHA«
Disable-TlsCipherSuite -Name «TLS_DHE_RSA_WITH_AES_128_CBC_SHA«
Disable-TlsCipherSuite -Name «TLS_RSA_WITH_AES_256_GCM_SHA384«
Disable-TlsCipherSuite -Name «TLS_RSA_WITH_AES_128_GCM_SHA256«
Disable-TlsCipherSuite -Name «TLS_RSA_WITH_AES_256_CBC_SHA256«
Disable-TlsCipherSuite -Name «TLS_RSA_WITH_AES_128_CBC_SHA256«
Disable-TlsCipherSuite -Name «TLS_RSA_WITH_AES_256_CBC_SHA«
Disable-TlsCipherSuite -Name «TLS_RSA_WITH_AES_128_CBC_SHA«
Disable-TlsCipherSuite -Name «TLS_RSA_WITH_3DES_EDE_CBC_SHA«
Disable-TlsCipherSuite -Name «TLS_DHE_DSS_WITH_AES_256_CBC_SHA256«
Disable-TlsCipherSuite -Name «TLS_DHE_DSS_WITH_AES_128_CBC_SHA256«
Disable-TlsCipherSuite -Name «TLS_DHE_DSS_WITH_AES_256_CBC_SHA«
Disable-TlsCipherSuite -Name «TLS_DHE_DSS_WITH_AES_128_CBC_SHA«
Disable-TlsCipherSuite -Name «TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA«
Disable-TlsCipherSuite -Name «TLS_RSA_WITH_RC4_128_SHA«
Disable-TlsCipherSuite -Name «TLS_RSA_WITH_RC4_128_MD5«
Disable-TlsCipherSuite -Name «TLS_RSA_WITH_NULL_SHA256«
Disable-TlsCipherSuite -Name «TLS_RSA_WITH_NULL_SHA«
Disable-TlsCipherSuite -Name «TLS_PSK_WITH_AES_256_GCM_SHA384«
Disable-TlsCipherSuite -Name «TLS_PSK_WITH_AES_128_GCM_SHA256«
Disable-TlsCipherSuite -Name «TLS_PSK_WITH_AES_256_CBC_SHA384«
Disable-TlsCipherSuite -Name «TLS_PSK_WITH_AES_128_CBC_SHA256«
Disable-TlsCipherSuite -Name «TLS_PSK_WITH_NULL_SHA384«
Disable-TlsCipherSuite -Name «TLS_PSK_WITH_NULL_SHA256«

Testing proper hardening

After hardening it’s time to test the hardening. Everyone should sign off (not literally, unless that’s procedure) on the correct working of the Windows Servers running Azure AD Connect. Does authentication to cloud applications still work? Does rolling over the certificate still work? Does monitoring still work? Can we still make back-ups? Can we still restore the backups we make?

Typically, hardening is rolled out to one Windows Server. When testing the hardening of the functionality behind the load balancer, make sure that the load balancer points you to the hardened system, not another one. In an environment with a Staging Mode Azure AD Connect installation, the hardening can be performed on this Windows Server installation and tested with the normal Staging Mode (imports only) synchronization cycles. When hardening is approved upon, the actively synchronizing Azure AD Connect installation can be switched, or hardened, too.

Note:
The registry changes are step 2 of two steps to harden protocols, cipher suites and hashing algorithms of the Hybrid Identity implementation. Make sure to Enforce Azure AD Connect to use TLS 1.2 only on the Windows Servers running Azure AD Connect, before testing.

Rolling Back Hardening

To roll back hardening, use the following lines of Windows PowerShell:

$SChannelRegPath = «HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols»

Remove-Item –Name «TLS 1.0» –Path $SChannelRegPath
Remove-Item –Name «TLS 1.1» –Path $SChannelRegPath
Remove-Item –Name «TLS 1.2» –Path $SChannelRegPath

Enable-TlsCipherSuite -Name «TLS_DHE_RSA_WITH_AES_256_CBC_SHA«
Enable-TlsCipherSuite -Name «TLS_DHE_RSA_WITH_AES_128_CBC_SHA«
Enable-TlsCipherSuite -Name «TLS_RSA_WITH_AES_256_GCM_SHA384«
Enable-TlsCipherSuite -Name «TLS_RSA_WITH_AES_128_GCM_SHA256«
Enable-TlsCipherSuite -Name «TLS_RSA_WITH_AES_256_CBC_SHA256«
Enable-TlsCipherSuite -Name «TLS_RSA_WITH_AES_128_CBC_SHA256«
Enable-TlsCipherSuite -Name «TLS_RSA_WITH_AES_256_CBC_SHA«
Enable-TlsCipherSuite -Name «TLS_RSA_WITH_AES_128_CBC_SHA«
Enable-TlsCipherSuite -Name «TLS_RSA_WITH_3DES_EDE_CBC_SHA«
Enable-TlsCipherSuite -Name «TLS_DHE_DSS_WITH_AES_256_CBC_SHA256«
Enable-TlsCipherSuite -Name «TLS_DHE_DSS_WITH_AES_128_CBC_SHA256«
Enable-TlsCipherSuite -Name «TLS_DHE_DSS_WITH_AES_256_CBC_SHA«
Enable-TlsCipherSuite -Name «TLS_DHE_DSS_WITH_AES_128_CBC_SHA«
Enable-TlsCipherSuite -Name «TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA«
Enable-TlsCipherSuite -Name «TLS_RSA_WITH_RC4_128_SHA«
Enable-TlsCipherSuite -Name «TLS_RSA_WITH_RC4_128_MD5«
Enable-TlsCipherSuite -Name «TLS_RSA_WITH_NULL_SHA256«
Enable-TlsCipherSuite -Name «TLS_RSA_WITH_NULL_SHA«
Enable-TlsCipherSuite -Name «TLS_PSK_WITH_AES_256_GCM_SHA384«
Enable-TlsCipherSuite -Name «TLS_PSK_WITH_AES_128_GCM_SHA256«
Enable-TlsCipherSuite -Name «TLS_PSK_WITH_AES_256_CBC_SHA384«
Enable-TlsCipherSuite -Name «TLS_PSK_WITH_AES_128_CBC_SHA256«
Enable-TlsCipherSuite -Name «TLS_PSK_WITH_NULL_SHA384«
Enable-TlsCipherSuite -Name «TLS_PSK_WITH_NULL_SHA256«

Concluding

Get rid of old protocols, cipher suites and hashing algorithms in your Hybrid Identity implementation, so they cannot be used to negotiate the security of the connections down.

Further reading

Managing SSL/TLS Protocols and Cipher Suites for AD FS
245030 How to restrict cryptographic algorithms and protocols in Schannel.dll
187498 How to disable PCT 1.0, SSL 2.0, SSL 3.0, or TLS 1.0 in IIS
Recommendations for TLS/SSL Cipher Hardening
How to Update Your Windows Server Cipher Suite for Better Security
A Cipher Best Practice: Configure IIS for SSL/TLS Protocol