Port 636 – LDAPS

TCP

Port 636 is the LDAPS port – LDAP encrypted with TLS from the start of the connection (implicit TLS). Unlike STARTTLS on port 389 which upgrades an existing connection, port 636 requires TLS before any LDAP operations. Use port 636 for all cross-network directory queries where plaintext credentials are unacceptable.

Port Number

636

Protocol

TCP

Service

LDAP over TLS/SSL

Range

IANA Well-Known (0–1023)

Description

LDAPS on port 636 wraps the entire LDAP session in TLS encryption from the first byte. This differs from STARTTLS on port 389, which starts in cleartext and upgrades. The implicit TLS approach on port 636 prevents protocol downgrade attacks that can strip STARTTLS. Active Directory domain controllers listen on both 389 (LDAP) and 636 (LDAPS). For LDAPS to function, the DC needs a valid certificate – either from the domain's Enterprise CA or a third-party CA. Self-signed certificates cause connection failures unless clients explicitly trust them. Test with: openssl s_client -connect dc:636

Security risks

1Certificate validation bypass: many LDAP clients disable certificate verification (e.g., ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER)) to avoid SSL errors, making MITM trivial
2Expired or self-signed certificates: domain controllers with expired LDAPS certs still serve connections – clients configured to ignore errors send credentials to potentially impersonated DCs
3LDAP channel binding not enforced: without EPA (Extended Protection for Authentication), LDAPS connections are vulnerable to NTLM relay attacks even over TLS
4Weak TLS configurations: older domain controllers may offer TLS 1.0/1.1 and weak cipher suites (RC4, DES) on port 636 – downgrade attacks remain possible
5Certificate private key exposure: AD LDAPS uses the domain controller's machine certificate. If the DC is compromised, the LDAPS cert's private key enables decryption of captured LDAPS traffic

Firewall guidance

Port 636 should be accessible from all domain-joined machines and applications performing LDAP authentication. Prefer 636 over 389 for all LDAP traffic. Microsoft is mandating LDAP signing and channel binding in future Windows Server updates – prepare now. For internet-facing apps needing AD auth: use Azure AD/Entra ID federation, not direct LDAPS exposure.

Diagnosis commands

Check LDAPS certificate validity and subject

shell

openssl s_client -connect dc.example.com:636 -showcerts 2>/dev/null | openssl x509 -noout -dates -subject

Test LDAPS bind with user credentials

shell

ldapsearch -H ldaps://dc.example.com -x -b 'dc=example,dc=com' -D '[email protected]' -W '(samAccountName=admin)'

Check TLS version and cipher suite in use

shell

echo | openssl s_client -connect dc:636 2>/dev/null | grep 'Protocol\|Cipher'

PowerShell: verify LDAPS port is reachable from client

shell

Test-NetConnection dc.example.com -Port 636

Usage examples

Port 636 – LDAPS

shell

ldapsearch -H ldaps://dc.example.com:636 -b 'dc=example,dc=com'
openssl s_client -connect dc.example.com:636
LDAPTLS_REQCERT=allow ldapsearch -H ldaps://host

Common services on this port

Active Directory Domain ServicesOpenLDAP (slapd)389 Directory ServerFreeIPAAzure AD Connect

Related ports

389

LDAP (plaintext/STARTTLS)

636

LDAPS (this port, implicit TLS)

3268

Global Catalog

3269

Global Catalog over SSL

History

LDAPS was introduced alongside LDAPv3 (RFC 4511) as a way to encrypt LDAP communications. Port 636 was registered for LDAP over implicit TLS. Unlike STARTTLS on port 389 (which upgrades mid-connection), LDAPS establishes TLS from the first byte – similar to HTTPS vs HTTP. Microsoft has been pushing LDAPS adoption aggressively: Windows Server 2025 plans to disable unsigned LDAP binds by default, forcing all clients to use either LDAPS (636) or LDAP+signing (389).

FAQ

LDAPS (636) vs LDAP+STARTTLS (389) – which is more secure?

LDAPS (636) is marginally more secure in practice: TLS from first byte means no downgrade attack window. STARTTLS (389) starts plaintext then upgrades – a MITM can strip the STARTTLS command (if client doesn't enforce). However, both are secure when properly configured. Microsoft recommends LDAPS for simplicity. The real security gap is clients that disable certificate validation – fix that regardless of port.

How do I enable LDAPS on Active Directory?

AD automatically enables LDAPS when the DC has a valid certificate with Server Authentication EKU. Options: (1) Enterprise CA: auto-enrolled via Certificate Services. (2) Third-party CA: request cert with DC's FQDN as SAN, import to Local Computer\Personal store. (3) Verify: ldp.exe → Connection → connect to DC:636 with SSL. Common failure: cert missing the DC's FQDN in SAN field, or cert in wrong store (User instead of Computer).

Specification

RFC 4513 – Port 636 specification →