Port 636 – LDAPS (LDAP over SSL)

Port 636 is the default port for LDAPS (LDAP over SSL/TLS) — the Lightweight Directory Access Protocol wrapped in TLS from the very first byte. Unlike cleartext LDAP on port 389, which starts in the clear and can be upgraded in place with StartTLS, LDAPS uses implicit TLS: the socket negotiates the encrypted channel before any directory data is exchanged. It’s the secure counterpart to 389, and every Active Directory domain controller and most OpenLDAP servers answer on 636 once a certificate is installed. Because the whole session is encrypted, LDAPS is the right answer for directory traffic — but it also means every query, bind, and enumeration that rides it is invisible to a WAF or IDS watching the wire.

Why It’s Open

LDAPS is where any organization that cares about encryption points its directory clients. Every Active Directory domain controller can serve LDAPS the moment a valid certificate lands in its store — Microsoft turns it on automatically — and enterprise apps, VPNs, storage arrays, and single sign-on systems bind over 636 so credentials never cross the network in the clear. Outside Windows you’ll find it on OpenLDAP (slapd) with TLS configured, on the 389 Directory Server, and on FreeIPA. Where port 636 answers, the rest of the domain controller is usually one scan away — check for Kerberos on port 88, cleartext LDAP on port 389, SMB on port 445, RPC on port 135, and the Global Catalog over SSL on port 3269. Note the split: 636 is domain LDAPS, while the forest-wide Global Catalog runs on 3268 (LDAP) and 3269 (LDAP over SSL).

Common Risks

• Encrypted enumeration once you have credentials. LDAPS protects the channel, not the directory. With any valid bind, every user, group, computer, OU, and BloodHound collection you’d run against port 389 runs identically over 636 — only now it’s inside TLS, so a WAF or IDS can’t see the queries. See port 389 for the full enumeration playbook; all of it applies here over an encrypted socket.
• Anonymous / null bind still leaks over TLS. Encryption is not authorization. If the directory allows an unauthenticated bind, an attacker who trusts the certificate still dumps the whole org structure over LDAPS — the padlock just hides it from the network.
• NTLM relay and the channel-binding question. When LDAP signing and channel binding aren’t enforced, an attacker can relay coerced NTLM authentication to a domain controller’s LDAP service and act as the victim (CVE-2017-8563). Hardening pushes clients toward signed LDAP or LDAPS — and LDAPS with channel binding (EPA) actually defeats the relay, which is exactly why the fix leans on 636.
• Certificate weaknesses on the listener. Self-signed, expired, or weak-key certificates on 636 mean clients that skip validation can be man-in-the-middled — the session is “encrypted” to an attacker’s certificate. This is the most common way LDAPS becomes encryption theater.
• Weak TLS protocols and ciphers. SSLv3/TLS 1.0, RC4, or export ciphers on the LDAPS listener open the door to downgrade and decryption attacks, and an unpatched OpenSSL behind 636 is exposed to TLS-layer bugs like Heartbleed.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service

nmap -sV -p 636 <target>

nmap labels the service ssl/ldap (often shown as ldapssl) and, with -sV, confirms TLS is wrapping a directory.

Inspect the certificate and TLS configuration

nmap -p 636 --script ssl-cert,ssl-enum-ciphers <target>

openssl s_client -connect <target>:636 -showcerts

sslscan <target>:636
testssl.sh <target>:636

ssl-cert dumps the certificate subject, issuer, and validity; ssl-enum-ciphers grades every protocol and cipher the listener accepts. openssl s_client, sslscan, and testssl.sh confirm self-signed/expired certs and weak SSLv3/TLS 1.0/RC4 support.

Bind and enumerate over LDAPS

# RootDSE over implicit TLS; LDAPTLS_REQCERT=never ignores an untrusted cert
LDAPTLS_REQCERT=never ldapsearch -H ldaps://<target> -x -s base namingContexts

# Dump the directory over the encrypted channel if a bind is allowed
LDAPTLS_REQCERT=never ldapsearch -H ldaps://<target> -x -b "dc=example,dc=com"

# Authenticated AD enumeration over 636 with windapsearch
windapsearch.py --dc-ip <target> --secure -u 'DOMAIN\user' -p 'Password123' -U

NetExec over the LDAPS port

nxc ldap <target> --port 636 -u user -p 'Password123' --users --groups
nxc ldap <target> --port 636 -u user -p 'Password123' --bloodhound -c all --dns-server <target>

Metasploit modules (SSL enabled)

msfconsole -q
use auxiliary/gather/ldap_query
set RHOSTS <target>
set RPORT 636
set SSL true
run

use auxiliary/scanner/ldap/ldap_login    # test binds over TLS
set RHOSTS <target>
set RPORT 636
set SSL true
run

Log every weak certificate, accepted anonymous bind, and enumeration result you confirm so it lands in the final pentest report instead of a scratch file.

What to Look For

Known CVEs and Exploits

