LDAPS (Lightweight Directory Access Protocol Secure) is the encrypted version of LDAP, used to securely manage and access directory information across networks. Where standard LDAP sends data in plain text, LDAPS wraps all communication in SSL/TLS encryption, protecting sensitive information like passwords and user credentials from being intercepted.
LDAPS uses port 636 for secure communication between clients and directory servers like Microsoft Active Directory or OpenLDAP. If you are running LDAP over an untrusted network, or handling sensitive user data, LDAPS on port 636 is the recommended choice.
In this article, we will look at what LDAPS is, which port it uses, how it differs from standard LDAP, and how to set it up correctly.
What is LDAPS?
LDAPS stands for LDAP over SSL/TLS. It is not a different protocol from LDAP — it is the same protocol running over an encrypted connection. The “S” works the same way as in HTTPS, where the underlying protocol is secured using SSL/TLS.
When a client connects to a directory server using LDAPS, the encrypted connection is established first, before any data is exchanged. This is different from StartTLS, which starts the connection unencrypted and upgrades to encryption later.
LDAPS is commonly used in enterprise environments where Active Directory handles user authentication. Any application that needs to verify user credentials against Active Directory — such as a VPN, a web application, or an email server — should use LDAPS rather than standard LDAP when communicating over a network you do not fully control.
LDAPS Port 636
Port 636 is the default port for LDAPS. It uses TCP, and the encrypted connection is established at the start of every session.
When you connect to a directory server on port 636, your client and the server perform a TLS handshake before any LDAP data is sent. This means that all searches, authentication requests, and responses are encrypted from the very beginning of the connection.
If you are configuring a firewall, you will need to allow TCP traffic on port 636 between your LDAP clients and your directory server. Port 389, used by standard LDAP, can be blocked entirely in environments where LDAPS is enforced.
LDAPS vs LDAP
The main difference between LDAP and LDAPS is encryption. Standard LDAP on port 389 sends all data in plain text. This includes usernames, passwords, and any directory data returned by the server. On an internal, isolated network, this is sometimes considered acceptable, but it is a significant risk on any network where traffic can be intercepted.
LDAPS on port 636 encrypts everything using SSL/TLS from the moment the connection is opened. This protects against man-in-the-middle attacks and makes it much harder for an attacker to intercept credentials or directory data.
| Feature | LDAP | LDAPS |
|---|---|---|
| Port | 389 (TCP/UDP) | 636 (TCP) |
| Encryption | None (plain text) | SSL/TLS from connection start |
| Security | Vulnerable to interception | End-to-end encrypted |
| Certificate required | No | Yes |
| Use case | Trusted internal networks | Any network, especially untrusted |
| Performance | Slightly faster | Negligible overhead in practice |
LDAPS vs StartTLS
StartTLS is an alternative way to add encryption to LDAP. Instead of using a separate port, StartTLS starts a connection on the standard LDAP port 389 and then upgrades it to an encrypted connection using the STARTTLS command.
The difference matters for security. With LDAPS on port 636, the connection is encrypted before any data is sent. With StartTLS on port 389, there is a brief unencrypted phase at the start of the connection. If something goes wrong during the upgrade — or if a client is misconfigured — data could be sent unencrypted without either side noticing.
For most environments, LDAPS on port 636 is the simpler and safer choice. Some older systems only support StartTLS, but modern directory servers and clients support LDAPS without issues.
Setting Up LDAPS
To use LDAPS, your directory server needs a valid SSL/TLS certificate. Without a certificate, clients will not be able to verify the identity of the server, and the encrypted connection cannot be established.
SSL/TLS Certificates for LDAPS
The certificate used for LDAPS needs to meet a few requirements. The Common Name or Subject Alternative Name on the certificate must match the hostname of your directory server. The certificate must be trusted by the clients connecting to it, which usually means it needs to be issued by a Certificate Authority that the clients already trust.
In Active Directory environments, the easiest way to get a valid certificate is through Active Directory Certificate Services, which can issue certificates automatically to domain controllers. For non-Windows environments, you can use a certificate from a public CA or set up your own internal CA.
Self-signed certificates will work technically, but clients will show warnings or refuse to connect unless the certificate is explicitly added to their trust store. For production environments, a properly issued certificate from a trusted CA is strongly recommended.
Enabling LDAPS on Active Directory
Active Directory automatically supports LDAPS on port 636 once a valid certificate is installed on the domain controller. You do not need to enable it manually, as soon as the domain controller has a certificate that meets the requirements, it will start accepting LDAPS connections.
To verify that LDAPS is working on your domain controller, you can use the ldp.exe tool on Windows. Connect to the server on port 636 and select SSL. If the connection succeeds and you can browse the directory, LDAPS is working correctly.
Enabling LDAPS on OpenLDAP
For OpenLDAP, you need to configure the server to load your SSL certificate and private key. This is done in the slapd configuration, where you specify the paths to your certificate file, private key, and CA certificate.
Once the certificate is in place, you start the LDAP service with ldaps:/// as one of the listener URLs. By default this listens on port 636. You can then test the connection using ldapsearch with the -H ldaps://yourserver flag.
LDAPS and the Global Catalog
In Active Directory environments, the Global Catalog is a service that lets you search across all domains in a forest. It runs on its own ports: 3268 for standard LDAP and 3269 for LDAPS.
If your application needs to search the entire Active Directory forest, not just a single domain, you should connect to port 3269 instead of port 636. The connection works the same way as regular LDAPS, using SSL/TLS encryption, but the Global Catalog returns a broader set of results.
| Service | Standard Port | Secure Port |
|---|---|---|
| LDAP | 389 | 636 |
| Global Catalog | 3268 | 3269 |
Troubleshooting LDAPS
The most common issues with LDAPS relate to certificates. If a client cannot connect on port 636, the first thing to check is whether the certificate on the server is valid, not expired, and trusted by the client.
Certificate hostname mismatches are a frequent cause of connection failures. If the hostname your client uses to connect does not match the name on the certificate, the TLS handshake will fail. Make sure the certificate includes the correct hostname, and that your clients are connecting using that exact hostname rather than an IP address.
Firewall rules are the second most common issue. Port 636 needs to be open between your clients and your directory server. If you are also using the Global Catalog, port 3269 needs to be open as well.
If connections are failing and you are not sure why, enabling verbose logging on your LDAP client is usually the fastest way to see what is going wrong during the TLS handshake.
Conclusion
LDAPS is the secure version of LDAP, running on port 636 with SSL/TLS encryption from the start of every connection. If you are handling user authentication or directory queries over any network that is not fully trusted, LDAPS is the right choice over standard LDAP on port 389.
The main requirement is a valid SSL/TLS certificate on your directory server. Once that is in place, most modern directory servers and clients support LDAPS without significant additional configuration.
