Operations, Security & LDAP in the Enterprise

Bind & Search

# bind (authenticate)
ldapwhoami -D "uid=jdoe,ou=Engineering,dc=example,dc=com" -W

# search filter — AND: objectClass=person AND cn starting with "John"
(&(objectClass=person)(cn=John*))

A bind authenticates a client to the server — anonymous, simple (DN + password), or SASL (e.g. Kerberos-based). Search filters use a prefix-notation syntax with &/|/! operators and wildcards to match entries against attribute criteria.

Securing LDAP Traffic

Plain LDAP (port 389) sends bind credentials unencrypted — interceptable by anyone observing network traffic. LDAPS (LDAP over TLS, typically port 636) or STARTTLS (upgrading an initially plaintext connection) are essential whenever real credentials are involved.

Active Directory & Kerberos

Microsoft Active Directory is a directory service implementation that exposes LDAP as one of its interfaces for querying directory data. In many enterprise setups, Kerberos handles the actual cryptographic authentication handshake while LDAP is used separately to query attributes and group memberships — complementary, not competing, protocols.

LDIF & Pagination

LDIF (LDAP Data Interchange Format) is the plain-text format for representing entries and changes, commonly used for bulk import/export and scripted modifications. Because servers often cap how many entries a single search returns, clients querying large result sets need to use paged-results controls to retrieve everything in batches.

Fronting LDAP with a Modern Identity Provider

Raw LDAP concepts (DNs, filters, schema, binds) add real integration complexity compared to a standardized OAuth2/OIDC token flow. It's common to put a SAML/OIDC identity provider in front of an LDAP directory, so applications integrate against a modern auth protocol rather than embedding LDAP-specific logic everywhere.