LDAP Signing Requirements for Active Directory
What is LDAP Signing?
SASL provides several mechanisms to increase the security of an LDAP connection, including user authentication, anti-tampering (message signing), and confidentiality (encryption). SASL is a communication layer that operates within LDAP on the default AD data ports (TCP port 389 and TCP port 3268).
Microsoft Recommends LDAP Signing
Microsoft recommends that you should strengthen your site's LDAP signing requirements in order to protect safety of Active Directory domain controllers from an elevation of privilege vulnerability (ADV190023).
The change will impact older desktop clients and domain controllers that do not support LDAP signing, and it might prevent them from connecting successfully to Active Directory once the update is applied.
Levels of LDAP Signing
There are three levels that SASL can use to sign data in Active Directory:
- Not required (Level 0)
- Sign if both parties are capable (Level 1)
- Always sign (Level 2)
On a domain controller, the required signing level is set in the registry key HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ NTDS \ Parameters under the value LdapServerIntegrity (REG_DWORD). The value can be overridden using Group Policy at Computer Configuration \ Windows Settings \ Local Policies \ Security Options under Domain controller: Ldap server signing requirements.
Microsoft recommends that administrators make the hardening changes described in ADV190023 by increasing the value of LdapServerIntegrity from 1 to 2.
The client signing level is set in the registry key HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ LDAP under the value LdapClientIntegrity. The value can be overridden using Group Policy at Computer Configuration \ Windows Settings \ Local Policies \ Security Options under Network security: LDAP client signing requirements.
Support for LDAP signing was added to Windows 7 (Service Pack 1) and Windows Server 2008 R2. If the client and server both support it and have a value of 1 or higher they will negotiate and use it.
Some legacy PowerShell scripts or Visual Basic scripts might attempt to open an LDAP connection using cleartext credentials if the script fails to request LDAP signing. See Identifying Clear Text LDAP binds to your DCs.
Diagnosing LDAP Signing Errors in the Event Log
To help diagnose connectivity problems with older clients, you can enable LDAP Event Logging to report attempts to connect to Active Directory using potentially conflicting LDAP signing settings. To turn on diagnostic logging, change the registry value 16 LDAP Interface Events from 0 to 2 at HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ NTDS \ Diagnostics.
When enabled, the following additional information is recorded in the Event Log:
- Event ID 2887: A count of insecure client LDAP SASL binding attempts during the past 24 hours
- Event ID 2888: A reminder that the local server is configured to reject unsigned LDAP SASL client binding attempts (once per 24 hours)
- Event ID 2889: A warning when a client attempted an insecure LDAP binding connection
The events are recorded in the Event Log under Directory Services.
Error Checking During AD Upgrade
To help mitigate this problem, U-Move starting with version 2.7.3136 will check the LDAP settings and will warn you if they will prevent a successful upgrade of Active Directory to a new server (swing migration). For example, if you attempt to migrate Active Directory from Windows Server 2008 to Windows Server 2019 and you do not override the default settings, U-Move will warn you that the LDAP signing settings are in conflict. The warning will appear in red letters in the Verify Report.
SASL and TLS/SSL are not the same
LDAP signing (SASL) should not be confused with the use of TLS/SSL encryption. The latter is an entirely different security mechanism that is based on Public Key Infrastructure (PKI) over TCP ports 636 and 3269.
TLS/SSL is rarely configured at most AD sites because it requires that you first obtain and distribute a TLS/SSL certificate for all of your domain controllers from a third party Certificate Authority (CA) or from AD Certificate Services (AD CS).
Almost all regular AD network traffic between domain controllers (DCs) and member computers use SASL over TCP ports 389 and 3268, not TLS/SSL. TLS/SSL is generally used only for low-level Linux-compatible LDAP utilities like ldp.
What is LDAP Channel Binding?
LDAP Channel Binding strengthens the security of an LDAP TLS/SSL connection to prevent a man-in-the-middle attack (CVE-2017-8563) by adding support for SSPI Extended Authentication Protection (EAP). It is used only for LDAP TLS/SSL connections.
LDAP Channel Binding requires that you install and distribute a TLS/SSL web certificate just like on a secure website. LDAP TLS/SSL connections are typically only used by Linux-compatible apps like ldp.
For More Information
|U-Move for Active Directory|