OpenLDAP Security: Harden slapd ACLs, TLS, Password Policy and Replication

An OpenLDAP directory often holds every employee, service account and Unix group an organisation has, and slapd serves it to whatever client can reach port 389 under the access rules the administrator writes. The protocol-level picture of bind types, signing and channel binding is covered in the LDAP Security Deep Dive Guide. This guide goes one level down into slapd itself: the cn=config database, olcAccess rules, the security strength factor directives, TLS settings, the ppolicy overlay, password hashing, syncrepl replication identities and the accesslog and auditlog overlays. It is written for directory administrators, Linux platform engineers and identity teams running OpenLDAP 2.6, and uses the directive names from the project's own Administrator's Guide and man pages.

This is an independent guide from NHI Mgmt Group, based on the OpenLDAP Project's public documentation as of November 2026. It is not sponsored or reviewed by the OpenLDAP Project. Product features change, so confirm settings against the OpenLDAP Project's current documentation.

Key takeaways

• Replace the default read policy. Without explicit rules slapd allows read by all clients; write olcAccess rules that protect userPassword first and end with a deny.
• Require authentication, not just a named bind. Use olcRequires: authc; olcDisallows: bind_anon on its own still permits anonymous directory access.
• Enforce protection with security strength factors. olcSecurity values such as simple_bind=128 and update_ssf=128 stop passwords and changes travelling in clear text.
• Turn on the ppolicy overlay with a default policy. If no default policy DN is set and an entry has none of its own, no password policy is enforced at all.
• Treat replication and config identities as privileged service accounts. The syncrepl bind DN reads the whole tree and the cn=config rootDN can load code; give each its own identity, strong authentication and monitoring.

How identity and access work in OpenLDAP

slapd answers LDAP operations for one or more databases, each with a suffix (for example dc=example,dc=com), a rootDN that bypasses access control, and an ordered list of access rules. Since OpenLDAP 2.3 the recommended configuration method is the dynamic cn=config database (the slapd.d directory), where every directive becomes an attribute with an olc prefix and changes are applied with ldapmodify without a restart. The older slapd.conf file uses the same keywords without the prefix. Both names are given below where they differ.

A client identity is established at bind time. OpenLDAP documents four authentication paths, and each needs a decision.

Access control rules

Each olcAccess value has the form to <what> by <who> <access> [control]. The what clause selects entries by DN, filter or attribute list. The who clause can be *, anonymous, users, self, a DN pattern, a group, a peername address pattern or an ssf threshold. Access levels are cumulative: none, disclose, auth, compare, search, read, write, manage.

Evaluation is first match. Per-database rules are checked before global (frontend) rules, the first matching what selects the rule, and the first matching who inside it decides the access. Every rule ends with an implicit by * none, and a non-empty list ends with an implicit to * by * none. The Administrator's Guide sums up the ordering advice as special rules first, generic rules last. Its standard pattern for passwords is:

• Rule 1: to attrs=userPassword by self =xw by anonymous auth by * none lets users change their own password without reading it, lets the server use it to authenticate binds, and hides it from everyone else.
• Rule 2: to * by self write by users read by * none gives users their own entry, authenticated users read access, and nothing to anonymous clients.

Add rules for shadowLastChange, sshPublicKey or other sensitive attributes the same way, and put rules that grant write to group administrators or helpdesk staff above Rule 2. The cn=config database itself is inaccessible by default unless you configure a way to authenticate as its super-user.

Admin roles and privileged access

In OpenLDAP, privilege comes from the rootDN of each database and from manage or write grants in olcAccess. Three kinds of identity need the most care.

Practical steps for privileged access:

1. Create named administrator entries in a protected ou=admins branch and a group per duty (accounts, groups, schema). Avoid shared use of the rootDN.
2. Write those grants with an ssf condition, for example by group.exact="cn=dir-admins,ou=groups,dc=example,dc=com" ssf=128 write, so administration only works over an encrypted session.
3. Restrict where administration can come from with peername.ip= or peername.regex= clauses plus a host firewall.
4. Keep one break-glass route (local ldapi with SASL EXTERNAL as root) documented and tested. See the Break-Glass Account Guide.
5. Review rootDN, olcAccess and group membership changes through the auditlog overlay described below.

Integrations, API tokens and service accounts

Most binds against a production directory come from machines: PAM and SSSD on Linux hosts, web applications, mail servers, VPN concentrators and replicas. These are non-human identities with long-lived passwords, and they deserve the same lifecycle discipline as any other service account. See the Service Account Security Guide.

