LDAP signing increases security in communication between LDAP clients and Active Directory domain controllers. LDAP signing is a Simple Authentication and Security Layer (SASL) feature, as part of the LDAP protocol used to access Active Directory.
Using the default configuration of this value allows LDAP clients to communicate with Active Directory in an insecure fashion. An attacker can use this insecure communication to elevate privileges and identify valuable assets in the network to perform various kinds of attacks such as brute force, pass the hash, pass the ticket, etc.
This blog post will cover:
- LDAP server signing requirements policy description
- The potential vulnerability when not configured right
- Countermeasures
- The potential impact of configuration change
- Vulnerability severity
- The recommended value
- How to configure LDAP signing requirements
POLICY DESCRIPTION:
This policy setting determines whether the Lightweight Directory Access Protocol (LDAP) server requires LDAP clients to negotiate data signing.
POTENTIAL VULNERABILITY:
Unsigned communication is vulnerable to man-in-the-middle and reply attacks. The intruder can capture the packet between the server and the client (domain controller) and modify it so that the client will take decisions based on false records from the LDAP directory. Eventually, the attacker will be able to perform several actions such as mapping valuable assets, admin and services account names, and leverage this information to escalate the attack.
COUNTERMEASURES:
Configure the Domain controller: LDAP server signing requirements setting to Require signature.
Restrict NTLM: Audit Incoming NTLM Traffic- The Policy Expert
POTENTIAL IMPACT:
Hardening this value will require organizational efforts and special preparations to avoid painful outcomes for several reasons.
Old versions of Windows may not support LDAP signing, thereby won’t be able to run LDAP queries against domain controllers. Windows 2000 based computers and computers that use NTLM authentication must have Windows 2000 Service Pack 3, or have a registry change.
In addition, some non-Microsoft OS, such as AD integrated Mac systems or Linux systems, do not support LDAP signing, therefore they won’t be able to access domain resources if this policy is enabled.
Bottom line, when done manually, deep research and tests must be performed before this policy is implemented. Automation tools, such as CHS, may be a great help in this case and can sometimes be the game changer when it comes to deciding whether this value is even going to be hardened.
SEVERITY:
Critical
RECOMMENDED VALUE:
When possible:
domain controllers: Require signing
Member server: Not Defined
HOW TO CONFIGURE THE SECURITY EVENT LOG:
For more information regarding practical actions to change this policy configuration in the LDAP server, by using local computer policy using domain group policy, or by using registry key click here.
AUTOMATE DOMAIN CONTROLLER HARDENING:
Server hardening can be a painful procedure. If you’re reading this article, you probably already know it. Endless hours, labor, and money are invested in this process, which can often result in production breakdown despite the effort to prevent it. CSH by CalCom is automating the entire server hardening process. CHS’s unique ability to ‘learn’ your network abolishes the need to perform lab testing while ensuring zero outages to your production environment. CHS will allow you to implement your policy directly on your production hassle-free. want to know more?
Click here and get the datasheet.
https://www.ultimatewindowssecurity.com/wiki/page.aspx?spid=DCldap
