Hi All, Alan here again, this time trying to give some details on these two settings that will become active from March 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
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:
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.
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
This is the Event ID you want to check in order to understand which IP Address 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”
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.
AUDITING LDAP Channel Binding :
Logging of LDAP Binds Not Using CBT
NOTE: these events will only be logged once the update is installed
Same registry key as for LDAP Signing, so "16 LDAP Interface Events = 2 "
EventID 3039 Informational
EventID 3040 Informational
Very important NOTE: 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
ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023
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 March 2020 update rolls out.
Here they are:
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.
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
- 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).
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.
Receiving many questions on how to disable this behavior and seems like it's still not quite understood
THE ONLY WAY TO DISABLE LDAP SIGNING is via REGISTRY (LDAPServerIntegrity = 0).
If you set via GPO, for eample configuring None, it will be changed by update
LDAP Signing Group Policy - No Downtime
After installing ADV190023 both settings (even None and Not Defined) will enforce Require Signature
Only 0 (OFF) will not enforce Require Signature
NOTE (not recommended, but if you really want to stick with disabling):
This means that value of "0" in registry means "OFF" and this also means that the update will not change the setting and not enforce Require Signing
DC: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters --> LDAPServerIntegrity = 0
LDAP Signing Group Policy - Behavior Change Example
If we don’t want to wait for the March 2020 update
Summarizing a little this long article we can state the following:
Hope this helps understanding how these settings work and how they will be configured after the March 2020 update, which can affect your LDAP Authentication if you don’t make any changes.
Regards to All
Alan @ PFE
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.