PORTImplicit TLSIANA assigned
Port 636LDAPS (LDAP over TLS)
Port 636 is the standard TCP port for LDAPS: LDAP wrapped in TLS from the start of the connection. Active Directory listens on it once a domain controller has a suitable server certificate. Applications that bind with a username and password should use 636 rather than plain LDAP on 389.
What port 636 is used for
LDAPS is LDAP inside TLS. An application connects to port 636, verifies the server certificate, and then performs its bind and searches over the encrypted channel. It is the right choice for any application that authenticates users with a simple bind, because the password would otherwise cross the network in clear text.
Uses include VPN and Wi-Fi authentication back ends, SaaS directory connectors, Linux hosts joined to AD through SSSD, and web applications with an "LDAP login" option.
LDAPS versus StartTLS
Both produce a TLS-protected LDAP session. LDAPS on 636 is simpler to reason about and to firewall; StartTLS on 389 keeps a single port. Active Directory supports both; many third-party applications support only one, so check the documentation.
Enabling LDAPS on a domain controller
- Issue a certificate to the DC with its fully qualified name and the Server Authentication EKU, from your enterprise CA (auto-enrolment handles this with the Kerberos Authentication or Domain Controller templates) or an external CA.
- Ensure the certificate is in the local computer's Personal store (or the NTDS service store for explicit selection).
- Restart the DC or wait; the Active Directory service picks up the certificate and starts listening on 636 and 3269.
Security considerations
- Validate the certificate in every client. A client that ignores certificate errors can be redirected to a rogue server that harvests credentials.
- Keep a service account with minimal rights for application binds.
- Do not expose 636 to the internet any more than 389; TLS protects the transport, not the directory from enumeration.
How to check port 636
Is something listening locally? On Windows, open Command Prompt and run:
netstat -ano | findstr :636A line in the LISTENING state means a local program has bound port 636; the last column is its process ID (PID). Match the PID in Task Manager (Details tab) or with tasklist /fi "PID eq <pid>". On Linux or macOS the equivalent is ss -tulnp | grep :636 or lsof -i :636.
Can you reach it on a remote host? PowerShell's built-in connection test attempts a TCP handshake:
Test-NetConnection dc01.corp.example -Port 636TcpTestSucceeded : True means the remote system accepted a TCP connection on port 636. False means the port is closed, filtered by a firewall, or the host is unreachable; the output's ping result helps tell those apart.
See the netstat and Test-NetConnection records for the full option sets.
Test with the built-in LDP tool (ldp.exe, part of RSAT): Connection → Connect, enter the DC name, port 636, tick SSL. A successful connection shows the RootDSE attributes; a failure shows the TLS error.
Firewall considerations
Domain controllers need inbound TCP 636 (and 3269) from the application servers and clients that use LDAPS. Nothing else needs an inbound rule.
On Windows, inbound rules live in Windows Defender Firewall with Advanced Security (wf.msc). A rule allowing port 636 only takes effect on the profile (Domain, Private, Public) it is assigned to. The command-line equivalent is netsh advfirewall firewall add rule; see the netsh record.
Frequently asked questions
Why does my domain controller not listen on 636?
LDAPS activates only when the DC has a certificate it can use: issued by an enterprise CA or imported into the NTDS certificate store, with the DC's FQDN in the subject or SAN and the Server Authentication purpose. Without one, 636 stays closed.
Which certificate does the application need to trust?
The issuing CA of the domain controller's certificate. Internal CAs are fine as long as the application host trusts the root. Disabling certificate validation to make LDAPS "work" removes most of its value.