Beware of Microsoft’s LDAP Server CVE-2017-8563 Fix

[German]Microsoft has updated several products on July 11, 2017, to close a Windows Elevation of Privilege Vulnerability(CVE-2017-8563). But there are manual actions required to fix the vulnerability finally.


The Hacker News has been reporting this critical flaw within Microsoft’s Windows NTLM security protocols here. They wrote:

The first vulnerability involves unprotected Lightweight Directory Access Protocol (LDAP) from NTLM relay, and the second impact Remote Desktop Protocol (RDP) Restricted-Admin mode.

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

Microsoft provided patches for all supported Windows versions. But it’s not sufficient, just to install the patches. In an Active Directory environment, you need to take care of the following advise, Microsoft has given within its KB articles.

In addition to installing the updates for CVE-2017-8563 are there any further steps I need to carry out to be protected from this CVE?
Yes. To make LDAP authentication over SSL/TLS more secure, administrators need to create a LdapEnforceChannelBinding registry setting on machine running AD DS or AD LDS. For more information about setting this registry key, see Microsoft Knowledge Base article 4034879.

If we follow the link given above, we may read the following additional advise:

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. See Microsoft Security Advisory 973811 for more details.

This German site contains a script to check, whether the update is installed or not.


Cookies helps to fund this blog: Cookie settings

This entry was posted in Security, Update, Windows and tagged , , . Bookmark the permalink.

3 Responses to Beware of Microsoft’s LDAP Server CVE-2017-8563 Fix

  1. TP says:

    Could you help me understand this?
    How do I set the registry key for LdapEnforceChannelBinding on a domain server?

    Microsoft shows it as a key- and not as the name of the DWORD.
    Path: HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/NTDS/Parameters
    Key: LdapEnforceChannelBinding
    DWORD value: 0
    DWORD value: 1
    DWORD value: 2

    If the keys and sub-keys are the “folders”, and I add a new sub-key then the new registry hive path would be HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/NTDS/Parameters/LdapEnforceChannelBinding
    If I add a new DWORD value type to this new key, what do I name it?
    Are they calling the DWORD the key and I should I just create a DWORD in ../Parameters and name it LdapEnforceChannelBinding?

    • guenni says:

      Microsoft used the wrong nomenclature – LdapEnforceChannelBinding is not a key, it’s a value! The Path is:


      Then right click and select new value -> DWORD 32
      Set it’s content to the appriate vaule.

  2. Boogar says:

    I hate Microsoft

Leave a Reply

Your email address will not be published. Required fields are marked *