Strange issue: LDAP container restart caused authentication failures

No config changes.
No outages.
slapd was running and port 389 was open.

But SSH logins suddenly started failing for some users.

From the outside everything looked healthy. Replication looked normal too.

After digging into it, the issue wasn’t a crash or obvious misconfiguration. It was drift.

In a lot of Docker LDAP setups, things slowly stop behaving the same way over time:

• mounted volumes keep old ownership after restarts
• initialization scripts assume a clean directory
• config inside slapd.d drifts from env variables
• attributes used by authentication filters aren’t indexed

Nothing actually breaks. Authentication just becomes inconsistent.

We ended up rebuilding our container around one rule: a restart should behave exactly like the first deployment.

Before slapd starts we reconcile permissions on mounted volumes so the ldap user (UID 55) can always access the database.

Startup is idempotent — if the database or base DN already exists we validate instead of blindly reapplying configuration.

We also made sure attributes like uid, cn, member, and memberOf are indexed early so authentication queries stay predictable as the directory grows.

Replication is defined explicitly with SERVER_ID and peer configuration so nodes actually understand their role.

After those changes, restarts stopped changing authentication behaviour.

Which is honestly the goal — LDAP should be boring infrastructure.

Curious how others deal with LDAP state in containers.

If you restart your LDAP container today, are you confident authentication will behave exactly the same?