• CVE-2017-8563 — Windows LDAP elevation of privilege (CVSS 8.1). When Kerberos falls back to NTLM and LDAP signing isn’t enforced, an attacker who relays that NTLM authentication to a domain controller’s LDAP service acts with the victim’s privileges — the canonical “NTLM relay to LDAP” path to domain admin. Microsoft’s fix added the LdapEnforceChannelBinding setting, and the 2020 hardening (ADV190023) moved to enforce LDAP signing and channel binding by default. This is the flaw that makes LDAPS with channel binding the mitigation, not the target — affects Windows 7 SP1 through Server 2016.
• CVE-2014-0160 — “Heartbleed” in OpenSSL 1.0.1 before 1.0.1g (CVSS 7.5). A crafted TLS heartbeat triggers a buffer over-read that leaks process memory — private keys, session data, credentials — from any TLS service running the vulnerable OpenSSL, including an LDAPS listener on 636. It’s a flaw in the TLS layer itself, not in LDAP, which is why a directory server that terminates TLS with unpatched OpenSSL is exposed. Proof-of-concept archived on Exploit-DB 32745.
• CVE-2015-3276 — OpenLDAP cipher-string parsing (CVSS 7.5). The nss_parse_ciphers function in libraries/libldap/tls_m.c mishandles multi-keyword cipher strings, so an OpenLDAP client or server can negotiate weaker ciphers than the administrator configured — silently downgrading the protection LDAPS is supposed to provide. Fixed in the OpenLDAP 2.5 line.

Mitigation

• Require LDAP signing and channel binding; disable unsigned LDAP. On domain controllers, enforce signing and set channel binding to required (ADV190023) so NTLM relay to LDAP fails and clients are pushed to sealed LDAP or LDAPS. This is the single most important AD hardening around 389/636.
• Use valid, CA-issued certificates. Never rely on self-signed or expired certs on 636, and configure clients to validate the certificate — disabling validation (LDAPTLS_REQCERT never) in production hands an attacker a MITM.
• Enforce TLS 1.2+ with strong ciphers. Disable SSLv3, TLS 1.0/1.1, RC4, and export ciphers on the LDAPS listener; confirm with ssl-enum-ciphers or testssl.sh.
• Restrict port 636 to management and DC-to-DC traffic. A domain controller should never answer LDAPS from the internet or arbitrary user subnets — firewall it to trusted ranges.
• Disable anonymous and null binds. Encryption doesn’t stop an unauthenticated dump; require authentication for directory reads.
• Patch OpenSSL, OpenLDAP, and Windows. Keep the TLS stack current to close Heartbleed-class bugs and cipher-downgrade flaws, and move OpenLDAP to a maintained 2.5+ release.

Real-World Example

The most common LDAPS failure isn’t a broken cipher — it’s encryption theater. An organization is told to “turn on LDAPS,” so an admin generates a self-signed certificate, opens 636 on the domain controllers, and points the applications at ldaps://dc.corp.local. To make the connection succeed without deploying the cert to every client, they set the LDAP client library to skip certificate validation (LDAPTLS_REQCERT never, or the equivalent “ignore certificate errors” checkbox). Now the session is encrypted — but to any certificate, because nothing is verified. An attacker on the internal path stands up their own LDAPS listener, presents a certificate the client accepts blindly, and reads or rewrites every bind that flows through: usernames, passwords on simple binds, and directory writes. The padlock is real and the traffic is unreadable to a passive sniffer, yet the directory is fully exposed to an active man-in-the-middle. It’s the clearest reminder that LDAPS only protects you when the certificate is trusted and validated — turning on 636 is step one, not the whole job. Pair it with enforced LDAP signing and channel binding (ADV190023) so a relayed or MITM’d session is rejected rather than trusted.

FAQ

What port does LDAPS use?

LDAPS uses port 636 by default — LDAP wrapped in SSL/TLS from the first byte (implicit TLS). Standard LDAP uses port 389, which is cleartext by default or upgraded in place with StartTLS. Active Directory also exposes the Global Catalog on 3268 (LDAP) and 3269 (LDAP over SSL) for forest-wide searches.

What is the difference between port 389 and port 636?

Port 389 is standard LDAP: the session starts in cleartext and can be upgraded to TLS in place with StartTLS. Port 636 is LDAPS: the session is wrapped in TLS from the start (implicit TLS), so credentials and queries are never exposed on the wire. If you need encryption end to end, use LDAPS on 636 — a simple bind on 389 without StartTLS sends the password in the clear.

Is port 636 TCP or UDP?

TCP. LDAPS binds, searches, and directory operations all run over TCP 636. There’s no standard UDP equivalent for LDAP over SSL — the connectionless CLDAP variant lives on UDP 389, not on 636.

What is port 636 used for?

Port 636 carries LDAPS — encrypted directory lookups and authentication against Active Directory domain controllers, OpenLDAP, and other directory servers. Clients bind over TLS and query for users, groups, computers, and organizational units, or authenticate a login, without any of it crossing the network in the clear.

Is LDAPS on port 636 secure, and can it be exploited?

LDAPS is the secure option, but the port itself isn’t a guarantee. It’s only as strong as its certificate and cipher configuration: a self-signed cert that clients don’t validate can be man-in-the-middled, weak protocols invite downgrade attacks, and an unpatched OpenSSL is exposed to bugs like Heartbleed. Encryption also doesn’t stop an anonymous bind or authenticated enumeration — those run fine over 636, just hidden inside TLS. Treat a reachable 636 as a directory to enumerate and a TLS listener to test.

TL;DR

• Service: LDAPS (LDAP over SSL/TLS) — encrypted directory access over implicit TLS
• Default port: 636 TCP (cleartext variant: LDAP on 389; Global Catalog over SSL on 3269)
• Biggest risk: certificate/cipher weaknesses that enable MITM, plus anonymous-bind and authenticated enumeration hidden inside TLS
• Mitigation: enforce LDAP signing + channel binding, deploy valid CA-issued certs with client validation, require TLS 1.2+, restrict 636 to management ranges, and patch the TLS stack