Some systems were running a patch that originated from CentOS that borks their LDAP. The steps to validate are:

1) Move the /etc/openldap/slapd.d folder out of the way. (The CentOS RPM creates this folder)
mv /etc/openldap/slapd.d /tmp/

2) Make sure that you have a valid slapd.conf file in the /etc/openldap/ directory. This file should have all of the schema:

# Schemas
#----------------------------------------------------------

# Core schemas
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema

# ClearFoundation base
include /etc/openldap/schema/rfc2307bis.schema
include /etc/openldap/schema/clearfoundation.schema

# ClearCenter extension
include /etc/openldap/schema/clearcenter.schema

# Password policy extension
include /etc/openldap/schema/ppolicy.schema

# RADIUS extension
include /etc/openldap/schema/RADIUS-LDAPv3.schema

# Kolab extension
include /etc/openldap/schema/rfc2739.schema
include /etc/openldap/schema/kolab2.schema

# Horde extension
include /etc/openldap/schema/horde.schema

# Samba extension
include /etc/openldap/schema/samba3.schema

# OwnCloud
include /etc/openldap/schema/owncloud.schema

# Zarafa extension
include /etc/openldap/schema/zarafa.schema

# Kopano extension
include /etc/openldap/schema/kopano.schema

The Kopano is new so if the file you have doesn't have all of these and the Kopano as well, please find a valid copy in backup or as one of the files in this directory. Restore this file to its proper place.

3) Validate that the slapd.conf file is owned by ldap. If not, run:
chown ldap:ldap /etc/openldap/slapd.conf

NOTE: I will include a full copy of a template slapd.conf file in a subsequent post.

Domain: replace example.com
Password: Must have the valid password

# Schemas

#----------------------------------------------------------



# Core schemas

include /etc/openldap/schema/core.schema

include /etc/openldap/schema/cosine.schema

include /etc/openldap/schema/inetorgperson.schema



# ClearFoundation base

include /etc/openldap/schema/rfc2307bis.schema

include /etc/openldap/schema/clearfoundation.schema



# ClearCenter extension

include /etc/openldap/schema/clearcenter.schema



# Password policy extension

include /etc/openldap/schema/ppolicy.schema



# RADIUS extension

include /etc/openldap/schema/RADIUS-LDAPv3.schema



# Kolab extension

include /etc/openldap/schema/rfc2739.schema

include /etc/openldap/schema/kolab2.schema



# Horde extension

include /etc/openldap/schema/horde.schema



# Samba extension

include /etc/openldap/schema/samba3.schema



# OwnCloud

include /etc/openldap/schema/owncloud.schema



# Zarafa extension

include /etc/openldap/schema/zarafa.schema



# Kopano extension

include /etc/openldap/schema/kopano.schema





# Global configuration directives

#----------------------------------------------------------



pidfile /var/run/openldap/slapd.pid

argsfile /var/run/openldap/slapd.args



TLSCACertificateFile   /etc/openldap/certs/clearos-ca-cert.pem

TLSCertificateFile     /etc/openldap/certs/clearos-cert.pem

TLSCertificateKeyFile  /etc/openldap/certs/clearos-key.pem



defaultsearchbase "dc=example,dc=com"



allow bind_v2



loglevel 0



sizelimit 10000



moduleload accesslog.la

moduleload ppolicy.la

moduleload memberof.la

moduleload syncprov.la





# Monitor database

#----------------------------------------------------------



database   monitor





# Accesslog database

#----------------------------------------------------------



database   bdb

directory  /var/lib/ldap/accesslog

suffix     cn=accesslog

rootdn     cn=accesslog

index      default eq

index      entryCSN,objectClass,reqEnd,reqResult,reqStart



overlay syncprov

syncprov-nopresent TRUE

syncprov-reloadhint TRUE



access to *

    by self write

    by peername.ip=127.0.0.1 read

    by * none stop





# Primary database

#----------------------------------------------------------



database    bdb

directory   /var/lib/ldap

suffix      "dc=example,dc=com"

rootdn      "cn=manager,ou=Internal,dc=example,dc=com"

rootpw      "{SSHA}aaaaaaaaaaaaaaaaaaaa+abababababa"



cachesize     20000

checkpoint    512 5

idlcachesize  20000

idletimeout   300

dirtyread



index  default sub

index  entryCSN eq

index  entryUUID eq

index  objectClass pres,eq

index  uid approx,pres,sub,eq

index  displayName pres,sub,eq

index  uidNumber eq

index  gidNumber eq

index  memberUID eq

index  member eq,pres

index  mail approx,sub,pres,eq

index  cn approx,sub,pres,eq

index  sn approx,sub,pres,eq

index  givenName approx,sub,pres,eq



# Contact extension

index  clearMailAliases approx,sub,pres,eq



# Samba extension

index  sambaSID eq,sub

index  sambaSIDList eq

index  sambaPrimaryGroupSID eq

index  sambaDomainName eq

index  sambaGroupType eq



# Kolab extension

index  kolabDelegate approx,sub,pres,eq

index  kolabHomeServer pres,eq

index  kolabDeleteflag pres,eq



# password policies

overlay ppolicy



# memberOf

overlay memberof



# syncrepl provider for primary database

overlay syncprov

syncprov-checkpoint 100 5



# accesslog overlay definitions for primary database

overlay accesslog

logdb cn=accesslog

logops writes

logsuccess TRUE

logpurge 32+00:00 01+00:00



# syncuser granted limitless searches

limits dn.exact="cn=syncuser,ou=Internal,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited



access to *

    by dn="cn=syncuser,ou=Internal,dc=example,dc=com" write

    by * break



access to attrs=userPassword,clearMicrosoftNTPassword,clearSHA1Password,clearSHAPassword,sambaLMPassword,sambaNTPassword

    by self =wx

    by anonymous =x

    by * none stop



access to attrs=mail

    by * read stop



access to attrs=uid

    by * read stop



access to *

    by self write

    by peername.ip=127.0.0.1 read

    by * none stop

Thank you for the quick response. Heading to the basement to the server as I cannot ssh in for some reason. Will report back.

Please see responses in this thread for ongoing woes.

https://www.clearos.com/clearfoundation/social/community/ldap-not-starting-anymore-out-of-a-sudden-checking-configuration-file-failed

@Gordon, If you raise a free ticket (perhaps a general enquiry) and give remote access to the devs, they will log in and fix it for you.

Gordon came into support and what we found was that a restore attempt earlier had made it so that our fix doesn't work because the restore killed all his LDAP database. Basically, if you have a compromised system and attempt to recover from a backup configuration it will try to restore with the failed slapd.conf file and will error out. Unfortunately, it will have already dropped your users from your LDAP database in the process so if you fix the slapd.conf file and start 'slapd' it will run but have no users in the database.

The process is a bit advanced to recover from this so if anyone has this particular nuance of attempting to recover from the backup config and failing, please hop into support for ClearCARE and let us help you fix it. Basically what you have to do is to create a merged recovery file in Remote Configuration Backup of a previous backup and the fixed slapd.conf.

You create a directory.
Copy the configuration backup file you want to restore from.
Extract it (tar xvcf filename) and move the archive tgz file away
Copy the correct slapd.conf file (with the Kopano fixes) into the right place in the archive
Validate the permissions (ldap:ldap)
Archive up the file (cd /place/you/extracted/the/file && tar /tmp/ldaprecovery.tgz -cvzf *)
Then move the ldap recovery file back to /var/clearos/configuration_backup
Then go back into Webconfig and restore it.