Active Directory LDAP Channel Binding Patch Coming in March
Update – It appears that Microsoft will not be changing the defaults with the rollouts in March https://blogs.vmware.com/vsphere/2020/01/microsoft-ldap-vsphere-channel-binding-signing-adv190023.html
Have you heard about the change coming to the way connections will be made by default to Active Directory? Microsoft is has started to sound the alarm on a change coming down the pipes that will be implemented via Windows Updates in March 2020. This will affect the default connectivity and LDAP channel binding for Active Directory and ultimately services that you have connected to your Active Directory infrastructure. Let’s take a look at this Active Directory LDAP Channel Binding Change Coming in March Patch and see what it is exactly and why it is happening.
What is the LDAP Channel Binding Change?
First of all, what change is being made in March 2020? Well, basically if you are not using the secure encrypted TLS connection to Active Directory, you will be affected by the forthcoming changes in March.
Another indicator of being affected – If you are using the plain ldap:// instead of ldaps:// connection, you will be impacted by the change.
Ultimately, the behavior you will see is that you authentication requests coming from systems integrated with or communicating without the required security configuration changes will no longer function.
VMware has noted this will include VMware vSphere using Active Directory as an identity source and configured to make connections using the non-secure 389 LDAP port.
Why is Active Directory LDAP Channel Binding Changing?
The first question you may ask is “why is Microsoft drastically changing the behavior of Active Directory when the LDAP 389 port has worked for years? Well, as with so many required changes the past few years, it is due to security.
There is a known vulnerability that exists in Microsoft Windows when a man-in-the-middle (MITM) attack is carried out to successfully forward an authentication request to a Windows LDAP server such as a domain controller running Active Directory Domain Services role.
Read the official CVE-2017-8563 – https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8563
The update that is forthcoming will address the vulnerability of the MITM attack by adding support for extended protection that will allow the ADDS domain controller to detect and block the forwarded authentication requests that would be taking place as a result of an attacker using the MITM attack documented.
Preparing for the Change
The official response from Microsoft regarding changes they recommend includes:
“We strongly advise administrators to enable LDAP channel binding and LDAP signing between now and March 2020 to find and fix any operating systems, applications or intermediate device compatibility issues in their environment. If any compatibility issue is found, administrators will need to contact the manufacturer of that particular OS, application or device for support.
Important Any OS version, application and intermediate device that performs a man-in-the-middle inspection of LDAP traffic are most likely to be impacted by this hardening change.”
Operating Systems Affected by the Change and Receiving Patch
The following are operating systems that are listed by Microsoft as those that will receive the forthcoming patch that is targeted for March 2020. Interestingly, as you can see also, Microsoft is going to be patching the unsupported Windows 7, Windows Server 2008 SP2 and Windows Server 2008 R2 SP1 platforms.
- Windows Server 2008 SP2
- Windows 7 SP1
- Windows Server 2008 R2 SP1
- Windows Server 2012
- Windows 8.1
- Windows Server 2012 R2
- Windows 10 1507
- Windows Server 2016
- Windows 10 1607
- Windows 10 1703
- Windows 10 1709
- Windows 10 1803
- Windows 10 1809
- Windows Server 2019
- Windows 10 1903
- Windows 10 1909
Active Directory LDAP Channel Binding Patch Coming in March
As you can tell, there is a forthcoming patch that will be appearing in March of this year that will automatically patch your domain controllers for this vulnerability.
As you await the patch, you want to make sure that your clients are updated with the security patches described here: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8563
Also, you can go ahead and enable LDAP channel binding by creating the registry key listed below. Microsoft has provided a few options via the registry key that implement the change in various degrees of rigidity.
- Active Directory Domain Controllers: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
- Active Directory Lightweight Directory Services (AD LDS) servers: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<LDS instance name>\Parameters
- DWORD: LdapEnforceChannelBinding
- DWORD value: 0 indicates disabled. No channel binding validation is performed. This is the behavior of all servers that have not been updated.
- DWORD value: 1 indicates enabled, when supported. All clients that are running on a version of Windows that has been updated to support channel binding tokens (CBT) must provide channel binding information to the server. Clients that are running a version of Windows that has not been updated to support CBT do not have to do so. This is an intermediate option that allows for application compatibility.
- DWORD value: 2 indicates enabled, always. All clients must provide channel binding information. The server rejects authentication requests from clients that do not do so.
Wrapping Up
Understanding the Active Directory LDAP Channel Binding Patch Coming in March and the changes that will be introduced to your environment is key to ensuring there are no major headaches with the overall change in Active Directory communication.
All in all, this change is due to a known security vulnerability. Patching your systems is always a good idea to ensure that you have all the security mechanisms in place that help to protect your environment. The good thing is you have some time before the change is implemented via Window Updates to ensure compatibility between all your systems and the new recommended way to communicate with Active Directory.
