Legacy application configurations may still use 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.
With more remote and hybrid environments, LDAP authentications are more often crossing the public internet, thereby requiring additional security mechanisms.
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 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 itself. However, while much of AD’s functionality is built on LDAP, they’re not one and the same – in fact, 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.
What’s the Difference Between LDAP and LDAPS?
LDAPS isn’t a fundamentally different protocol: it’s the same old LDAP, just packaged differently. LDAPS allows for the encryption of LDAP data (which includes user credentials) in transit during any communication with the LDAP server (like a directory bind), thereby protecting against credential theft.
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.
Due to the rise in security risks and increasing need for in-transit encryption, LDAPS is replacing LDAP as the accepted standard directory protocol. Here’s how IT administrators can implement this switch.
Implementing LDAPS (LDAP Over SSL)
Typically, LDAP and LDAPS are enabled at the root level, making Secure LDAP available to all directory binds. In cloud-hosted LDAP environments, for instance, it’s made available in the LDAP platform.
In AD, on the other hand, you enable it on the domain controller or global catalog. In AD, enabling LDAPS doesn’t automatically force LDAPS unless you set it to do so; requiring LDAPS binds immediately could break binds with resources still using 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.
A domain controller or other LDAP server that has its certificates properly configured will offer LDAPS via port 636 (3269 to a global catalog server) and STARTTLS via port 389. 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. However, port 389 supports both plain-text and STARTTLS – only use port 389 for authentications that support STARTTLS; otherwise, use port 636 for LDAPS. (Datacenter management consultant Kurt Roggen lays out step-by-step details of this process on his blog.)
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.
Do I Still Need LDAP/LDAPS?
Given some of the workarounds necessary in order to use LDAP securely, you might be wondering if LDAP 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 Active Directory 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 cloud LDAP management.