Is port 389 (LDAP) exposed to the internet, and is anonymous bind on?
Port 389 is the default port for LDAP, the protocol most directory services — including Active Directory — use to look up users, groups and other objects. LDAP supports an unauthenticated "anonymous bind," and on a plain (non-TLS) connection, even an authenticated bind sends the username and password in clear text, so an internet-reachable port 389 is rarely something you want by design.
By AdminKit team, Netbase JSC · Updated October 24, 2026
Why port 389 shouldn’t normally face the internet
IANA registers port 389 for LDAP, the Lightweight Directory Access Protocol that Active Directory and most other directory services use for lookups and authentication. RFC 4511, the protocol specification, defines several bind mechanisms, including an anonymous bind that requires no credential at all, and a simple bind that — on a plain, non-TLS connection — transmits the bind DN and password in clear text. Both are legitimate protocol features for an internal, trusted network; neither is something you want answering requests from the open internet.
What an exposed, misconfigured port 389 actually gives away
If anonymous bind is enabled on a reachable server, anyone who connects can typically enumerate the entire directory: usernames, group memberships, organizational units, and any descriptive attributes administrators have populated — sometimes including credentials or hints that were never meant to be queryable without authentication. On a plain (non-TLS) simple bind, credentials pass across the wire unencrypted, so anyone positioned to observe the traffic path can recover a working login. Microsoft’s own guidance on LDAP signing and LDAP channel binding exists specifically to close the follow-on risk: an unsigned LDAP session can also be relayed by an attacker positioned on the network path, turning a single intercepted or relayed bind into broader access across the domain.
How to check your own exposure
AdminKit’s planned open ports check is designed to test whether port 389 and other commonly-exposed management ports on your own public IP respond from outside your network. A directory server can be fully patched and still be reachable on 389 from outside simply because of a firewall rule or port-forward nobody remembers adding — worth confirming directly rather than assuming the perimeter is closed.
How to fix it
- Block port 389 at your perimeter firewall so directory lookups are only reachable from your internal network or over a VPN — a directory service almost never needs to answer LDAP queries from the public internet directly.
- Disable anonymous bind on the directory server unless a specific, reviewed application genuinely requires it.
- Require LDAPS (port 636) or StartTLS for any bind, so credentials and query results aren’t sent in clear text even on paths you do trust.
- On Active Directory, enable LDAP signing and channel binding enforcement so unsigned or unprotected binds are rejected outright, closing the relay risk Microsoft’s guidance describes.
Defensive use only
Every check this page links to is for assets you own or are explicitly authorized to test. Never scan, probe, or attempt to connect to a network or device you don’t control — AdminKit’s active checks only ever run against the IP making the request or an asset you’ve verified ownership of. See our Disclaimer and Acceptable Use Policy for the full terms.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
Is LDAP itself insecure, or only specific configurations?
The protocol itself, as defined in RFC 4511, supports an anonymous (unauthenticated) bind and a simple bind that sends credentials in clear text unless the session is wrapped in TLS or StartTLS. Neither is a bug — they're options the protocol allows — but either one reachable from the public internet turns a normal administrative feature into an open door.
Why would anonymous bind be enabled in the first place?
It's sometimes turned on deliberately to simplify directory lookups for legacy applications that don't support authenticated binds, or it's left over from a default or test configuration that was never locked down before the server became reachable from outside the network.
What has Microsoft done about this on Active Directory specifically?
Microsoft has been pushing Active Directory domain controllers toward requiring LDAP signing and channel binding by default, specifically to stop unsigned, unencrypted LDAP binds from being accepted at all — a direct response to the cleartext-credential and relay risks that an unsigned port 389 session carries.
What's the fastest fix if I find my own directory server's port 389 open to the internet?
Block port 389 at the perimeter firewall so it's only reachable from your internal network or a VPN, disable anonymous bind on the directory server if it's enabled, and require LDAPS (port 636) or StartTLS for any bind that does need to cross an untrusted network.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.