Port 389 (LDAP): How It Is Attacked and Secured

Written by Ruben Selby, Founder and Lead Security Consultant, Wolfcore. Last reviewed 7 November 2026.

In one sentence: Port 389 is the door that Windows computers, apps and devices use to ask your company directory, Active Directory, who a user is and whether their password is right.

Part of our Ports and protocols library.

What runs on port 389

LDAP stands for Lightweight Directory Access Protocol. Microsoft’s documentation describes it as the way clients authenticate users and retrieve directory information in Active Directory. Port 389 is the standard port. Port 636 carries LDAP over TLS (LDAPS). Port 389 can also be upgraded to TLS using STARTTLS.

You will find it on domain controllers, and on anything that uses the directory to sign people in: VPNs, Wi-Fi controllers, printers, file servers and business apps. A “bind” is the sign-in step. A “simple bind” sends a username and password. A “SASL bind” uses integrated sign-in such as Kerberos or NTLM.

Why attackers look for it

Internet-wide scanning and device search engines list services that answer on well-known ports. A directory service answering from the internet tells an attacker where your identity system lives. Inside a network, an attacker who has one foothold looks for LDAP because it holds the list of users, groups and administrators.

Port 389 should be reachable only from the machines that need it, not the internet. The Cyber Essentials Plus test (see below) scans your internet-facing addresses and reviews every service it finds.

How it gets attacked

The risks come from configuration, not from LDAP being broken.

Unsigned binds accepted. Microsoft says Windows Server 2022 or earlier does not enforce LDAP signing by default. Domain controllers accept both signed and unsigned binds. Unsigned traffic means someone on the network can modify packets in transit, tamper with answers or inject messages that alter directory objects.
Cleartext simple binds. A simple bind on port 389 without TLS sends credentials with no protection. Microsoft’s own comparison table shows no confidentiality, no integrity and no relay protection for this case.
Credential relay. On Windows Server 2022 or earlier, Microsoft says the channel binding policy defaults to Never. An attacker can intercept a client’s sign-in data and forward it to the domain controller over a separate connection, because that sign-in method does not tie itself to one connection. Microsoft’s advisory for this class of problem is ADV190023.
LDAPS without channel binding. TLS alone does not close the relay gap. Microsoft states that LDAPS with SASL and no channel binding is vulnerable to NTLM relay.

The defaults are better on new builds. Microsoft says Windows Server 2025 requires LDAP signing by default for new deployments and sets channel binding to When supported. Upgraded domains keep their old settings.

Who it affects and how badly

Any organisation with Active Directory, which is most offices with a Windows server: accountancy and legal practices, schools, care providers, manufacturers, councils and MSPs managing many client domains, in the UK, EU, US and Armenia alike.

Sole trader to 10 staff: usually cloud sign-in only. Port 389 matters if there is an office server or a NAS using directory sign-in.
10 to 50 and 50 to 250: one weak legacy device or app can force the whole domain to accept unsigned binds. Worst case: an attacker with a foothold escalates to domain administrator, and everything is down while you rebuild.
Regulated and 250 plus: same technical worst case, plus a personal data breach to report to the ICO or an EU authority, and lost clients.

How to check whether yours is exposed

Safe checks, using your own systems only:

Look at your firewall’s inbound rules for ports 389 and 636. There should be no rule from the internet to a domain controller.
Check your asset list for every device that uses the directory: printers, VPNs, scanners, apps.
On domain controllers, open Event Viewer, then Applications and Services Logs, then Directory Service. Microsoft says event 2886, logged at startup, warns the controller does not reject unsigned binds or cleartext simple binds. Event 2887 is a 24-hour summary of the unsigned binds it allowed.
For per-client detail, set the “16 LDAP Interface Events” diagnostic level to 2. Event 2889 then records the IP address and identity of each client making an unsigned or cleartext bind. Switch it off after investigating, as Microsoft warns of a performance impact.
For channel binding, events 3039 to 3041 and 3074 to 3075 report clients that fail or would fail. They appear when the policy is When supported or Always.
Run the free scan on your public addresses to confirm nothing answers on these ports.

The UK angle

Cyber Essentials Plus includes a remote scan of every internet-facing address. The NCSC test specification says it tests whether an internet-based opportunist attacker can break in with typical low-skill methods. Each service found goes through a flow chart. A service with a vulnerability scoring 7.0 or more fails. A service that needs a login but has no multi-factor authentication fails if default passwords have not been changed, or if logins are neither throttled nor locked out after at most 10 failed attempts. A directory port open to the internet is a poor start. See cyber-essentials-plus.

What we check on a test

A general description of our method, not a client finding.

Whether ports 389 and 636 answer, from outside and from a normal staff network.
Whether the domain controller accepts unsigned or cleartext binds, and what the signing and channel binding policies are set to.
Whether legacy apps and devices bind in cleartext.
Whether NTLM is still allowed, since it is what relay attacks depend on.
What a normal user account can read from the directory.
Directory accounts used by apps, and whether they have more rights than needed.

How to secure it

Block port 389 and 636 from the internet at the firewall. Allow only the servers and devices that need them.
Audit first with events 2887, 2889 and 3075. Find and fix the clients that bind unsigned or without a channel binding token.
Set “Domain controller: LDAP server signing requirements” to Require signing, once the audit is clean. Microsoft’s migration path is to monitor, fix clients, then require.
Set “Domain controller: LDAP server channel binding token requirements” to When supported, then Always.
Use TLS for simple binds, since signing does not protect them. Microsoft recommends SASL with Kerberos where possible, and says NTLM and Digest are deprecated.
Replace or isolate any device that cannot support signing, as Microsoft suggests.
Keep domain controllers patched. See patch-management.

FAQ

Should port 389 be open to the internet? Our sources give no reason to expose it. Cyber Essentials Plus scans internet-facing services and reviews them one by one.

Does LDAPS fix everything? No. Microsoft says TLS alone does not stop credential relay, and simple binds rely on TLS alone for protection. Channel binding closes the gap for SASL sign-ins.

Will enforcing signing break things? It can, for older devices. That is why Microsoft advises monitoring events 2887 and 2889 and fixing clients before you require signing.

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/ or see https://wolfcore.co.uk/services/penetration-testing/.