No announcement yet.

Microsoft wants to break your network: ADV190023 LDAPS Changes


  • Microsoft wants to break your network: ADV190023 LDAPS Changes

    This information came through a while ago, pretty much ignored it until now. Finally got round to actually reading it, wish I did it sooner! Initial information release was August 2019, so yea little late getting round to it.



    LDAP channel binding and LDAP signing provide ways to increase the security of network communications between an Active Directory Domain Services (AD DS) or an Active Directory Lightweight Directory Services (AD LDS) and its clients. There is a vulerability in the default configuration for Lightweight Directory Access Protocol (LDAP) channel binding and LDAP signing and may expose Active directory domain controllers to elevation of privilege vulnerabilities.  Microsoft Security Advisory ADV190023 address the issue by recommending the administrators enable LDAP channel binding and LDAP signing on Active Directory Domain Controllers. This hardening must be done manually until the release of the security update that will enable these settings by default. 


    Microsoft intends to release a security update on Windows Update to enable LDAP channel binding and LDAP signing hardening changes and anticipate this update will be available in March 2020.



    Microsoft recommends administrators make the hardening changes described in ADV190023 because when using default settings, an elevation of privilege vulnerability exists in Microsoft Windows that could allow a man-in-the-middle attacker to successfully forward an authentication request to a Windows LDAP server, such as a system running AD DS or AD LDS, which has not configured to require signing or sealing on incoming connections.  The security of a directory server can be significantly improved by configuring the server to reject Simple Authentication and Security Layer (SASL) LDAP binds that do not request signing (integrity verification) or to reject LDAP simple binds that are performed on a clear text (non-SSL/TLS-encrypted) connection. SASLs may include protocols such as the Negotiate, Kerberos, NTLM, and Digest protocols. Unsigned network traffic is susceptible to replay attacks in which an intruder intercepts the authentication attempt and the issuance of a ticket. The intruder can reuse the ticket to impersonate the legitimate user. Additionally, unsigned network traffic is susceptible to man-in-the-middle attacks in which an intruder captures packets between the client and the server, changes the packets, and then forwards them to the server. If this occurs on an LDAP server, an attacker can cause a server to make decisions that are based on forged requests from the LDAP client.



    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.


    Effectively Microsoft is in the process of no longer supporting insecure LDAP completely. Handy table for those that just want a quick answer to what should be configured, you want a tick in LDAP signing required as anything not that will not be supported by the end of the year (you can disable it though).




    Windows Updates in March 2020 add new audit events, additional logging, and a remapping of Group Policy values that will enable hardening LDAP Channel Binding and LDAP Signing. The March 2020 updates do not make changes to LDAP signing or channel binding policies or their registry equivalent on new or existing domain controllers.


    A further future monthly update, anticipated for release the second half of calendar year 2020, will enable LDAP signing and channel binding on domain controllers configured with default values for those settings.


    Administrators can prevent the feature update from making those change either by enabling LDAP signing and channel binding NOW or by configuring non-default values prior to installing updates that enable LDAP signing and channel binding by default.


    For those that work in IT will likely realize the seriousness and consequence of this right away, this change has the potential to break many fundamental aspects of services. There is a wide array of software and services that rely on LDAP and have likely been in place for 10+ years not using secure LDAP (it ain't broke don't fix it, or the guy that did it left 10 years ago and nobody knows). Some fun examples: Printing authentication and accounting, sssd Linux group membership lookups (think nobody can login anymore), user account management software, Learning Management Systems, those awesome scripts that have been in place longer than anyone currently employed that are actually vital to the functioning of the entire network.


    Authentication itself may not be LDAP but the secondary information lookups in the authentication chain usually are and if those fail to work you're going to have a bad day, a very bad day.


    So for some of you the million dollar question is, "How do we identify everything that is using simple binds to LDAP".


    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 


    This information is preliminary and is subject to revision.

    This article is a living document, written over time and is subject to change. When guidance presented in this article is in direct conflict with official documentation, one must defer to official documentation.


    AUDITING LDAP Signing : 

    To enable auditing we need to add the following registry key on each Domain Controller:

     Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagno stics /v "16 LDAP Interface Events" /t REG_DWORD /d 2  


    Once we add the key, no reboot required, the system will start logging the following event (Directory services log):


    Event ID 2889

    This is the Event ID you want to check in order to understand which IP Addresses and Accounts are making these requests.

    Once you open Event 2889 in Details you will have

    Client IP address: “Value”

    Identity the client attempted to authenticate as: “Value”


    You will also find these other events related to LDAP:



    Telling us that our DCs are not requiring LDAP signing 


    2887 (already on by default and logged every 24 hours)

    Telling us how many such binds occurred 

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



    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. 


    VMware advice:


    Redhat advice (Customer login required so full post below):


    Impact of this Advisory will enhance security measures between Active Directory and Client communication.


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

    Red Hat has verified by enforcing LDAP channel binding and LDAP signing on Active Directory Domain on Active Directory domain 2016 with various scenarios and observed no impact on Red Hat Enterprise Linux 7 and 8 client systems functionality. Following are the few scenario we have tested and confirmed to work as expected.
    • IdM/AD cross forest trust
    • Direct integration of Red Hat Enterprise Linux machine as AD client with SSSD id_provider=ad
    • Direct integration of Red Hat Enterprise Linux machine as AD client with SSSD id_provider=ldap
    • Direct integration of Red Hat Enterprise Linux machine as AD client with samba/winbind using ldap ssl ads = yes and client ldap sasl wrapping = seal options

    When SSSD is used for direct or indirect integration with Active Directory, the default configuration establishes an encrypted communication path using SASL GSSAPI and SASL GSS-SPNEGO on default LDAP port 389.


    NOTE: This information is preliminary and is subject to revision. This article is a living document, written over time and is subject to change.


    Citrix advice:


    Netapp advice:




      Posting comments is disabled.



    Article Tags


    Latest Articles