Port 636 (LDAPS): What It Is and How to Secure It

Written by Ruben Selby, founder and penetration tester at Wolfcore. Last reviewed 8 November 2026.

In one sentence: Port 636 is the door that a staff directory uses when it talks over an encrypted connection, and it is the safer sibling of plain LDAP on port 389.

Part of our Ports and protocols library.

What runs on this port

LDAP is the language computers use to ask a directory “who is this user and what are they allowed to do?”. In most offices that directory is Microsoft Active Directory. Microsoft Learn explains that LDAP traffic is sent unencrypted over port 389 by default, while LDAPS sets up an encrypted TLS tunnel over port 636 (or port 3269 for global catalog traffic). That protects sign-in details and directory queries from being read on the network.

Typical users of port 636 are domain controllers, VPN gateways, Wi-Fi sign-in servers, printers, HR and finance software, and anything else that checks passwords against the directory. For the unencrypted version, see port-389-ldap.

Why attackers look for it

A directory holds every account name, group and password check in the business. Any service that is reachable from the internet can be found by scanning, so a directory port open to the world is easy to spot. Inside a network, an attacker who already controls one machine will look for the directory because it shows where the valuable accounts are.

How it gets attacked

Encryption on port 636 is good, but it is not the whole job. The common weaknesses are:

Port 389 left open next to it. Microsoft’s own scenario table says that on port 389 with a simple bind, credentials travel in plain text.
Relayed sign-ins. Microsoft says TLS alone encrypts the transport and authenticates the server, but it does not bind the inner authentication to the specific TLS session. Without channel binding, an attacker can end the client’s TLS session, open a separate one to the domain controller and relay the NTLM sign-in data. NTLM is an older Windows sign-in method.
Bad certificates. The certificate has to name the domain controller and be trusted by clients. Expired or self-signed certificates teach staff to click through warnings or to switch encryption off.
Simple binds. A simple bind sends a username and password to the server. Microsoft notes that LDAP signing and channel binding do not protect simple binds, so they depend entirely on TLS.

The advisory behind the hardening settings is Microsoft ADV190023. Microsoft’s channel binding page describes it as phased enforcement, with different defaults by Windows Server version: Windows Server 2022 or earlier has channel binding set to Never, while new Windows Server 2025 deployments default to When supported.

Who it affects and how badly

Sole trader to 10 staff: usually no local directory, so low exposure. Cloud sign-in matters more.
10 to 50 staff (accountancy, legal, recruitment, trades): one or two domain controllers and several apps tied to them. Realistic worst case: a stolen directory account leads to the file server and email, and the office loses a day or more while accounts are reset.
50 to 250 and 250 plus (schools, care providers, manufacturing, councils, fintech and insurance, MSPs): many apps and old devices that only speak plain LDAP. Realistic worst case: an attacker with directory access reaches most systems, which can mean downtime, data loss and a reportable personal data breach.

The technical risk is the same in the UK, EU, US and Armenia. Only the regulator who asks the questions afterwards changes.

What we check on a test

This is method, not a list of findings.

Whether directory ports answer from the internet, or from a normal staff network position.
Whether port 389 still accepts simple binds.
Whether the LDAPS certificate is trusted, in date and matches the server name. Microsoft requires Server Authentication and the domain controller’s FQDN.
Whether signing and channel binding are enforced, or only requested.
Which service accounts bind to the directory, and how strong their passwords are.

The UK angle

The ICO says the UK GDPR requires appropriate technical and organisational measures to process personal information securely, and lists encryption as an example. Its guide to data security says you must regularly test and evaluate your measures, and names vulnerability scanning and penetration testing as ways to do it. It also points to Cyber Essentials as a good starting point. The ICO does not name port 636, but directory traffic carries staff personal data and passwords, so unencrypted LDAP is hard to defend.

How the traffic flows

Worked example (an illustration, not a real client)

A 30-person accountancy firm has one domain controller. Its practice software was set up years ago to check passwords over port 389. Nobody notices because it works. A contractor’s laptop carrying malware joins the office Wi-Fi and watches the network, and the practice software’s sign-ins are readable. The firm then spends days on password resets and has to decide whether client data was touched. The fix is an afternoon of work: install a proper certificate, point the software at port 636, then require signing and channel binding once the logs show nothing still uses the old route.

How to check whether yours is exposed

Safe checks only, on systems you own:

Look at your firewall rules for inbound 389, 636, 3268 and 3269 from the internet. There should be none you cannot explain.
Compare your asset list with what answers on those ports inside the network. Printers and scanners are the usual surprises.
On a domain controller, open ldp.exe, choose Connection then Connect, enter port 636 and tick SSL. Microsoft says RootDSE information appears when LDAPS works.
Run the free scan at https://wolfcore.co.uk/free-web-vulnerability-scan/ to see what is visible from outside.

How to secure it

Block ports 389, 636, 3268 and 3269 from the internet at the firewall. This is Wolfcore’s advice, not a quote from Microsoft.
Move every app and device to port 636, then stop accepting simple binds over port 389.
Install a certificate from an authority your clients trust, with Server Authentication and the server name, as Microsoft’s article describes.
Set the policy Domain controller: LDAP server channel binding token requirements to When supported, then to Always once clients are ready.
Watch the Directory Service log for events 3039, 3074 and 3075 before you enforce. Microsoft says 3075 records the client IP, identity and whether the client supports channel binding.
Use Kerberos rather than NTLM where you can.
Renew certificates before they expire and put the date in a calendar.

Frequently asked questions

What is the difference between port 389 and port 636? By default LDAP traffic on port 389 is unencrypted, while port 636 wraps it in a TLS tunnel.

Does LDAPS stop sign-in relay by itself? No. Without channel binding, the domain controller cannot tell a relayed sign-in from a real one.

Which events show clients that do not use channel binding? Events 3039, 3074 and 3075 in the Directory Service log, once channel binding is set to When supported or Always.

Back to the Ports and protocols hub.

Sources

How Wolfcore helps

A Wolfcore penetration test finds this the way an attacker would, by hand, not with a scanner. Start with the free web vulnerability scan at https://wolfcore.co.uk/free-web-vulnerability-scan/ and read about penetration testing at https://wolfcore.co.uk/services/penetration-testing/.

Port 636 (LDAPS): what it is, how it is attacked and how to secure it