This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
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
2887 Telling us how many such binds occurred
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-encrypted) 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 how to 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 HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /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.
The security bulletin states the following:
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.
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: 2 indicates enabled, always (All clients must provide channel binding information. The server rejects authentication requests from clients that do not do so)
Also ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing: https://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 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.
The update addresses this vulnerability by incorporating support for Extended Protection for Authentication 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_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
ADLDS - HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<LDS instance name>\Parameters
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:
- How to set the server LDAP signing requirement
- How to set the client LDAP signing requirement through a domain Group Policy Object
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:
- Directory Services Log is our friend: Event IDs 2886,2887,2888,2889
- 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
- Enable LdapEnforceChannelBinding = 1
- Enable GPO 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