In many Active Directory Domain Services environments, LDAP is a common protocol to provide access to objects and their attributes in the directory. The Lightweight Directory Access Protocol (LDAP) is an open protocol for use with various directory services, including Active Directory.
Over the years, Microsoft has been made aware about vulnerabilities in the way Domain Controllers handle LDAP requests. We’ve blogged about it in 2017 regarding CVE-2017/8563 and the information available back then.
What’s New
Microsoft intends to change the default behavior of the LDAP endpoints on Domain Controllers and on servers running Active Directory Lightweight Domain Services (AD LDS). These changes will configure more stringent requirements by default for LDAP channel binding and LDAP signing. Instead of not requiring these security measures (effectuated by the value 0 in the lines of Windows PowerShell below) or politely asking for them (effectuated by the value 1) , they will be required always (effectuated by the value 2).
Microsoft has documentation on a roll-out schedule. However, admins can test their exposure to these changes and take mitigating actions to prevent impact of these changes to functionality offered to their colleagues and customers before these changes are rolled out to default configurations.
Who and what is impacted?
Not all AD admins have to deal with functionality that communicates using LDAP with Domain Controllers. If an organization doesn’t use LDAP or LDAPS, it is not impacted.
These changes will be made to Domain Controllers running default settings for LDAP channel binding and LDAP signing, only. If an organization uses non-default settings, they will not be impacted at this time.
Sources using LDAP (ldap://, on TCP port 389 and 3268) are likely to be affected. Sources using LDAPS (ldaps://, on TCP port 636 and 3269) are likely fine if they use direct connections and not through proxies or load balancers.
Approach
There are three approaches to these changes:
1. Test the new settings and remediate issues
To benefit from these changes, perform them manually and remediate any issues that may arise.
2. Configure non-default settings for interoperability
You can opt to set non-default settings for LDAP channel binding and LDAP signing.
This is a useful approach if your tests reveal interoperability issues In this case, set the non-secure LDAP options on all systems running Active Directory Domain Services and Active Directory Lightweight Domain Services in scope of the issue.
This is also a perfect approach if you like to live dangerously, in general.
3. Do nothing
If you don’t use LDAP or LDAPS to communicate to Domain Controllers, your networking environment is not impacted. You’ll receive the gift of more secure LDAP, by default, on supported Windows Server Operating Systems from Microsoft soon.
Obviously, the first approach is the best approach; There is no way of telling if Microsoft at a point in time will override non-default settings, if Microsoft will continue to support non-default settings. Likewise, your organization may in the future deploy functionality that may not support LDAP channel binding and LDAP signing.
Implement these changes manually
Perform the following steps manually to implement Microsoft’s changes manually to Domain Controllers. This will help identify any issues that may arise.
LDAP Channel Binding
On Windows Server 2012, Windows Server 2012 R2 and Windows Server 2016, make sure the July 2017 Cumulative update (KB4025331, KB4025336 and KB4025339, respectively) or a newer cumulative update is installed. Otherwise, compatibility issues may arise, and LDAP authentication requests over SSL/TLS that previously worked may no longer work.
To enable LDAP channel binding, perform the following lines of Windows PowerShell on Domain Controllers:
$RegPath = "HKLM:\System\CurrentControlSet\Services\NTDS\Parameters"
New-ItemProperty -Path $RegPath -Name LdapEnforceChannelBinding
-Value 2 -PropertyType DWORD
LDAP Signing
To enable LDAP signing, perform the following lines of Windows PowerShell on Domain Controllers:
$RegPath = "HKLM:\System\CurrentControlSet\Services\NTDS\Parameters"
New-ItemProperty -Path $RegPath –Name LdapServerIntegrity
-Value 2 -PropertyType DWORD -force
Functionality that relies on unsigned SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP binds or on LDAP simple binds over a non-SSL/TLS connection stop working after you make this configuration change.
Identify issues with the new settings
To identify functionality, impacted by the LDAP Signing requirement, you can configure the directory server to provide more detailed logs. Perform the following lines of Windows PowerShell on the Domain Controller you’re using for testing:
$DiagPath = "HKLM:\System\CurrentControlSet\Services\NTDS\Diagnostics"
New-ItemProperty -Path $DiagPath –Name "16 LDAP Interface events" -Value 2 -PropertyType DWORD –force
This additional logging logs an event with Event ID 2889 when a client tries to make an unsigned LDAP bind. The logging displays the IP address of the client and the identity that the client tried to use to authenticate. When the binding type indicated is 1, then the client typically needs remediation.
If the Domain Controller 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 with Event ID 2888 one time every 24 hours when such bind attempts occur.
Roll-back these settings
To roll-back the above manual changes, perform the following lines of Windows PowerShell:
$RegPath = "HKLM:\System\CurrentControlSet\Services\NTDS\Parameters"
Remove-ItemProperty -Path $RegPath –Name LdapEnforceChannelBinding
New-ItemProperty -Path $RegPath –Name LdapServerIntegrity
-Value 1 -PropertyType DWORD –force
$DiagPath = "HKLM:\System\CurrentControlSet\Services\NTDS\Diagnostics"
New-ItemProperty -Path $DiagPath –Name "16 LDAP Interface events" -Value 0 -PropertyType DWORD –force
Concluding
Get ahead of the curve. Implement the most secure settings for LDAP today and use the extra time between now and the moment that Microsoft implements these changes to remediate any issues.
Use the lines of PowerShell above to make these changes per Domain Controller or even per LDAP functionality when you point the functionality to a specific Domain Controller in its configuration or use a specific Active Directory site.
Event 2889 occurs with Unsigned and Signed SASL Bindings over port 389 /3268 (GSSAPI / TLS). As I understand, there is always one unsigned LDAP SASL Bind (to get the KerbTicket or the certificate), and the DC accepts this. After that, the LDAP SASL Bind can be processed. So even in an environment with Signing set to "required" and all LDAP clients works fine, you will get 2889 events.
We have to wait for the March update; the new events may help to analyze the SASL Binds.
FYI,
this initially should have been postpone to Q3 or Q4 “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.”
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023
But now on the same page (recently updated) Microsoft says:
"On March 10, 2020, Windows updates will add options for administrators to harden the configurations for LDAP channel binding on Active Directory domain controllers. The updates add:
Domain controller: LDAP server channel binding token requirements group policy.
CBT signing events 3039, 3040, and 3041 with event source Microsoft-Windows-ActiveDirectory_DomainService in the Directory Service event log.
Important The March 10, 2020 and updates in the foreseeable future will not make changes to LDAP signing or LDAP channel binding policies or their registry equivalent on new or existing domain controllers."
Note that all RootDSE requests are outside of all checks and logging.
What I'm missing is the discussion on how to test and verify LDAP TLS use of CBT.