Port 389 LDAP – Free, Online, Private

What listens on 389

Port 389 is LDAP. The IANA name is ldap, Lightweight Directory Access. Clients bind, search, and modify entries. STARTTLS can upgrade the session. Implicit TLS is port 636, ldaps. The registry has a UDP row. Directory traffic you will operate is TCP. Active Directory uses 389 for the domain, and it also uses a set of other ports, including Kerberos on 88, that are not this number. Closing 389 and leaving the rest open does not disable a domain controller. Opening only 389 does not make one work.

The IANA service name is ldap: Lightweight Directory Access Protocol. The practical transport is TCP. The checks below use TCP. IANA may also have a UDP row for 389. The service described here is the TCP one. A process can bind this port without being the service in the registry. The commands show who bound it. They do not prove the protocol on the wire is the one IANA named.

Service notes for port 389

Service notes for port 389: the IANA name is ldap (Lightweight Directory Access Protocol), and the program people mean is LDAP. TCP 389 is the IANA ldap port. LDAPS is 636. Cleartext LDAP should not be how you bind over a network you do not trust. A simple bind on 389 sends the password in the clear unless STARTTLS ran and the certificate was verified. Require TLS, or use 636, and do not allow anonymous reads of the whole tree. An LDAP server is an account database. Treat the listener like one. Bind it to the network that should see it, not to every address. If this host is not a directory, a listener on 389 is a surprise and should be removed. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 389, you are on the wrong page.

Clients that say 'SSL' and port 389 speak TLS to a server that is waiting for an LDAP message. Use 636 or configure STARTTLS explicitly. A certificate name that does not match the host people dial is the next failure, and it looks like a port problem because the TCP handshake worked. Another trap is a firewall that opened 389 for a legacy app and became the permanent hole. Another is testing with nc and reading the lack of a banner as a dead server. LDAP servers often wait for the client to send first.

How to check whether it is open

On the machine itself, ask the kernel which socket is bound. ss and lsof do that. A firewall, a security group, and a Docker publish rule sit in front of that socket, so a listener is not the same thing as a port the internet can use. From somewhere else, nc -vz host 389 tries a TCP handshake when the command is the TCP form. A refusal means something answered with a reset. A timeout means a filter dropped the packet or the host is unreachable. Those are different faults. TCP 389 should be owned by slapd, or by an AD process on a domain controller. From a client, an LDAP search with a real base DN is the test. nc -vz only proves the handshake. Confirm whether the socket is on the internal address only.

grep and findstr match text. A pattern of :80 also matches :8080 and :8000. The lsof and Get-NetTCPConnection forms take a numeric port and do not have that substring bug. Use them when the number is ambiguous. ss filters in the kernel with sport = :N, which is also exact. On macOS, netstat -p selects a protocol. It does not print the process the way Linux netstat -p does. lsof prints the process.

• Port 636 is ldaps. Port 389 is not implicit TLS.
• A domain controller needs more than 389. Kerberos and SMB are separate ports.
• UDP 389 in the registry is not the traffic to debug first.
• No banner does not mean the port is closed. LDAP often speaks second.

Linuxsudo ss -lptn 'sport = :389'
sudo lsof -nP -iTCP:389 -sTCP:LISTEN

macOSsudo lsof -nP -iTCP:389 -sTCP:LISTEN
netstat -anv -p tcp | grep '\.389[^0-9]'

Windowsnetstat -ano | findstr :389
Get-NetTCPConnection -LocalPort 389

Remotenc -vz host 389