Troubleshooting LDAP

This is the last page of a five-part tutorial on LDAP. The full tutorial includes

• User Authentication: LDAP
• LDAP Server
• LDAP Client
• Using LDAP
• Troubleshooting LDAP

Updating after Changes

After making any change in an LDAP configuration, like the location of the LDAP server, multiple files need to be updated -

• /etc/ldap/ldap.conf
• /etc/pam_ldap.conf
• /etc/libnss-ldap.conf

Changes to the administrative password for LDAP database need to be changed at

• /etc/libnss-ldap.secret
• /etc/pam_ldap.secret

Alternatively, dpkg-reconfigure for libnss-ldap and libpam-ldap will also work. Don't run dpkg-reconfigure for slapd, though, as this will erase the previous database (see below if this accidentally happens).

LDAP Checks

It's often helpful to have a non-LDAP user and an LDAP user account on a client system to test out.

• First, can you log in at all as the non-LDAP user? If not, there's most likely a problem with the basic configuration of nsswitch.conf or the pam files.
• Can you do an ldap search for the LDAP user? Use ldapsearch -x uid=<ldap user's ID>. This will determine whether the client can connect to the ldap server at all.
  • If not, check /etc/ldap/ldap.conf
• Can you su - <ldapuser>, id <ldapuser>, and change the user's password (passwd <ldapuser>)? If not, then there's probably a problem with the nsswitch and pam talking to the ldap server. Double check the values for
  • /etc/nsswitch.conf
  • /etc/pam.d/common-account, /etc/pam.d/common-auth, /etc/pam.d/common-password, and /etc/pam.d/common-session
  • /etc/pam_ldap.conf

How to Fix an Accidental Dpkg-Reconfigure Slapd

If you run dpkg-reconfigure slapd on the LDAP server and go into the database configuration options, a new LDAP database will automatically be created for you and your old one purged. Yikes! Fortunately, dpkg creates a backup of your old database in /var/backups/. For instance, the directory automatically created for me after a dpkg-reconfigure was dc=raptor,dc=loc-2.3.38-1+lenny1.ldapdb. (My internal network is raptor.loc.)

To restore your previous slapd (LDAP server) database, first stop slapd with

/etc/init.d/slapd stop

Next, move the current LDAP server database - the one that was newly created for you, that you probably didn't really want - to a different location. You'll want to keep it in case something goes wrong. The current database is stored in /var/lib/ldap/. Make a folder in root's home directory and copy it to root's home directory with

mkdir ~/ldapempty

cp /var/lib/ldap/* ~/ldapempty/

Once it's been copied over, you can delete the contents of /var/lib/ldap using

rm /var/lib/ldap/*

Then copy over the files from the backup directory to the directory you just emptied. Yours will look similar to this, but of course, replace the directory name with your actual backup directory.

cp /var/backups/dc\=raptor\,dc\=loc-2.3.38-1+lenny1.ldapdb/* /var/lib/ldap/

If you do an ls on /var/lib/ldap, you'll see that all the files are currently owned by root. Failing to change then to openldap will cause an error like this in /var/log/syslog when you try to start the system back up:

Feb  6 12:44:39 eyrie slapd[19570]: bdb_db_open: database "dc=raptor,dc=loc": alock package is unstable.
Feb  6 12:44:39 eyrie slapd[19570]: backend_startup_one: bi_db_open failed! (-1)

To prevent that, change all of the files to be owned by openldap using this command:

for x in `ls /var/lib/ldap`; do chown openldap:openldap $x; done

Finally, you'll want to copy your slapd.conf configuration file back. Again, make a copy of the new one in case something should go wrong:

cp /etc/ldap/slapd.conf ~

and then replace it with your backed up version, which will look something like this:

cp /var/backups/slapd-2.3.38-1+lenny1/slapd.conf /etc/ldap/slapd.conf

After you've done that, you should be able to start slapd back up again:

cp /var/backups/slapd-2.3.38-1+lenny1/slapd.conf /etc/ldap/slapd.conf

/etc/init.d/slapd start

It's wise to make sure the changes took affect as you expected by doing an LDAP search for a user account. If you can't connect to the LDAP server, double check everything started ok by tailing /var/log/syslog.