When setting up OpenLDAP with FusionDirectory on RHEL/CentOS 6 systems, many administrators encounter the "No such object (32)" error during the initial configuration phase. This typically occurs when trying to modify LDAP database entries before they're properly initialized.

The error message indicates that LDAP cannot find the specified database entry in cn=config. This usually happens because:

1. The database index ({2}bdb) doesn't match your actual database numbering
2. The slapd configuration isn't properly loaded
3. The olcDatabase entries haven't been created yet

First, verify your current database configuration:

sudo ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config

Instead of assuming {2}bdb, dynamically identify your database number:

sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config "(olcDatabase=*)" olcDatabase

Here's a safer way to apply your configuration changes:

# First create the basic database structure
dn: olcDatabase=bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=example,dc=net
olcDbDirectory: /var/lib/ldap
olcRootDN: cn=Manager,dc=example,dc=net
olcRootPW: {SSHA}RbncgBcs8McqwMMAjx4CFdENpLycUc4w
olcDbIndex: objectClass eq
olcDbIndex: uid,uidNumber,gidNumber eq
olcDbIndex: cn,sn,mail eq,sub

For the monitor database, use this safer approach:

dn: olcDatabase={1}monitor,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * 
  by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
  by dn.base="cn=Manager,dc=example,dc=net" read
  by * none

After applying changes, verify with:

sudo ldapsearch -x -LLL -b "dc=example,dc=net" -D "cn=Manager,dc=example,dc=net" -W

Remember to restart the slapd service after configuration changes:

sudo service slapd restart

1. Database numbering mismatch between installations
2. Incorrect file permissions on /etc/openldap/slapd.d
3. Missing schema definitions before applying ACLs

---

When deploying OpenLDAP with FusionDirectory on RHEL/CentOS 6 systems, many administrators encounter the frustrating "No such object (32)" error during initial configuration. This typically occurs when applying LDIF modifications to cn=config through ldapadd commands.

The error manifests when running commands like:

sudo ldapadd -Y EXTERNAL -H ldapi:/// -f ch_domainSettings.ldif

With the following output:

ldap_modify: No such object (32)
matched DN: cn=config

The primary causes fall into these categories:

• Database index mismatch (your LDIF references {2}bdb but system uses different index)
• Incorrect DN paths in the LDIF file
• Missing prerequisite schemas or configurations
• Permission issues with cn=config access

First, verify your actual database indexes:

sudo ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config 'olcDatabase=*' dn

You'll typically see output like:

dn: olcDatabase={1}monitor,cn=config
dn: olcDatabase={2}hdb,cn=config

Notice the database type (hdb vs bdb) may differ from your LDIF. Adjust your ch_domainSettings.ldif accordingly:

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=example,dc=net

For production deployments, consider these enhancements:

# Add these to your LDIF:
dn: olcDatabase={2}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: objectClass eq
olcDbIndex: uid eq,pres,sub
olcDbIndex: cn eq,pres,sub
olcDbIndex: mail eq,pres,sub

After successful modification, verify with:

sudo ldapsearch -Y EXTERNAL -H ldapi:/// -b 'dc=example,dc=net' '(objectclass=*)'