Learn LDAP - Security Fundamentals

#Introduction

In episode 14 you made searches fast with indexes. Now the discussion shifts: a fast directory that leaks is worthless. Episode 15 opens the security and encryption phase by covering the basic threats — from passwords sent as-is to man-in-the-middle attacks — then mapping the authentication types available in OpenLDAP before you seal them with TLS in episode 16.

#Security Challenges

The fundamental nature of LDAP is a text network protocol running over TCP. Without protection, these are the threats:

• Clear-text passwords — a simple bind sends the DN and password in the clear to the server; anyone on the network path can read them.
• Network eavesdropping — passive sniffing; an attacker only needs to sniff packets to capture credentials.
• Unauthorized access — accounts or services accessing data they shouldn't.
• Data tampering — modifying data in transit undetected.
• Man-in-the-middle attacks — an attacker impersonates the server and tricks clients into handing over credentials.

All these threats can be answered with a combination of transport encryption (episode 16) and strict access policies. This episode prepares the authentication concepts first.

#Authentication Methods

OpenLDAP provides several ways to recognize who's talking:

• Anonymous access — a bind without DN or password; useful for public data, dangerous if left open for internal data.
• Simple bind — a bind with DN plus password; the easiest, but sends the password in the clear unless a TLS layer is present.
• SASL (Simple Authentication and Security Layer) — a pluggable framework that selects an authentication mechanism.
• External authentication — uses credentials from a lower layer, e.g. a TLS client certificate or a Unix socket.

A quick comparison:

#SASL Mechanisms

SASL doesn't authenticate by itself — it's a container for various mechanisms:

• PLAIN — sends username and password in the clear; needs a TLS layer, similar to a simple bind but with an identity that doesn't have to be a DN.
• DIGEST-MD5 — digest-based hashing; historically popular but now considered weak and not recommended.
• CRAM-MD5 — challenge-response based on MD5; also dated because MD5 is no longer strong.
• GSSAPI (Kerberos) — Kerberos ticket-based authentication; strong and the basis of SSO. This is covered in depth in episode 17.
• EXTERNAL (TLS client cert) — identity taken from the client certificate; very strong for mutual TLS.

#Security Strength Policy

Because simple bind and SASL PLAIN send plaintext passwords, OpenLDAP provides a security gate via olcSecurity on cn=config and per database:

Requiring a security layer

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSecurity
olcSecurity: tls=1
olcSecurity: ssf=1

tls=1 requires a TLS connection for all operations, and ssf=1 (security strength factor) demands a security layer with a minimum strength of 1. The result: binds that send passwords without TLS are rejected from the start, not just warned about.

#Password Storage

Beyond transport, how the server stores passwords also determines overall security. OpenLDAP stores hashes, not plaintext passwords, with a scheme label:

The default hash is set via olcPasswordHash in cn=config. Avoiding the deprecated {SHA} and {MD5} is the cheapest security decision you can make.

#Access Policy and Least Privilege

Authentication is only half the journey — the other half is authorization. A few key settings:

• Disable anonymous — set olcDisallows: bind_anon to forbid anonymous binds, and olcRequires: authc so every operation demands authentication.
• Enforce TLS/SSL — olcSecurity as above.
• Strong password policies — enable the policies from episode 12.
• Least privilege — give the smallest ACL possible; reading applications get read, not write, and a replication account only gets search access.
• Authz policy — olcAuthzPolicy governs how SASL identities map to directory DNs; in episode 17 this becomes the key to Kerberos integration.

Closing anonymous access

dn: cn=config
changetype: modify
replace: olcDisallows
olcDisallows: bind_anon
 
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcRequires
olcRequires: authc

Periodic security audits, the monitoring and logging covered in episode 18, and firewall restrictions (only open ports 389 and 636 to authorized networks) close the remaining gaps.

#Closing

In this episode 15 you understood the OpenLDAP security foundation: cleartext password, eavesdropping, and man-in-the-middle threats; the difference between anonymous, simple bind, SASL, and external; SASL mechanisms from PLAIN to GSSAPI; securing with olcSecurity and ssf; password storage schemes from {SSHA} to {ARGON2}; and minimal access policies plus closing anonymous access.

Key takeaways:

• A simple bind without TLS is naked — passwords are sent in the clear; olcSecurity: ssf=1 forces a secure layer.
• SASL is a framework, not one mechanism — choose GSSAPI or EXTERNAL for production.
• Change the default hash — {SSHA512} or better, stay away from {MD5} and {SHA}.
• Least privilege beats trust — a combination of strict ACLs, bind_anon forbidden, and a firewall.

In the next episode, episode 16, you install the layer that seals all this: TLS/SSL configuration — certificates, StartTLS versus LDAPS, and testing encryption with ldapsearch -ZZ. The ssf and EXTERNAL concepts you know now become real practice.