Ports

Port 389: LDAP

Directory lookups and authentication plumbing. Often tied to Active Directory.

Where you will see it: You will see this in scans, firewall rules, vulnerability reports, and service configs. Treat open ports as exposure points and verify the service is expected, hardened, and restricted.

What it is

Port 389 is used for LDAP, a directory protocol that many enterprise identity systems depend on. A port is a transport layer number used together with an IP address and a protocol such as TCP or UDP to direct traffic to the correct service on a host.

A server process binds a socket to a port and listens, while a client typically chooses an ephemeral source port for outbound connections. The combination of source and destination IP addresses, source and destination ports, and the transport protocol uniquely identifies a flow so the operating system can keep many conversations separate.

Firewalls, NAT, and scanners talk about ports because the destination port is the stable rendezvous point that exposes a service to the network. Directory servers listen on 389 so applications can bind, search for users and groups, and read attributes that drive authorization decisions.

Most LDAP traffic is over TCP because it involves request and response exchanges and can include larger payloads. UDP 389 also exists for CLDAP, a connectionless variant used in some discovery and lookup scenarios, which is why scans sometimes show both.

A typical real flow is: the client connects to port 389, performs a bind (often with a service account), runs searches using filters, and may upgrade to TLS with StartTLS before sending credentials if configured correctly. Security wise, an exposed directory port can leak your entire org structure and enable credential attacks, so environments usually restrict 389 to trusted application networks and require StartTLS or use LDAPS on 636.

How it works in broad strokes

  1. Client connects and performs a bind operation to authenticate or to establish an anonymous session if allowed.
  2. Client performs searches for users, groups, or attributes using LDAP filters.
  3. Optionally, the connection upgrades to TLS using StartTLS, or you use LDAPS on 636 for implicit TLS.

Concrete example

An application needs to check group membership. It binds to LDAP, searches for the user DN, then queries group attributes to decide whether to allow access.

Why it matters

Directory services are high value targets. Exposing LDAP without encryption can leak credentials and directory structure. Misconfigured LDAP access also enables privilege escalation through group discovery and weak service accounts.

Security angle

  • Use StartTLS or LDAPS and require strong authentication.
  • Restrict who can query the directory and monitor bind failures and unusual search patterns.
  • Harden service accounts and remove unnecessary anonymous binds.

Common pitfalls

  • Allowing simple bind over cleartext where passwords can be captured.
  • Granting directory read access too broadly, leaking sensitive attributes.
  • Confusing LDAP with Kerberos. LDAP is often used for lookups even when Kerberos does the main auth.