Lightweight Directory Access Process (LDAP) is a user authentication process developed for directory services. This protocol is usually used by applications for searching resource information such as users and different system components. LDAP identifies a client’s properties with servers such as Active Directory, OpenLDAP, and Open DJ. It was first introduced in 1993 and since 1997 LDAP 3rd version is the Internet standard for directory services.
In the common scenario, the client is a system or application requesting information access from a database in an LDAP server. The LDAP database can store not only usernames and passwords but other attributes such as an address, phone number, and other core user identities.
This blog post will cover the following topics:
- LDAP Signing.
- LDAP Channel Binding.
- LDAP and Active Directory.
- Securing Active Directory LDAP Authentication Without Breaking Production
LDAP signing is also a way to increase LDAP security. The signing process refers to a digital signing of the LDAP traffic that is done by the traffic source (client). LDAP signing blocks attackers from altering the LDAP traffic during transit (like in Reply and Man-in-the-Middle attacks). Using LDAP signing guarantees information integrity and enables verification of the source of the information. You must configure both the Domain Controllers and clients to enable LDAP signing for it to work.
LDAP Channel Binding:
When talking about channel binding it is usually referred to as binding the transport layer to the application layer.
LDAP channel binding is a method developed to increase security in communication with Active Directory (AD). LDAP channel binding lowers the chances for replay and man-in-the-middle attacks. The binding is between the LDAP application layer and the TLS tunnel. Binding these two will create a unique LDAP communication fingerprint. This unique fingerprint is important for security since any interference to the communication will affect the fingerprint and can be detected.
LDAP and Active Directory:
There are two critical LDAP configurations that must be enforced in Active Directory Domain Controllers.
Domain Controller LDAP communication must require signing:
Unsigned network traffic is a good source for man-it-the-middle attacks. LDAP man-in-the-middle attacks can result in Domain Controllers making decisions that are based on false information coming from the LDAP directory. Therefore, requiring LDAP signing is crucial in Domain Controllers. Another way to improve security is to use IPsec authentication header mode to ensure mutual authentication and packet integrity for IP traffic. The default LDAP configuration does not require signing, so it is important to take active actions to prevent this high-risk vulnerability.
Note that Domain Members’ LDAP must be configured to negotiate signing or higher, or they won’t be able to communicate with the Domain Controller.
You should test the potential impact of this policy before enforcing it, to make sure that there are no clients that are configured to authenticate with AD while using unsigned LDAP. Requiring signing will interfere with these applications’ functions. For more information about how you can automate the testing and enforcement process, continue your reading here.
Domain Controller LDAP communication must require channel binding always:
Requiring Channel Binding can prevent from attackers capturing users’ credentials and reusing them in another TLS session. I addition, it helps to lower the chances for man-in-the-middle attacks.
By default, no LDAP channel binding validation is performed. Changing this setting from ‘Never’ to ‘Always’ can have an impact on production.
Requiring channel binding means that all authentication request that doesn’t use channel binding will be rejected. Therefore, all LDAP clients must provide information binds over SSL/TLS. Clients must have security updates under CVC-2017-8563 to support channel binding. Having channel binding without this security update installed may not be enough.
In addition, it is recommended to have the March 2020 security update installed to create an Event ID 3039 whenever a client do not use channel binding tokens in their LDAPS connection.
Securing Active Directory LDAP Authentication without breaking production:
There are many scenarios where Active Directory’s unique LDAP configuration requirements can lead to Domain Members and applications not being able to authenticate and communicate with the Domain Controllers. It is not uncommon when security and functionality don’t come in one hand.
To prevent production dysfunctions you should perform an impact analysis. The most common method for impact analysis is to first change the setting in a test environment that simulates your production. This is feasible only in infrastructures with a limited number of servers (up to 150 servers, according to our experience). Building a test environment for large and complex infrastructures is very resource-demanding. Therefore, most large organizations leave their Active Directory LDAP unhardened.
The best solution for this challenge is to automate the hardening procedure. A good hardening automation tool should generate an impact analysis report automatically, enforce your policies on your production and maintain your servers’ compliance posture. A hardening automation tool is essential for minimizing the attack surface and achieving compliance at large and complex infrastructures.