LDAPS and TLS introduced the two ways to encrypt an LDAP connection. This page compares them directly so you can pick the right one.
| Plain LDAP | LDAPS | STARTTLS | |
|---|---|---|---|
| Port | 389 | 636 | 389 |
| Encryption | None | From the first byte | Negotiated mid-connection |
| Standardized | RFC 4511 | Not formally standardized | RFC 4513 |
| Safe for real credentials | No | Yes | Yes |
LDAPS is the simpler option operationally — there's no extra negotiation step, and it's straightforward to reason about ("this port is always encrypted"). It's a good default when the server supports it, which essentially all modern directories (including Active Directory) do.
ldaps://dc1.example.com:636
STARTTLS is preferable when you need to support clients or firewalls that expect a single, standard LDAP port (389) and negotiate encryption within it, or when your organization's tooling and monitoring already assumes plain port 389 for connectivity checks. See STARTTLS for the client-side implementation.
Plain, unencrypted LDAP on port 389 with no STARTTLS upgrade sends simple bind passwords in cleartext. It's only acceptable for:
- Fully anonymous, read-only operations where nothing sensitive is transmitted.
- Isolated test environments that never see real credentials.
Danger
If you see application code binding with a real password against a bare ldap:// URL with no TLS negotiation, treat it as a security bug, not a style choice.
If your directory or client library specifically requires STARTTLS, continue to STARTTLS for the details.