LDAP over SSL/TLS: How secure is your Directory?

One of the issues with using LDAP as an “Authentication” protocol for applications is that this usually means LDAP simple binds. LDAP simple binds by default will pass the userId and userPassword in clear text between the client and the server. This means that anyone or anything with access to that communication path can view the details and gain access to sensitive information. It seems that because of how easy LDAP is to use, applications tend to default to using simple binds for passing credentials to Active Directory (AD), which could pose security issues in your environment.

“But we are in a secure switched network environment.”

That is something I hear all the time, as an excuse why simple LDAP binds over SSL are not enforced requirements. In reality, you are only limiting your exposure, not eliminating it in a switched network environment. The same reasoning is often used with HTTP vs HTTPS, and it’s a false sense of security allowing for sensitive data to be submitted as clear text.

Issues with plaintext communications

The reality is, yes the network transport exposure is limited compared to a shared pipe, but the end points are still wide open.

Some of the points of concern would be:

LDAP traffic in the clear can be sniffed on the server/client endpoints very easily, and can be an easy way to capture sensitive information.
Network port mirroring to allow sniffing as part of troubleshooting. The application owners, administrators maybe contractors or 3rd party consultants for an application which now have access to viewing the user credentials in the clear. On a shared server environment, where multiple applications are hosted, troubleshooting one by network sniffing, may expose visibility to credentials being passed to another unsecured application on the same server.
ARP Cache poisoning has been shown to be a way of getting to be the man in the middle allowing capturing of that conversation, and placing an attacking box watching your LDAP server without TLS would be a prime target for such an attack.
In theory, a simple trojan could be installed on a client unwittingly can be set to listen for LDAP bind attempts within your enterprise because LDAPS is so uncommonly enforced.

Securing communications via SSL/TLS

To mitigate this, the simplest way is to NOT use LDAP simple binds, and utilize a SASL bind which support the GSSAPI and can use real authentication protocols like Kerberos via a when authenticating users. Of course this is not realistic, because LDAP has become the the lowest common denominator as far as application integration goes. Many applications consider supporting LDAP as all they need to connect to Active Directory, and unfortunately convenience seems to outweigh security.

By utilizing SSL, the transport is encrypted, and is hidden from any network sniffing attempts on both the client and the server endpoints. SSL is a oneway mechanism which identifies the trusted served to the client to open a secure tunnel for passing sensitive data protecting it from 3rd party viewing. While unencrypted traffic can be useful for troubleshooting, it is a better practice to require SSL for applications which utilize a simple bind if a SASL bind is not possible. One of the drawbacks of SSL is that it does require a PKI infrastructure to be in place that supports issuing Server Authentication certificates to the directory server. The clients also need to have the certificate hierarchy as a trusted chain in order to establish an SSL connection. There is also an overhead for SSL communications as there are performance implications for encrypting all traffic as well, yet on today’s robust and often overpowered hardware, this should be an issue only for few deployments.

In the absence of certificates, Kerberos can also be used to Sign and Seal the conversation when using a Windows to Windows client and server which supports Kerberos, but this may leave out other platforms.

TLS is the modern, more secure, successor to SSL and can be used as a mutual (Client and Server) authentication mechanism to secure the connection as well, but I personally have not seen many applications from vendors widely supporting this.

Securing ADAM binds

When using an ADAM instance you can enforce the using of Secure Simple Binds by setting the RequireSecureSimpleBind and RequireSecureProxyBind values to 1 in the configuration of the instance. It is important to note, that it will not stop the accepting of clear text bind attempts, but they will not successful. So applications which are a not using LDAPS will not be able to bind, and will hopefully resolve the problem quickly if capable by switching to LDAPs.

Applications are the toughest to secure

So while in most cases the directory infrastructure can be configured quite simply to support SSL/TLS for simple bind operations, it is the applications that must be configured to use the secure ports that will be the hardest task to implement. Unfortunately this would require baseline security requirements for applications within your environment, which may not meet the business requirements if a much needed application does not have support for secure LDAP. It will be up to your environment to which requirement trumps the other, but hopefully a secure environment is the preferred mind set.