Protocol · LDAP

LDAP PCAP Analysis

by My Network Consultant

From capture to clarity—follow directory binds and searches, spot failed authentication and cleartext credentials with AI-powered insights.

Layer 7 (Application) Related: TCP, UDP, TLS, Kerberos, SMB2 Ports: 389/TCP, 636/TCP (LDAPS), 389/UDP (CLDAP)

Overview

Lightweight Directory Access Protocol (LDAP, RFC 4511) is how clients query and update directory services such as Active Directory and OpenLDAP, and it sits behind a lot of authentication and permission problems. From a PCAP/PCAPNG you can follow the operations that matter—Bind (simple DN + password, or SASL such as GSSAPI/Kerberos), Search (base DN, scope, filter), Add/Modify/Delete/Compare, Extended requests (StartTLS is one), Unbind and Abandon—and read the result codes each one returns. Because LDAP is a BER/ASN.1 protocol, the analyzer decodes each PDU and lays the messages out per session, so a failed login or a cleartext password is easy to see.

  • What you’ll see: bind DN and auth method, search base/scope/filter, result codes (0 success, 32 noSuchObject, 49 invalidCredentials, 50 insufficientAccessRights), extended/StartTLS requests, and cleartext simple binds
  • Best for: Active Directory auth troubleshooting, SOC triage, incident response, and performance analysis
  • Works with: LDAP on 389/TCP, LDAPS on 636/TCP (TLS from start), StartTLS on 389, and CLDAP on 389/UDP (AD rootDSE/netlogon pings)

What to look for

  • Failed binds: result code 49 (invalidCredentials); repeated across connections → brute force or password spray,
  • Cleartext credentials: a simple bind with a bind DN over plain LDAP (389, no TLS) exposes the password—flagged as a cleartext simple bind,
  • Permission errors: result code 50 (insufficientAccessRights)—the identity is authenticated but not authorized,
  • Missing objects: result code 32 (noSuchObject)—the base DN or target entry does not exist,
  • Server faults: result code 1 (operationsError)—internal or protocol-sequencing problems,
  • Reconnaissance: many searches, broad subtree scopes, or CLDAP rootDSE/netlogon pings enumerating the directory,
  • Encryption posture: StartTLS extended requests, LDAPS on 636, and SASL (e.g. GSSAPI/Kerberos) vs. plain simple binds.

Capture tips

  • Capture 389/TCP for classic LDAP and 389/UDP for CLDAP (rootDSE/netlogon) so AD pings are visible.
  • Include 636/TCP (LDAPS); it is TLS from the start, so pair it with the TLS analysis for handshake detail.
  • For StartTLS, capture the whole session—the clear-text LDAP before the upgrade is decoded, everything after becomes TLS.
  • Capture close to the domain controller or the client to localize where failed binds and permission errors originate.
  • Use a focused time window that reproduces the issue and stays within the 10 MB demo limit.

Example walkthrough

  1. Browse to LDAP.
  2. List the bind operations and their result codes; isolate any 49 (invalidCredentials) and note repeats across connections.
  3. Check each bind’s auth method; flag simple binds with a DN over plain LDAP as cleartext credential exposure.
  4. Review searches—base DN, scope (base/one/subtree) and filter—for broad or repeated enumeration.
  5. Inspect other result codes (50 insufficientAccessRights, 32 noSuchObject, 1 operationsError) to separate permission from configuration problems.
  6. Open the parsed-message view to read each PDU—bind DN/auth, search base/scope, result code/diagnostic—and export evidence for the ticket.

LDAP FAQ

Look for bind operations answered with result code 49 (invalidCredentials)—the DN or password was wrong. The analyzer lists each bind and its result, so repeated 49s across many connections stand out as a possible brute-force or password-spraying attempt.

Yes. A simple bind that carries a bind DN over plain LDAP (port 389, no TLS) sends the password in clear text. The analyzer flags this as an “LDAP cleartext simple bind” so you can find exposed credentials and recommend LDAPS, StartTLS, or SASL instead.

LDAPS on port 636 is TLS from the start and is handled by the TLS analysis. StartTLS is an LDAP extended request on port 389 that upgrades the connection; the clear-text LDAP before the upgrade is decoded, and everything after becomes TLS.

Watch for many searches, broad subtree scopes from one client, and CLDAP (UDP 389) rootDSE or netlogon pings used to enumerate Active Directory. Reviewing search base DNs and scopes alongside result codes separates normal lookups from enumeration.
We use cookies & process data
By using this site, you agree to our Terms and Privacy Policy. We process file uploads for network analysis only.