• One DN per consumer: create cn=app-name,ou=services,dc=example,dc=com entries rather than sharing one search account, so olcAccess can scope each one and logs show which system bound.
• Least read scope: grant each service only the subtree and attributes it needs, for example to dn.subtree="ou=people,dc=example,dc=com" attrs=uid,cn,mail,memberOf by dn.exact="cn=mailserver,ou=services,dc=example,dc=com" read. Keep userPassword at auth only.
• Certificate or Kerberos instead of passwords: where clients support it, use SASL EXTERNAL with a TLS client certificate (set olcTLSVerifyClient: try or demand) or SASL GSSAPI with a keytab, and map the identity with olcAuthzRegexp.
• Protect stored credentials: bind passwords in client files (sssd.conf, application config) belong in a secrets manager or root-only files, with rotation. See the Secrets Management Guide.
• Size and time limits: use olcLimits to give ordinary service DNs bounded size and time values, and grant unlimited only to the replication DN that needs it.

Replication identities

syncrepl consumers bind to the provider and receive whatever that identity can read. The replication documentation shows a provider rule of to * by dn.exact="cn=replicator,dc=example,dc=com" read by * break placed first, and unlimited limits scoped to that DN only. For delta-syncrepl the replicator also needs read access to the accesslog database. Secure the channel and the credential:

• Set starttls=critical (not yes, which falls back to clear text if TLS fails) and tls_reqcert=demand in each olcSyncrepl value, or use an ldaps:// provider URI.
• Prefer bindmethod=sasl with saslmech=EXTERNAL and a client certificate over bindmethod=simple with an inline credentials= password. If a password is used, protect the slapd.d directory and rotate it.
• Use partial replication where a consumer only needs part of the tree: it receives only what its bind identity can read.
• Protect the session log by restricting who can bind as the replicator; the replication guide describes this as the control to use for the session log.

Transport security: TLS and security strength factors

OpenLDAP supports StartTLS on port 389 (the standard approach) and ldaps on port 636. Configure the server certificate and policy in cn=config:

TLS that is available is not the same as TLS that is required. olcSecurity sets minimum security strength factors (SSF, roughly the effective key length) per operation type. A useful baseline is olcSecurity: ssf=1 update_ssf=128 simple_bind=128: integrity on everything, encryption for every change, and no simple bind outside an encrypted session. The same thresholds can be used inside olcAccess (ssf=, tls_ssf=, sasl_ssf=) to tie sensitive grants to encrypted sessions. Apply the general guidance in the TLS Server Configuration Baseline Guide.

Password policy and password storage

The ppolicy overlay implements the LDAP password policy draft: lockout, history, minimum length, ageing and forced change after reset. Load the module, add olcOverlay: ppolicy to the database, create a pwdPolicy entry and point ppolicy_default (cn=config: olcPPolicyDefault) at it. The man page is explicit that with no default and no per-entry policy, no policies are enforced.

Assign a separate policy to service accounts through pwdPolicySubentry on their entries, typically with lockout off (to avoid an outage when a misconfigured client retries) and monitoring on instead. Two further overlay options matter: ppolicy_hash_cleartext (olcPPolicyHashCleartext) hashes cleartext passwords that arrive in Add and Modify requests, and the man page recommends denying compare, search and read on passwords when it is used; ppolicy_use_lockout returns an AccountLocked code, which the man page advises security-sensitive sites not to enable, so leave it off on directories exposed beyond trusted clients. On replicas, ppolicy_forward_updates sends lockout state to the provider (it needs updateref and the chain overlay).

For storage, olcPasswordHash controls the scheme used when the Password Modify extended operation sets a password; the default is {SSHA}, salted SHA-1, which the Administrator's Guide describes as the most secure of its built-in schemes. Never configure {CLEARTEXT}, avoid unsalted {MD5} and {SHA}, and treat every stored hash as sensitive because, as the guide notes, hashes remain open to dictionary and brute-force attack. The {SASL}user@realm pass-through scheme (built with --enable-spasswd) delegates checking to saslauthd or Kerberos; if you use it, block password changes through LDAP with olcAccess.

Logging and detection

olcLogLevel defaults to stats, which logs connections, binds (with DN and method), operations and result codes to syslog. That is the minimum to forward. Two overlays add change history:

