In researching configuration tasks for OpenLDAP, I found this article about using sudo with OpenLDAP. As I am going to implement SSL with OpenLDAP, problems with sudo and SSL could be fatal, so I decided to investigate further.
It turns out that the problem is embedded in GnuTLS, a GPL-licensed OpenSSL replacement. GnuTLS was used by Debian because of a licensing conflict between OpenSSL and OpenLDAP. A backend library used by GnuTLS (libgcrypt11) causes problems based on the way it is initialized and the way it handles the dropping of privilege (that is, it gets rid of its “root” access). This shows up as suid applications failing when run against LDAP users; Ubuntu bugs 926350 (GnuTLS) and 423252 (sudo) are this exact problem.
GnuTLS is replacing libgcrypt11 with the nettle backend as of 2.11.x, but Ubuntu Lucid Lynx continues to use GnuTLS with the original (flawed) backend. The “fix” espoused by some is to use nscd – but this is acknowledged to be a workaround.
There is a GnuTLS version compiled not against libgcrypt11 but libnettle which should the problem. I did not test this PPA; if you wish to stick with OpenLDAP and GnuTLS this might be the way to go.
However, there is also a version of OpenLDAP compiled against OpenSSL. Add the PPA to your APT configuration and then perform a system update (apt-get update && apt-get upgrade). This will upgrade your OpenLDAP and cause it to stop at least temporarily; thus, make sure you allow for some server downtime.
This version of OpenLDAP works except for a few initial problems that must be overcome. When you first install, it may refuse to run.
First, it seems to add an openldap user and group – and while this is good, it does not completely change appropriate files to give access to the openldap user. There are two locations that need to be fixed:
/var/lib/ldap(the location of the LDAP data store)/etc/ssl(the location of the SSL certificates)
Fixing the first is simple:
chown -R openldap:openldap /var/lib/ldap
The second is not as straight-forward; in my case, I added the user openldap to the group ssl-cert which has access into the /etc/ssl directory and subdirectories. Use the vigr command to make this happen: add openldap to the end of the ssl-cert group line (your group id might be different):
ssl-cert:x:108:openldap
Note that if the SSL certificates aren’t set up right, then running the new OpenLDAP will not work – even if LDAPS is not enabled at startup. (There is a fantastic message showing how to make sure your certificates match from OpenVPN.net.) You also need to make sure that the certificates are not expired; it is reported that OpenLDAP will also fail to start with expired certificates.
As the final step, change the /etc/default/slapd file to start LDAPS:
SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"
Eventually, the best thing to do is to remove LDAP support entirely (and use LDAPS completely):
SLAPD_SERVICES="ldapi:/// ldaps:///"
UNIX Administratosphere 