LDAP and why it is used
Lightweight Directory Access Process (LDAP) serves as a user authentication mechanism tailored for directory services. This protocol is commonly employed by applications to retrieve resource data such as user profiles and various system elements. LDAP enables the identification of a client’s attributes with servers such as Active Directory, OpenLDAP, and Open DJ. Introduced in 1993, LDAP version 3 has been the Internet standard for directory services since 1997. LDAP configuration is important for security hardening and compliance.
LDAP is frequently used as a centralized repository for storing user credentials, such as usernames and passwords. This centralized storage mechanism enables multiple applications and services to interface with the LDAP server for user authentication purposes.
By leveraging LDAP, organizations can establish a unified authentication system, streamlining access management across various platforms and services. This approach enhances security by centralizing user credentials management, simplifying administrative tasks, and ensuring consistent authentication procedures across the network. Additionally, LDAP’s flexibility allows for seamless integration with diverse systems, contributing to its widespread adoption as a fundamental component of identity management solutions.
What is LDAP authentication (LDAP simple bind)?
The most common method for authenticating LDAP clients is through simple bind authentication. In this process, the client either binds anonymously, using an empty bind Distinguished Name (DN) or provides a DN along with a password. The Directory Proxy Server binds to a data source to verify these credentials and authenticate the client.
LDAP authentication can be illustrated effectively with an example involving an employee attempting to access their organization’s network. Since the most common action performed in such scenarios is logging into the network, the predominant function utilized is ‘read’. The LDAP protocol is specifically engineered to efficiently manage a large volume of read operations like these.
There are two main components in the LDAP authentication mechanism:
- LDAP Directory Server Setup – where the employee profile details are stored (username and password in this case).
- LDAP client – the employee's computer. It should have an LDAP client option setup. If the employee is going to authenticate through a web application, then the server hosting the application must be configured with an LDAP client.
LDAP authentication process has two stages:
- Identifying the user's directory attribute - The user entry is identified by its DN, which is the path to its details. In the first stage of the authentication, the user must obtain its DN and password. The user name usually requested in the login form is used to find the user's DN. A function called DN Resolution takes the user name (or email in some cases) and runs a search to find all the user entries to find his DN. Once the correct user DN is resolved, the next step is to validate the user's password.
- Password validation - The user's password is checked by a command called 'bind'. The LDAP directory server receives a request to authenticate the user bypassing its DN and password. If the credentials are correct, the directory server returns success, and the connection is established.
2 Security settings that do not have any impact on LDAP simple bind are:
- Ensure ‘Network security: LDAP client signing requirements’ is set to ‘Negotiate signing’ or higher
- Ensure ‘Domain controller: LDAP server signing requirements’ is set to ‘Require signing’
What is LDAP channel binding?
Security setting 'Ensure ‘Domain controller: LDAP server channel binding token requirements’ is set to ‘Always’ discusses channel binding.
This configuration option determines whether the LDAP server (Domain Controller) mandates the verification of Channel Binding Tokens (CBT) included in LDAP bind requests transmitted over SSL/TLS, commonly referred to as LDAPS.
The recommended state for this setting is: Always.
Mandating Channel Binding Tokens (CBT) serves as a preventive measure against attackers attempting to exploit captured authentication credentials (such as OAuth tokens or session identifiers) by deterring their reuse in separate TLS sessions. Additionally, this practice strengthens defenses against “man-in-the-middle” attacks when employing LDAP authentication over SSL/TLS (LDAPS).
When first deploying this setting, you may initially want to only set it to the alternate setting of When supported (instead of Always) on all Domain Controllers. This alternate, interim setting enables support for LDAP client channel binding but does not require it. Then set one DC that is not currently being targeted by LDAP clients to Always, and test each of the critical LDAP clients against that DC (and remediating as necessary), before deploying Always to the rest of the DCs.
By automated configuration hardening of this setting organizations can guarantee that the desired configurations are uniformly applied across all Domain Controllers. It eliminates the potential for human error that may occur with manual configuration, reducing the risk of misconfigurations that could compromise security. Automated configuration hardening enables organizations to swiftly implement changes and updates across their infrastructure, enhancing overall agility and responsiveness. Automated testing mechanisms can be integrated to validate configurations and assess their impact on critical LDAP clients, ensuring that any necessary adjustments are promptly identified and remediated.
What is LDAP signing?
LDAP Signing is a security feature that ensures the integrity of communications between LDAP clients and domain controllers. LDAP signing is a feature of the Simple Authentication and Security Layer (SASL). 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)
How to Enable LDAP Signing Configuration
For enabling LDAP signing in the server and the client you can either use Group Policy Object (GPO) or a registry key.
How to configure a server LDAP signing GPO:
- Go to 'Default Domain Controller Policy' > 'Computer Configuration' > 'Policies' > 'Windows Settings' > 'Security Settings' > 'Local Policies', and then select 'Security Options'.
- Right-click 'Domain controller: LDAP server signing requirements', and select Properties.
- Enable 'Define this policy setting', select 'Require signing' in the 'Define this policy setting list', and then select OK.
How to configure LDAP Singing at a client's local computer policy:
- Go to 'Local Computer Policy' > 'Computer Configuration' > 'Policies' > 'Windows Settings' > 'Security Settings' > 'Local Policies' and select 'Security Options'.
- Right-click 'Network security: LDAP client signing requirements' and select 'Properties’.
- In the dialog box, select 'Require signing' in the list, and then select OK.
How to configure a server LDAP signing using a registry key:
Note! We recommend backing up your registry before pushing any changes, as mistakes can have devastating results.
You need to create an LDAPServerIntegrity registry entry of the REG_DWORD type under the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<InstanceName>\Parameters
*instance name= the name of the AD LDS you want to configure.
LDAP Vulnerabilities Affecting Domain Controllers
CVE-2023-21676: A security flaw within LDAP poses a risk of enabling a remote code execution by an authenticated attacker on Windows Server installations functioning as Domain Controllers. This vulnerability presents a low-complexity attack vector accessible over the network.
CVE-2023-21557: is a vulnerability in LDAP that could allow an unauthenticated attacker could send a specially crafted request to a vulnerable LDAP server. Successful exploitation could result in bypassing a buffer length check which could be leveraged to achieve information leak.
LDAP Configuration Hardening
To improve the security of your directory server you can implement several configuration rules. These rules are best practices, and recommended also by the Center for Internet Security (CIS):
- Ensure 'LDAP server signing requirements’ is set to ‘Require signing’. – This policy setting will make clients use data signing.
- Ensure ‘Extended Protection for LDAP Authentication (Domain Controllers only)’ is set to ‘Enabled: Enabled (recommended: always) – this setting controls LDAP authentication over SSL/TLS.
- Ensure ‘Network security: LDAP client signing requirements’ is set to ‘Negotiate signing’ or higher - this policy sets the level of signing requested by the client who issues LDAP request.
LDAP Configuration and the MITRE ATT&CK Framework
Configuring LDAP for optimal security is a recommended best practice by the MITRE ATT&CK framework stating few techniques and mitigations
T1087– Adversaries may attempt to get a listing of domain accounts. This information can help adversaries determine which domain accounts exist to aid in follow-on behavior such as targeting specific accounts which possess particular privileges. Commands such as net user /domain and net group /domain of the Net utility, dscacheutil -q groupon macOS, and ldapsearch on Linux can list domain users and groups. PowerShell cmdlets including Get-ADUser and Get-ADGroupMember may enumerate members of Active Directory groups.
T1482- MITRE ATTACK framework clasify LDAP configuration settings under the technique- Domain Trust Discovery– , stating that Adversaries may attempt to gather information on domain trust relationships that may be used to identify lateral movement opportunities in Windows multi-domain/forest environments. Domain trusts can be enumerated using LDAP. the Windows utility Nltest is known to be used by adversaries to enumerate domain trusts.
Changing configurations as part of server hardening is critical for security but may cause severe damage. We strongly recommend using automation to prevent any possible outages in your production. The alternative for automation is using manual tools (GPO for example), testing the impact of the change in a lab environment, and hoping you covered all possible scenarios. By using automation in hardening, you will not need to test. You will get a full impact report to help you make the best decision for both security and operations.
