LDAP Channel Binding and LDAP Signing Requirements – JANUARY 2020 Updates

Hi All, Alan here again, this time trying to give some details on these two settings that will become active from January 2020 and they are creating some misunderstandings. 

Let's start saying that since Windows Server 2008 we have events 2886,2887,2888 and 2889 logged every 24 hours on the Directory Services log that tells us we are using these unsecure protocols 

Logging is our friend: 

2886 Telling us that our DCs are not requiring LDAP signing 

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd…

2887 Telling us how many such binds occurred 

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd…

During the previous 24 hour period, some clients attempted to perform LDAP binds that were either: (1) A SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP bind that did not request signing (integrity validation), or (2) A LDAP simple bind that was performed on a cleartext (non-SSL/TLS-) connection This directory server is not currently configured to reject such binds. The security of this directory server can be significantly enhanced by configuring the server to reject such binds. For more details and information on make this configuration change to the server, please see http://go.microsoft.com/fwlink/?LinkID=87923. Summary information on the number of these binds received within the past 24 hours is below. You can enable additional logging to log an event each time a client makes such a bind, including information on which client made the bind. To do so, please raise the setting for the “LDAP Interface Events” event logging category to level 2 or higher. Number of simple binds performed without SSL/TLS: “Value” Number of Negotiate/Kerberos/NTLM/Digest binds performed without signing: “Value” 

The suggested path to resolve this error is do modify the registry of the DC to allow it log those failures. 

Registry to add: 

Reg Add HKLMSYSTEMCurrentControlSetServicesNTDSDiagnostics /v “16 LDAP Interface Events” /t REG_DWORD /d 2 

………………….. 

Once the registry key “16 LDAP Interface Events” is configured we will have event 2889 telling us who is using this type of unsecure protocol 

2889 will tell us the IP Address of the client connecting with this type of protocols 

2888 If the directory server is configured to reject unsigned SASL LDAP binds or LDAP simple binds over a non-SSL/TLS connection, the directory server will log a summary event 2888 one time every 24 hours when such bind attempts occur. 

Once we know who is using these types of Unsecure Protocols we should consider disabling them before they will be enforced by January 2020 updates. This should be done on Clients, Servers and DCs side. 

LDAP channel binding and LDAP signing provide ways to increase the security for communications between LDAP clients and Active Directory domain controllers. A set of unsafe default configurations for LDAP channel binding and LDAP signing exist on Active Directory Domain Controllers that let LDAP clients communicate with them without enforcing LDAP channel binding and LDAP signing. This can open Active directory domain controllers to elevation of privilege vulnerabilities.

This advisory addresses the issue by recommending a new set of safe default configurations for LDAP channel binding and LDAP signing on Active Directory Domain Controllers that supersedes the original unsafe configuration. 

https://support.microsoft.com/en-us/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-e…

value: 0 indicates disabled. No channel binding validation is performed. This is the behavior of all servers that have not been updated.

value:1 indicates enabled, when supported [……] This is an intermediate option that allows for application compatibility.

value: indicates enabled, always (All clients must provide channel binding information. The server rejects requests from clients that do not do so)

Also ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signinghttps://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023 

Very important. You need to have this CVE-2017-8563 installed on your clients as a prerequisite before enabling LDAP Channel Binding and LDAP Integrity on DCs 

CVE-2017-8563 | Windows Elevation of Privilege Vulnerability (REQUIRED) 

An elevation of privilege vulnerability exists in Microsoft Windows when a man-in-the-middle attacker is able to successfully forward an request to a Windows LDAP server, such as a system running Active Directory Domain Services () or Active Directory Lightweight Directory Services (AD LDS), which has been configured to require signing or sealing on incoming connections. 

The update addresses this vulnerability by incorporating support for Extended Protection for security feature, which allows the LDAP server to detect and block such forwarded authentication requests once enabled. 

Main thing to point out is which values will these settings have once the January 2020 update rolls out.

Here they are:  

  • LDAP Channel Binding = 1 

AD – HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNTDSParameters 

ADLDS – HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesParameters 

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. 

  • LDAP Server Integrity (signing) = enabled by default 
https://support.microsoft.com/en-us/help/935834/how-to-enable-ldap-signing-in-windows-server-2008

I want to note that this article shows two sections related to server and client, that need to be configured: 

set the server LDAP signing requirement nbsp;nbsp;

set the client LDAP signing requirement through a domain Object nbsp;nbsp;

Important Notes  

– Before you enable this setting on a Domain Controller, clients must install the security update that is described in CVE-2017-8563. Otherwise, compatibility issues may arise, and LDAP authentication requests over SSL/TLS that previously worked may no longer work. By default, this setting is disabled. 

– The LdapEnforceChannelBindings registry entry must be explicitly created.  

– LDAP server responds dynamically to changes to this registry entry. Therefore, you do not have to restart the computer after you apply the registry change. 

 
To maximize compatibility with older operating system versions (Windows Server 2008 and earlier versions), we recommend that you enable this setting with a value of 1
 
To explicitly disable the setting, set the LdapEnforceChannelBinding entry to 0 (zero). 

Windows Server 2008 and older systems require that Microsoft Security Advisory 973811, available in “KB 968389 Extended Protection for Authentication”, be installed before installing CVE-2017-8563. If you install CVE-2017-8563 without KB 968389 on a Domain controller or AD LDS instance, all LDAPS connections will fail with LDAP error 81 – LDAP_SERVER_DOWN. In addition, we strongly recommended that you also review and install the fixes documented in the Known Issues section of KB 968389

Summarizing 

Summarizing a little this long article we can state the following: 

  1. Directory Services Log is our friend: Event IDs 2886,2887,2888,2889
  2. On Clients we need to have as a prerequisite CVE-2017-8563 “Extended Protection for Authentication” before we enable LDAP CBT and LDAP Signing

If we don't want to wait for the January 2020 update 

  1. Enable LdapEnforceChannelBinding = 1 
  2. Enable  LDAP Server Signing 
    • DC = Domain controller: LDAP server signing requirements = Require Signing
    • Servers/Clients = Network security: LDAP client signing requirements Properties = Require Signing

Hope this helps understanding how these settings work and how they will be configured after the January 2020 update, which can affect your LDAP Authentication if you don't make any changes. 

Regards to All 

Alan @ PFE 

 

This article was originally published by Microsoft's Azure SQL Database Blog. You can find the original article here.