Share This Article
Contents
Updated on July 8, 2024
Legacy application configurations may still use clear-text LDAP for some directory binds in a local environment, which was 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. Today, LDAP authentications are more often crossing the public internet within remote and hybrid environments. That requires adding the appropriate security controls.
You may have heard that you need to configure legacy third-party apps to use Secure LDAP instead of clear-text LDAP. LDAPS (LDAP over SSL) and STARTTLS (LDAP over TLS) are both secure versions of LDAP that encrypt the authentication process. (Note that “LDAPS” is often used to denote LDAP over SSL, STARTTLS, and a Secure LDAP implementation.)
Switching from LDAP to LDAPS involves taking 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, extracting CA (certificate authority) certificates to create the secure bind, and continued monitoring. The process can be cumbersome and time-consuming, but it’s doable — and, now more than ever, mandatory.
Let’s take a closer look at the LDAP protocol, what makes LDAPS and STARTTLS secure, and how to implement a secure authentication process for legacy applications.
What Is LDAP? Essential Background
LDAP (Lightweight Directory Access Protocol) is sometimes used as a synonym or shorthand for Microsoft Active Directory (AD). However, while much of AD’s functionality is built on LDAP, they’re not one and the same. AD leverages a proprietary version of Kerberos more often than LDAP to authenticate user access. 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. 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?
LDAPS is an extension of the standard LDAP protocol. It uses TLS or SSL to encrypt LDAP packets, ensuring that data cannot be intercepted by third parties while in transit. It’s a significant improvement because credentials could be intercepted or a server response could be modified if it’s left unencrypted.
What Are SSL and TLS?
SSL and TLS are cryptographic protocols that use certificates to establish a secure connection between client and server before any data (in this case, LDAP) is exchanged. TLS is an improved version of SSL, making STARTTLS more secure and recommended over both LDAP and LDAPS where possible.
TLS provides better security, stronger encryption, and improved negotiation mechanisms compared to SSL. That’s mainly because TLS uses stronger cryptographic algorithms for encryption and authentication and makes it difficult to decrypt session data.
Secure LDAP is replacing LDAP as the accepted standard directory protocol due to the rise in security risks and increasing need for in-transit encryption. The following describes how IT administrators can implement this change.
How Is LDAPS Implemented?
LDAP and Secure LDAP are typically enabled at the root level, making Secure LDAP available to all directory binds. It’s easier to set up using cloud-hosted LDAP environments, because it’s made available in the LDAP platform. AD, on the other hand, requires that you enable it on the domain controller or global catalog.
It’s important to understand that AD doesn’t automatically force LDAPS unless you set it to do so; requiring LDAPS binds immediately could break binds with resources that still use plain-text LDAP. In either case, you can update legacy binds by combing through your bound resources to find and change LDAP binds to Secure LDAP.
Insecure LDAP binds pose a significant problem in AD due to security risks like exposing domain admin account credentials in cleartext, data exfiltration/manipulation, or privilege elevation. Microsoft recommends subscribing to its security services to protect identities if your organization is using AD, which it deems a legacy product.
When binding with LDAPS, many applications require you to upload a Peer Certificate Authority; here’s how to do so in AD, and here’s how to do so on Mac, Windows, and Linux with JumpCloud, a cloud-hosted LDAP service.
JumpCloud Cloud LDAP
Upgrading Windows Server or OpenLDAP? Try JumpCloud to securely manage LDAP in the modern era of IT
It’s important to understand auditing. You can find and fix unsecured binds individually by combing through your directory service event log — any application using a port other than 636 and 3269 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.
Which Port Does LDAPS Use by Default?
LDAPS uses port 636 by default. Communication over this port is encrypted for data security. LDAPS requires properly configured SSL/TLS certificates on the server to establish a secure connection. In contrast, port 389 is used for unencrypted LDAP or LDAP with STARTTLS, which upgrades the connection to use TLS.
The choice between these ports depends on security requirements and server/client configurations.
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 authentication protocols, many 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 your 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 AD or on-prem 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 Secure LDAP functionality included and all data in transit automatically encrypted. Learn more about JumpCloud’s cloud LDAP management.
