Configuration Issues with OpenLDAP MDB Backend

Frontend and Backend Development
1

I’m facing challenges while trying to configure an OpenLDAP server with an MDB backend. I’ve attempted to use both the version from the package repository and a self-compiled version to ensure that back_mdb is included in slapd, but neither works. Although the config database is accessible and the log does not display any errors, the database file (data.mdb) is created, but my root suffix does not appear and is not writeable. Even a basic configuration from the OpenLDAP administrator’s guide hasn’t solved the problem. Here’s my current configuration:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args

database    mdb
maxsize     1073741824
suffix      "dc=myorg,dc=local"
rootdn      "cn=administrator,dc=myorg,dc=local"
rootpw      "{SSHA}somehashedpassword"
directory   /var/lib/openldap/data
index   objectClass eq
access to dn.subtree="ou=employees,dc=myorg,dc=local" by self write by dn="cn=server,ou=users,dc=myorg,dc=local" write by dn="cn=mobile,ou=users,dc=myorg,dc=local" read
access to * by dn="cn=administrator,dc=myorg,dc=local" write by anonymous auth by dn.subtree="ou=users,dc=myorg,dc=local" read by * none

database config
rootdn "cn=administrator,cn=config"
rootpw "{SSHA}somehashedpassword"

Looking for help to resolve this issue.

2

Hey Silvia, did you make sure the olcSuffix and olcRootDN are set correctly if you’re using cn=config? Sometimes things don’t sync between slapd.conf and cn=config properly. Also, did you check if the MDB backend file permissions are right? It could be just a simple perms issue.

3

Hey Silvia! What happens if you try to change the suffix to something simpler like “dc=test,dc=local” just as a test? It sounds a bit quirky, but i’ve seen unusual configurations work after simplifying things a bit. :sweat_smile: Also, have you tried checking slapd’s log level for more detailed logs?

4

It might be worthwhile to rename or temporarily move your existing database directory to ensure there isn’t any pre-existing corrupted data causing the issue. After that, recreate the slapd configuration, reloading it from scratch, ensuring no older config or data is lingering in the system. Additionally, try running slaptest with your current configuration file to check for any unnoticed syntax errors or configuration issues affecting the server’s operation. A clean start often helps diagnose persistent problems.

5

Try verifying that the rootdn and rootpw match in both instances—your main DB and config DB are separately defined in your config file. Sometimes they need alignment. Also, making sure ssha password is correctly encoded can help, wrong format could slip through unnoticed here.