• accesslog: writes operations into a separate LDAP database (logdb), with logops to choose operation types (for example writes plus bind), logsuccess, logold to capture prior values and logpurge for retention. It is also the basis for delta-syncrepl. Protect the log database with its own olcAccess rules.
• auditlog: writes every change as LDIF to the file named in olcAuditlogFile. Attach it to the cn=config database as well as the data database so configuration and ACL changes are recorded.

Forward slapd logs and auditlog output to your SIEM with the guidance in the Log Management and Retention Guide. Useful measures: percentage of binds over TLS or SASL (target 100%), number of service DNs with unlimited limits (target one per replica), count of identities with write or manage outside the admin groups, days since each service credential was rotated, and time from a cn=config change to SIEM alert.

Hardening baseline

Roll changes out in this order, testing each step against a staging copy loaded from slapcat output, and keep the previous cn=config export to roll back with slapadd if a change locks clients out.

1. Network: listen only where needed with slapd -h (for example ldap:/// ldaps:/// ldapi:/// on internal interfaces), and restrict 389/tcp and 636/tcp at the host firewall. The project advises firewall rules over TCP Wrappers.
2. Config access: confirm cn=config is reachable only through ldapi with SASL EXTERNAL; remove any cleartext olcRootPW.
3. TLS: install certificates, set olcTLSProtocolMin and the cipher suite, and move clients to StartTLS or ldaps.
4. Enforce: set olcSecurity ssf values and olcRequires: authc; watch stats logs for refused operations during a pilot window.
5. Access rules: deploy the userPassword rule, service-specific read rules and a final deny; test each service DN with ldapsearch and ldapwhoami.
6. Password policy: load ppolicy with a default policy, a privileged policy and a service policy; enable olcLastBind if you use pwdMaxIdle.
7. Replication: move syncrepl to starttls=critical and certificate or SASL binds; scope the replicator rule and limits.
8. Logging: enable auditlog on cn=config and data databases, accesslog where you need queryable history, and SIEM forwarding.
9. Updates: apply OpenLDAP and TLS library security releases promptly from your distribution or the project's release announcements.

Common misconfigurations

• Relying on bind_anon alone: olcDisallows: bind_anon refuses the anonymous bind request but, as the man page notes, does not prohibit anonymous directory access. Add olcRequires: authc.
• Rule order that leaks: a broad to * by users read placed above the userPassword rule wins on first match and exposes hashes to every authenticated user. Keep specific attribute rules first.
• starttls=yes on replicas: replication silently continues in clear text when TLS fails. Use critical.
• ppolicy loaded but not applied: the overlay is present but ppolicy_default is unset, so most entries have no policy.
• Clients that skip verification: TLS_REQCERT never or allow in ldap.conf on application servers accepts any certificate. Keep demand and distribute the CA file.
• Shared search account with unlimited limits: one service DN used by many applications, with read on the whole tree, turns any one application secret into a full directory export.

Practitioner checklist

• Restrict listeners with slapd -h and a host firewall on 389 and 636.
• Administer cn=config only through ldapi with SASL EXTERNAL; no cleartext rootPW anywhere.
• Set olcRequires: authc and olcSecurity: ssf=1 update_ssf=128 simple_bind=128.
• Require TLS 1.2 or later with olcTLSProtocolMin: 3.3 (OpenSSL builds) and keep client TLS_REQCERT demand.
• Put the userPassword rule first and end every database's olcAccess list with an explicit deny.
• Give each application its own service DN with scoped read, bounded limits and a vaulted, rotated credential.
• Load ppolicy with a default policy, plus separate privileged and service policies.
• Run syncrepl with starttls=critical, tls_reqcert=demand and a dedicated replicator identity.
• Enable auditlog on cn=config and forward stats logs to the SIEM with alerts on ACL and rootPW changes.
• Review olcAccess, admin group membership and service DNs every quarter.

Standards and references

• OpenLDAP: Administrator's Guide 2.6, Security Considerations
• OpenLDAP: Administrator's Guide 2.6, Access Control
• OpenLDAP: Administrator's Guide 2.6, Using TLS
• OpenLDAP: Administrator's Guide 2.6, Overlays (ppolicy, accesslog, auditlog)
• OpenLDAP: Administrator's Guide 2.6, Replication
• OpenLDAP: Administrator's Guide 2.6, Configuring slapd
• OpenLDAP: slapd-config(5) manual page
• OpenLDAP: slapo-ppolicy(5) manual page

Related NHI Mgmt Group resources: LDAP Security Deep Dive Guide · Service Account Security Guide · Password Policy Guide (NIST-aligned) · TLS Server Configuration Baseline Guide · Kerberos Security Guide