What is LDAPS?

LDAPS, or LDAP over SSL/TLS, is the encrypted version of the Lightweight Directory Access Protocol (LDAP), the standard protocol that applications and services use to query and authenticate against directory services. Where plain LDAP transmits bind credentials and directory data in cleartext over the network, LDAPS wraps that same traffic inside a TLS session, protecting it from interception and tampering the moment the connection is opened.

By default, LDAPS operates on TCP port 636 for standard domain controller (DC) queries and on TCP port 3269 when communicating with the Global Catalog in a multi-domain forest. No application-layer changes are needed to move from LDAP to LDAPS; the difference is entirely at the transport layer, which means that any tool or service that can speak LDAP can be pointed at port 636 once the DC has a valid certificate installed.

For IT administrators managing AD environments, LDAPS is not optional but a baseline security requirement. Microsoft's March 2020 LDAP hardening advisory made this explicit, along with a wide range of compliance frameworks, including PCI DSS, HIPAA, and NIST 800-53, that require encrypted transmission of authentication credentials. ADManager Plus, an AD management and reporting solution that offers user provisioning, delegation, and group management capabilities, uses LDAPS to ensure that every interaction is transmitted over an encrypted channel rather than in plaintext.

What is the difference between LDAP and LDAPS?

The difference between LDAP and LDAPS comes down to a single but consequential distinction: whether or not the traffic between the client and server is encrypted . Both protocols serve the same purpose such as querying, authenticating, and modifying entries in a directory service, but they do it with different security postures which has real consequences for any organization using AD for authentication.

Why LDAP is not secure

With LDAP, if you can observe the network segment between an LDAP client and a DC, you can read everything that passes over it, including the bind credentials. Tools can capture and display a cleartext LDAP simple bind in seconds, giving rise to well-documented man-in-the-middle attacks against LDAP without signing or encryption for over two decades.

Microsoft acknowledged this directly when it tightened the defaults in its March 2020 advisory, which began enforcing LDAP signing and channel binding requirements across Windows DCs. But signing alone only provides integrity protection; it does not encrypt credentials in transit, making LDAPS the more complete solution for both confidentiality and integrity. If your security strategy requires that credentials cannot be read on the wire, LDAPS is the only answer.

Before enforcing LDAPS, it is worth auditing your environment to identify which clients and applications are still connecting over LDAP. Windows DCs log unsigned or cleartext LDAP bind attempts as Event ID 2889 in the event log. Enabling diagnostic logging for LDAP Interface Events at Level 2 on each DC will display these events, giving you a list of source IP addresses and account names that are still using insecure binds. Remediating those connections before enforcing LDAPS prevents authentication failures when you move to requiring encrypted channels.

What port does LDAPS use?

LDAPS uses TCP port 636 for standard domain queries and TCP port 3269 for Global Catalog queries in multi-domain AD forests. These port numbers are well-established IANA assignments and have not changed. If you are configuring a firewall rule, application connection string, or network segment ACL, these are the ports you need to open for encrypted LDAP traffic.

A common point of confusion is whether port 636 uses UDP as well as TCP. Unlike port 389, which supports a connectionless LDAP variant over UDP for certain AD operations like DC discovery, LDAPS is strictly connection-oriented and operates over TCP only. When opening firewall rules for LDAPS, TCP/636 and TCP/3269 are the only ports required and UDP is not required.

How does LDAPS work?

At the protocol level, LDAPS works by wrapping LDAP inside a TLS session, meaning that the very first action that happens when a client connects to port 636 is a TLS handshake, not an LDAP operation. The TLS handshake is the mechanism by which the client and server negotiate the encryption algorithm they will use, exchange keys, and verify the server's identity through its certificate. Only after this handshake is completed and both sides have agreed on an encrypted channel does any LDAP traffic actually flow.

The sequence of events for an LDAPS connection is as follows:

1. The client opens a TCP connection to port 636 on the DC.

2. The server immediately presents its X.509 certificate.

3. The client checks the certificate's validity.

4. A symmetric session key is then derived using the negotiated cipher suite. From this point forward, every LDAP message, including the initial bind that carries the credentials, is encrypted inside that TLS session.

This is different from the STARTTLS mechanism, which is another way of adding TLS to LDAP.

LDAPS vs. STARTTLS

STARTTLS is an extension to the standard LDAP protocol that upgrades an existing connection on port 389 to an encrypted TLS session before any sensitive data is exchanged. Rather than opening a separate encrypted port like LDAPS, STARTTLS begins as a normal LDAP connection and then issues an upgrade command mid-session. Both methods encrypt LDAP traffic in transit, but the way they establish that encryption is fundamentally different. This distinction matters for firewall configuration, application compatibility, and security posture.

Manage the AD you just secured

If you manage AD at scale, securing LDAP traffic is only part of the equation. Provisioning users, delegating permissions, reviewing group memberships, and cleaning up stale accounts still demands significant effort when relying on native tools alone.

ADManager Plus is an AD management and reporting solution that lets IT administrators manage accounts in bulk, manage group memberships, generate over 200 built-in reports, and automate joiner-mover-leaver workflows, all through an intuitive interface that requires no direct access to ADUC or elevated domain privileges.

FAQs

1. What does LDAPS stand for?

LDAPS stands for Lightweight Directory Access Protocol over SSL/TLS. It reflects the fact that it is an LDAP layered over a TLS transport connection rather than a new protocol in its own right.

2. Is LDAP secure by default?

No, LDAP is not secure by default. Without additional configuration, specifically LDAP signing, LDAPS, or STARTTLS, LDAP transmits all traffic including bind credentials in cleartext, making it readable to anyone who can observe the network segment between the client and the directory server. Microsoft's 2020 LDAP hardening update raised the default signing requirements on DCs, but signing alone does not encrypt traffic. Because of this, LDAPS is required for confidentiality.

3. What is the difference between LDAP and LDAPS?

LDAP operates on port 389 and transmits directory queries and authentication data without encryption. LDAPS, on the other hand, operates on port 636 and wraps that same traffic in a TLS session, encrypting all data in transit including credentials. The application-layer protocol is identical, but the difference is entirely at the transport layer.

4. Why does LDAPS matter in cybersecurity?

In a cybersecurity context, LDAPS is significant because directory service authentication is one of the most sensitive attack surfaces in an enterprise network. AD credentials, if captured in transit, give an attacker the ability to escalate privileges, move laterally, and potentially compromise the entire domain. LDAPS addresses this by ensuring that LDAP bind operations and directory query responses cannot be read by anyone who intercepts the network traffic.

5. Does LDAPS require a certificate?

Yes, LDAPS requires a valid X.509 certificate installed in the Local Computer/Personal certificate store on the DC. The certificate must include the Server Authentication OID in its Enhanced Key Usage extension and must have the DC's FQDN in the Subject CN or a SAN DNS entry. Without this certificate, the AD LDAP service will not listen on port 636, and LDAPS connections will fail.