What is LDAP?
Securing LDAP Communications in Active Directory. Lightweight directory access protocol (LDAP) is an open protocol used to lookup information within a network. LDAP is often used to retrieve some piece of information from the directory server which is usually a certain kind of database. Directory servers, such as Active Directory Domain Services (AD DS), store the information about different network objects and their attributes. Then, this information is retrieved using the LDAP protocol. The protocol works the following way:
- The client (usually referred as a directory user agent, or DUA) establishes connection with the LDAP server (directory system agent, or DSA).
- DUA sends the request for the required information and provides user credentials, usually username and password.(also see password reset tool).
- DSA authenticates and authorizes.
- If the authentication is successful, the server provides the requested information.
Securing LDAP in Active Directory
Though LDAP is not used as a default authentication and authorization protocol in AD (it uses Kerberos). Many components of directory described in the LDAP specification, such as hierarchy, attribute schema and others, are used in AD. Most importantly, LDAP queries are used to interact with the directory and this communication must be well protected.
Enabling LDAPS
By default, LDAP traffic is not protected, and data is transferred as a plain text. The connections can be secured by encrypting the traffic using the Transport Layer Security (TLS) certificate, which prevents the man in the middle attacks. This approach is the most common way of protection of LDAP traffic and considered as a best practice. Enabling LDAPS doesn’t require any special config. You must place the appropriate TLS certificate to the local computer’s personal store. More details- see Local Machine and Current User Certificate Stores) of each domain controller.
Certificate Requirements
- Must be trusted by both domain controllers and LDAP clients. Therefore, if all the clients are members of the domain, issue the certificate using the Active Directory Certificate Authority. And if there are external clients – the certificate should be issued by a trusted third-party certificate authority.
- Must include the private key. So if you use one of the domain controllers to create a certificate signing request for a certificate. Then you plan to use the same certificate for other domain controllers, please ensure to mark private key as exportable.
- Strong private key protection must be disabled. For more details about strong key protection see What is a strong key protection in Windows?
- The fully qualified domain name (FQDN) of the domain controller must be presented in either subject name or subject alternative name (SAN) of the certificate. For example, if you want to purchase a certificate used for LDAPS in 4 domain controllers, specify 1 FQDN in the subject name attribute and 3 others – in SAN.
- Enhanced Key Usage extension of the certificate must include the Server Authentication object identifier.
The certificate enrolment and installation procedures are standard. Detailed instructions are found in Advanced Certificate Enrollment and Management). When the certificate is issued and installed to the local computer’s personal store, the domain controller must be restarted. After the restart, the server starts accepting the LDAPS connections over TCP port 636, so you need to ensure that the port is accessible for connections.
Try our Active Directory & Office 365 Reporting & Auditing Tools
Try us out for Free. 100’s of report templates available. Easily customise your own reports on AD, Azure AD & Office 355.
Enforcing LDAPS
When you enable LDAPS, secured connections to domain controllers become possible, but not guaranteed. To ensure that only protected LDAP queries are accepted by your domain controllers, enforce LDAP signing requirement on both client and server levels. The most effective approach is to use GPO for this purpose.
Configure Domain Controllers
To configure the domain controllers to only accept the secured LDAP queries use two GPO objects. The first one, LDAP server signing requirements enforces the LDAPS usage, while the second, LDAP server channel binding token requirements, adds and extra security level by preventing attackers from reusing TLS session credentials captured in another TLS session (more details are here: 2020, 2023, and 2024 LDAP channel binding and LDAP signing requirements for Windows (KB4520412)).
- Logon to domain controller and run the Group Policy Management console.
- In the hierarchy tree on the left side, navigate to Domains > Domain Name > Domain Controllers, right click on Default Domain Controllers Policy and select Edit.
- In the appeared Group Policy Management Editor window, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. In the list of options shown on the right side of the window, right-click Domain controller: LDAP server signing requirements entry and click Properties.
Enable Define this Policy Setting
- Following with the steps, in point 4, when the Properties window appears, enable Define this policy setting checkbox. Then select Require signing and click OK.
- In the Confirm Setting Change warning message, select Yes.
- Right click on the Domain controller: LDAP server channel binding token requirements entry and click Properties.
- In Properties window, enable Define this policy setting option, select either Always or When Supported value and click OK. The value selection depends on your requirements – the preferable value is Always (recommended by many organizations, including Center for Internet Security). However, if your network contains devices that don’t support LDAP channel binding, consider using the When Supported value instead.
- Close the Group Policy Management Editor window.
If you are not sure whether all LDAP clients support channel binding, set the When Enabled value and set monitoring tool to listen to 3074 and 3075 events on all Domain Controllers. It helps to identify the presence of such legacy devices and act accordingly.
Configure Domain Controllers
To ensure that clients use LDAPS to send queries to domain controllers, you need to use GPO. The best way is to use Default Domain Policy, as it covers all domain-joined objects. If there are clients external to the domain that use LDAP – use their vendor recommendations for enabling encrypted LDAP connections.
- Back in the Group Policy Management console, navigate to Domains > Domain Name, right click on Default Domain Policy and select Edit.
- In the appeared Group Policy Management Editor window, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. In the list of options shown on the right side of the window, right-click Network security: LDAP client signing requirements entry and click Properties.
- When the Properties window appears, enable Define this policy setting option, select Require signing and click OK.
- In the Confirm Setting Change warning message, select Yes.
- Close the Group Policy Management Editor window.
For more details about this GPO see Network security: LDAP client signing requirements. After the policy is applied to the client machines, they only establish secured connections to the domain controllers.
Well, that is it. Article Securing LDAP Communications in Active Directory is concluded. We head over to a conclusion section. Thank you!
Conclusion Securing LDAP Communications in Active Directory
LDAP, being an open and vendor neutral protocol, serves as a fundamental tool for retrieving and managing data stored in directory services like AD DS. Safeguarding LDAP communications within Active Directory is necessary. The protocol is not secure by default and allows unencrypted connections. Enabling LDAPS emerges as a best practice to enhance LDAP protection. By encrypting LDAP traffic using TLS certificates, organizations mitigate the risk of man-in-the-middle attacks and ensure the confidentiality of data transmitted between clients and servers. Moreover, enforcing the signing requirements through GPO (or any other managing tool) on both client and server levels ensures that only protected LDAP queries are accepted by domain controllers. It further mitigates the risk of unauthorized access and potential security breaches.
Try InfraSOS for FREE
Try InfraSOS Active Directory, Azure AD & Office 365 Reporting & Auditing Tool
- Free 15-Days Trial
- SaaS AD Reporting & Auditing Solution
