Port reference
Port 636 (TCP) – LDAPS (LDAP over TLS)
LDAPS — LDAP directory queries wrapped in TLS for confidentiality and integrity.
Default state
Open on domain controllers that have a server certificate installed (often via AD CS). Should be the preferred directory channel over cleartext 389.
Common attacks
- Directory enumeration over an authenticated channel
- Weak/expired TLS and certificate validation flaws
- Anonymous or unauthenticated bind (if permitted)
- Credential abuse against directory ACLs
Hardening
- Require LDAPS and disable cleartext LDAP simple binds where feasible
- Use strong TLS (1.2+), valid certificates, and disable legacy ciphers
- Enforce LDAP channel binding and signing
- Disable anonymous binds and apply least-privilege directory ACLs
- Restrict 636 to trusted management networks
nmap snippet
nmap -p636 --script ssl-cert,ssl-enum-ciphers,ldap-rootdse <target>Replace <target> with the host or range you're authorized to scan.
What runs on port 636?
Port 636 is the default for LDAPS — LDAP over TLS. It carries the same directory queries and modifications as plain LDAP, but wrapped in a TLS session so credentials and results are encrypted in transit. In Active Directory it is served by domain controllers that have a suitable server certificate (commonly issued by AD CS) and is the recommended channel for any sensitive directory operation, including password changes.
Why it matters for security
LDAPS fixes LDAP's biggest weakness — cleartext exposure of simple-bind passwords and directory data — and is required to defeat LDAP relay when combined with channel binding. But TLS only protects the transport. A directory that allows anonymous binds or grants broad read access still leaks its structure, and weak or expired certificates and legacy cipher suites can undermine the encryption itself or enable downgrade and interception.
How it's attacked
Even over TLS, an attacker with any valid (or anonymous) bind can enumerate users, groups, SPNs, and ACLs just as on port 389. Scanners check 636 for weak TLS versions, bad ciphers, and certificate validation problems that allow interception. Where channel binding is not enforced, relay scenarios may still succeed, and over-permissive directory ACLs enable privilege escalation.
Hardening checklist
Require LDAPS and phase out cleartext simple binds. Serve only TLS 1.2+ with valid certificates and disable legacy ciphers. Enforce LDAP channel binding and signing to stop relay. Disable anonymous binds and tighten directory ACLs to least privilege. Restrict 636 to trusted management networks. The nmap scripts above inspect the certificate and cipher suites on systems you are authorized to test.
Related ports
Frequently asked questions
- What is the difference between LDAP (389) and LDAPS (636)?
- LDAP on 389 is cleartext; LDAPS on 636 wraps the same protocol in TLS, encrypting credentials and directory data in transit. LDAPS is the secure choice.
- Does LDAPS prevent LDAP enumeration?
- No. TLS protects confidentiality, but an authenticated (or anonymously bound) attacker can still enumerate the directory. Combine LDAPS with channel binding and ACL hardening.