Legacy application configurations may still be using clear text LDAP for some directory binds in a local environment. Though these traditional LDAP binds were relatively harmless within the fortified LANs of yesteryear, modern security baselines require encryption of all user credentials in transit to protect against password sniffing and other forms of credential theft.
You might’ve heard that you need to configure rogue apps to use LDAPS (secure LDAP) instead of LDAP. This involves a close look at your directory service events log, manually identifying and switching the ports that legacy apps are using to bind to the directory, and continued monitoring. The process can be cumbersome and time consuming, but it’s doable. Let’s take a closer look at the LDAP protocol, what makes LDAPS secure, and how to implement a secure authentication process for legacy applications.
What is LDAP? Essential Background
LDAP (Lightweight Directory Access Protocol) sometimes gets used as a synonym or shorthand for Active Directory® itself. It’s important to note that while a lot of AD’s functionality is built on LDAP, they’re not one and the same. LDAP is one of the protocols that many on-prem apps and other resources use to authenticate users against a core directory like AD or OpenLDAP.
Here’s a more in-depth look at how LDAP works. And if you want to hear more about the protocol straight from its co-creator, check out our interview with Tim Howes:
What’s the Difference Between LDAP and LDAPS?
Secure LDAP (LDAPS) isn’t a fundamentally different protocol: it’s the same old LDAP, just packaged differently. Also known as LDAP over TLS and LDAP over SSL, LDAPS allows for the encryption of LDAP data (which includes user credentials) in transit when a directory bind is being established, thereby protecting against credential theft.
As cryptographic protocols, SSL and TLS use certificates to establish a secure connection between client and server before any data (in this case, LDAP) is exchanged. (TLS has replaced the now-obsolete SSL, but the two names are still sometimes used interchangeably even though they are two separate things.) SSL was originally developed to secure client-server communications over the internet, though encryption has become just as necessary in local environments as a precaution against more sophisticated attacks.
Implementing LDAPS (LDAP Over SSL)
The first step toward implementing LDAPS is to identify any applications that aren’t already using it. You can usually tell by which port the app is using to bind to AD or OpenLDAP. A domain controller or other LDAP server that has its certificates properly configured will offer LDAPS via a certain port (port 636 with AD). You can find and fix unsecured binds individually by combing through your directory service event log — any application using a port other than 636 should be investigated. In AD, most of the culprits will show connections via port 2889. For OpenLDAP, the port is often 389. (Datacenter management consultant Kurt Roggen lays out step-by-step details of this process on his blog.)
Do I Still Need LDAP/LDAPS?
Given some of the workarounds necessary in order to use LDAP securely, you might be wondering whether the protocol still has a place in the modern IT landscape. The short answer is that it does: Although the transfer of workloads to the cloud has led to the rise of other authN protocols, a lot of hardware and software solutions on-prem and at data centers still use LDAP. Tim Howes summed it up well at the end of our interview:
“You look at the world moving more and more to the cloud, but there’s still a world left behind in your local environment — you’ve got devices, you’ve got printers, you’ve got everything. People also need to be authenticated in these different contexts.”
So the question becomes less “Do I still need LDAP,” and more “Is there a better way to securely manage LDAP in the modern era of IT?”
A Modern Approach to LDAP & LDAPS
If you go through the evaluation process above and discover more than a handful of unsecured LDAP connections, this is likely a sign that your directory and applications need an update. Before you commit to the cost of upgrading Windows Server or OpenLDAP and any associated hardware, you may want to consider a more modern and comprehensive solution for LDAP management.
What if instead of doubling down on Active Directory or OpenLDAP, you could migrate your users and systems to an entirely new directory hosted in the cloud? Your new directory could securely manage both authorization and authentication for a wide variety of resources in the cloud and on-prem, with LDAP functionality included and all data in transit automatically encrypted. Learn more about cloud LDAP management.