Monday, May 7, 2012

HOWTO : CentOS 6.2 OpenLDAP 2.4 Setup

This blog post will show how to install and configure OpenLDAP 2.4 on CentOS 6.2.

Goals

  1. Install OpenLDAP 2.4.
  2. Configure Transport Layer Security (TLS).
  3. Manage users and groups in OpenLDAP.
  4. Configure pam_ldap to authenticate users via OpenLDAP.
  5. Use OpenLDAP as sudo's configuration repository.
  6. Use OpenLDAP as automount map repository for autofs.
  7. Use OpenLDAP as NFS netgroup repository again for autofs.
  8. Use OpenLDAP as the Kerberos principal repository.
  9. Setup OpenLDAP backup and recovery.
  10. Setup OpenLDAP replication.

Goal 1 : Install OpenLDAP 2.4


Of course, the very first thing we should do is to read the fine OpenLDAP Software 2.4 Administrator's Guide :)

Start by installing CentOS 6.2. This is quite easy. Just make sure to use the MINIMAL installation to keep the number of installed rpms to a minimum. This limits the number of packges one needs to update and also limits the attack surface on the server.
Once we have the CentOS machine up and running, we need to make sure the DNS settings are ok. Both forward and reverse lookup. This is also easy with two quick commands if our machine's Fully Qualified Domain Name (FQDN) is alice.example.com :

dig alice.company.com. +short
dig -x `dig server.company.com. +short` +short

Install the required packages. We install both the krb5-server-ldap and sudo packages right now even if we will configure them later. The idea is to get all the schema definitions right from the start.

sudo yum -y install openldap-servers openldap-clients krb5-server-ldap

Create a temporary working directory. We will use this directory during our installation.

mkdir ~/ldap

The general idea is to build a startup slapd.conf(5) file and then convert it to the new cn=config setup. List all the new schema files installed on the machine and dump them to a temporary configuration file.

rpm -ql openldap-servers krb5-server-ldap | grep '\.schema$' | sed -e "/README/d" -e "s/^/include /g" | tee  -a ~/ldap/slapd.conf.temp
rpm -ql sudo | grep -i schema.openldap | sed "s/^/include /g" | tee -a ~/ldap/slapd.conf.temp

Update! The latest version of OpenLDAP installs the pmi schema. The presence of this schema causes an error when running slaptest later in this tutorial. Since most of us don't need this schema, then we will remove it right here and now by running this command :

sed -e "/pmi/d" ~/ldap/slapd.conf.temp | tee -a ~/ldap/slapd.conf.fix

Thanks to Bas van Wetten for pointing this fix.

Now let's edit this file to add several items :
  • Our OpenLDAP suffix. It's normally your DNS domain name, but it doesn't have to.
  • the rootdn which is our OpenLDAP admin user. Think of him as the root user of your CentOS server. Let's use cn=admin,dc=company,dc=com as our super-user.
  • A password to our rootdn user specified by rootpw. Keep in mind that this user has complete control over the OpenLDAP data. So make sure to keep this password in a safe place (such as keepass or gpg). The slappasswd(8C) command will generate a salted SHA password for us. Record the output as we will need it soon (the example below is a fake password not used anywhere).
  • The type of backend database we want and where will it be located? Let's use the Oracle Berkely Database backend and place it into /var/lib/ldap.This directory was created when we installed the openldap-servers package.
  • A few Access Control List (ACL) for the various backend databases. We will build on those later on.
  • Where to write the process ID and the arguments file.
  • Trun on database monitoring.
  • We also remove the pmi.schema as we don't need it.
Before you edit the file, record the output of the slappasswd(8C) command

slappasswd
New password: 
Re-enter new password: 
{SSHA}JGjPUbxyCn7wa/pt8YM5rzK7s/hUGncW

We can now edit the temporary configuration file. One thing to keep in mind is that the order in which the directives appear in the slapd.conf file is important. For example, you must list your database and directory before the suffix and the suffix before the rootdn and rootpw. We need to reorder the include statements for the schemas because some schemas depend on previous ones. If we don't do this reordering, we might end up with slapcat(8) errors like this one :

/etc/openldap/schema/collective.schema: line 65 attributeType: AttributeType not found: "l"
slapcat: bad configuration directory!

vi ~/ldap/slapd.conf.fix

Test our temporary configuration to see if we made any mistakes. It should return "config file testing succeeded". If not, fix any pending errors, they should be obvious.

sudo slaptest -uf ~/ldap/slapd.conf.fix

Run slapcat to generate our cn=config data.

sudo slapcat -f ~/ldap/slapd.conf.fix -F ~/ldap -n 0

This will create the ~/ldap/cn=config.ldif file and the ~/ldap/cn=config directory. Let's test this new configuration to see if it's ok? This should also report "config file testing succeeded".

sudo slaptest -uF ~/ldap

Copy the new file and directory to the appropriate location where slapd(8) expects it and fix permissions. First we need to clear the config that was installed when we installed the openldap-servers package.

sudo mv /etc/openldap/slapd.d /etc/openldap/slapd.d.unused
sudo mkdir /etc/openldap/slapd.d
sudo cp -rp ~/ldap/cn\=config* /etc/openldap/slapd.d
sudo chown -R ldap:ldap /etc/openldap/slapd.d

Before we start slapd, we must first place a Berkley DB configuration file into /var/lib/ldap. The openldap-servers packages includes an example. If we don't have this file and we start slapd(8), it will complain with an error :

bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (2).#012Expect poor performance for suffix "dc=company,dc=com". 

Let's use this one for now.

sudo cp `rpm -ql openldap-servers | grep DB_CONFIG` /var/lib/ldap/DB_CONFIG


Fix permissions on the /var/lib/ldap directory.

sudo chown ldap:ldap /var/lib/ldap
sudo chmod 700 /var/lib/ldap

Edit the slapd(8) system configuration file.

sudo vi /etc/sysconfig/ldap


Configure rsyslogd(8) to send slapd(8) logs into a specific log file. To do this, we only need to add three lines right after the global directives.


Create the new log file.

sudo touch /var/log/slapd.log

Restart rsyslogd(8) so that it knows about this new configuration.

sudo /etc/init.d/rsyslogd restart

Configure logrotate(8) to handle this new log file.

sudo vi /etc/logrotate.d/slapd

Test your logrotate(8) configuration.

sudo logrotate -df /etc/logrotate.conf

One final test of our OpenLDAP configuration before we start the daemon.

sudo slaptest -u
config file testing succeeded

Good! That means we can now start our slapd(8) daemon.

sudo /etc/init.d/slapd start

Take a look at our log file to see if all is ok?

sudo tail /var/log/slapd.log
slapd starting


Check if the appropriate TCP 389 port and the UNIX socket are active?

netstat -alnt | grep :389

tcp        0      0 0.0.0.0:389                 0.0.0.0:*                   LISTEN 
   
netstat -lA unix | grep ldap
unix  2      [ ACC ]     STREAM     LISTENING     116029 /var/run/ldapi


Configure a system-wide LDAP client configuration. This is to simplifiy our life and reduce typing later on. Don't worry about the TLS configurations for now. We will configure them later, but it doesn't hurt to have them in the file at the moment. Don't forget that in this document, the OpenLDAP server's FQDN is alice.company.com. Be sure to change it for your own.


Check if our admin user can connect?

ldapwhoami -WD cn=admin,dc=company,dc=com
Enter LDAP Password:
dn:cn=admin,dc=company,dc=com

Check if our ACLs are ok and that we can see our cn=config suffix?

ldapsearch -xLLLWD cn=admin,dc=company,dc=com -b cn=config dn
Enter LDAP Password:
dn: cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}inetorgperson,cn=schema,cn=config
dn: cn={3}collective,cn=schema,cn=config
dn: cn={4}corba,cn=schema,cn=config
dn: cn={5}duaconf,cn=schema,cn=config
dn: cn={6}openldap,cn=schema,cn=config
dn: cn={7}dyngroup,cn=schema,cn=config
dn: cn={8}java,cn=schema,cn=config
dn: cn={9}misc,cn=schema,cn=config
dn: cn={10}nis,cn=schema,cn=config
dn: cn={11}ppolicy,cn=schema,cn=config
dn: cn={12}kerberos,cn=schema,cn=config
dn: cn={13}schema,cn=schema,cn=config
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}bdb,cn=config
dn: olcDatabase={2}monitor,cn=config

Another ACL check for SASL EXTERNAL users with both UID and GID set to 0. In this test we also test the UNIX socket (i.e. ldapi:///)

sudo ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}inetorgperson,cn=schema,cn=config
dn: cn={3}collective,cn=schema,cn=config
dn: cn={4}corba,cn=schema,cn=config
dn: cn={5}duaconf,cn=schema,cn=config
dn: cn={6}openldap,cn=schema,cn=config
dn: cn={7}dyngroup,cn=schema,cn=config
dn: cn={8}java,cn=schema,cn=config
dn: cn={9}misc,cn=schema,cn=config
dn: cn={10}nis,cn=schema,cn=config
dn: cn={11}ppolicy,cn=schema,cn=config
dn: cn={12}kerberos,cn=schema,cn=config
dn: cn={13}schema,cn=schema,cn=config
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}bdb,cn=config
dn: olcDatabase={2}monitor,cn=config

Excellent! We now have a working OpenLDAP server! The only thing left to do is make sure the daemon starts when we boot our server.

sudo chkconfig slapd on

We can now cross our first goal:
  1. Install OpenLDAP 2.4.
  2. Configure Transport Layer Security (TLS).
  3. Manage users and groups in OpenLDAP.
  4. Configure pam_ldap to authenticate users via OpenLDAP.
  5. Use OpenLDAP as sudo's configuration repository.
  6. Use OpenLDAP as automount map repository for autofs.
  7. Use OpenLDAP as NFS netgroup repository again for autofs.
  8. Use OpenLDAP as the Kerberos principal repository.
  9. Setup OpenLDAP backup and recovery.
  10. Setup OpenLDAP replication.

Transport Layer Security (TLS)


Using TLS is quite mandatory these days. TLS is used to provide integrity and confidentiality protections and to support LDAP authentication using the SASL EXTERNAL mechanism. TLS is defined in RFC4346.

To configure TLS, we need an SSL certificate and key. The certificate needs to be signed by a trusted Certificate Authority (CA) or self-signed if used in a lab.

In this blog post, we will show two different ways of setting up TLS :
  1. Using a self-signed certificate via the openssl command.
  2. Using a self-signed certificate via the CA.pl script.
  3. Using a local CA via the Microsoft Certificate Authority's certuil and certreq commands.
IMPORTANT : You only need to use one of those techniques to configure TLS. Not all of them!


Self-Signed Certificate via the OpenSSL Command


UPDATE : thanks to mousematt for pointing out documentation bugs in this section!
UPDATE : see this excellent blog post on how to do self-signed certificates.

You can setup your own self-signed certificate without using the perl script. Try this :
First, change your umask value so that the new file will have user read and write permissions only.

umask 066

Then, create a self-signed Certificate Authority CA.

openssl req -newkey rsa:2048 -days 3650 -x509 -nodes -out rootca.crt

Next create a CA configuration file.

vim myca.conf

Create a few files referenced in the myca.conf file.

sudo touch /etc/pki/tls/certs/certindex
echo 000a > /tmp/serialfile
sudo mv /tmp/serialfile /etc/pki/tls/certs/serialfile
sudo chown root:root /etc/pki/tls/certs/serialfile

Move the files created with our first openssl command above.

mv privkey.pem /etc/pki/tls/certs/privkey.pem
mv rootca.crt /etc/pki/tls/certs/rootca.crt

Now create a Certificate Signing Request file (hint, that's what the .csr extension means :) Simply answer the various questions. IMHO it's best not to use a challenge password. Why? Well because if you do, then you will need to enter it every time you start the services. And if you write down the password in a wrapper script so that you don't have to enter it manually each time, then it defeats the purpose. Anyway, when prompted for the common name, enter either your machine's FQDN or a CNAME by which the service will be configured by the clients.

openssl req -newkey rsa:1024 -nodes -out alice.company.com.csr -keyout alice.company.com.key

Normally, you would then send this server.csr file to be signed by a real, trusted Certificate Authority (CA). But in our case, we do not want to pay for this service or we don't have an internal CA or it's a dev machine or we just don't care. So we self-sign it with our own CA like this :

openssl ca -batch -config ./myca.conf -notext -in alice.company.com.csr -days 730 -out alice.company.com.crt

We can then place the files in their respective locations. Just make sure you configure your OpenLDAP server with the appropriate paths to where the files are stored. Be sure to change file permissions on them.

chmod 400 alice.company.com.crt
sudo chown ldap:ldap alice.company.com.crt
sudo mv server.pem /etc/pki/tls/certs/alice.company.com.crt

chmod 400 alice.company.com.key
sudo chown ldap:ldap alice.company.com.key
sudo mv privkey.pem /etc/pki/tls/certs/alice.company.com.key

Finally, we update our OpenLDAP server's configuration to let him know where the files are located.

sudo ldapmodify -Y EXTERNAL -H ldapi:/// <<-EOF
dn: cn=config
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/pki/tls/certs/alice.company.com.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/pki/tls/certs/alice.company.com.key
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/pki/tls/certs/rootca.crt
EOF

Now the OpenLDAP server should work with TLS extensions. We can double-check this with the following query :

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i tls

Once that works, we can get rid of the server.csr because we don't need it anymore. So just remove it.

rm alice.company.com.csr

IMPORTANT : At this point, you can go directly to « Test TLS Configuration » below.

Self-Signed Certificate via the CA.pl Script


Thanks to Ambot Lang who provided these instructions.

Optionally modify /etc/pki/tls/openssl.cnf to make your life easier by just pressing the « enter » key when you run the openssl command later. Modify each _default lines.

vi /etc/pki/tls/openssl.cnf

You will edit the _default data to something similar to this : (of course, these are from Ambot Lang, so make sure you edit those to suit your own data :) ) IMPORTANT : make sure to use your current OpenLDAP server's Fully Qualified Host Name in the Common Name value.

Country Name (2 letter code) [PH]:
State or Province Name (full name) [Mindanao]:
Locality Name (eg, city) [Aurora]:
Organization Name (eg, company) [Ambot Lang Bisdak]:
Organizational Unit Name (eg, section) [Mga Lumad]:
Common Name (eg, your name or your server's hostname) [alice.company.com]:
Email Address [root@127.0.0.1]:

Download and use Ambot's xCA.pl script  (an old script but very useful, courtesy of the authors). Place it into the ~/ldap directory.

mv ~/Downloads/xCA.pl ~/ldap

Then create the CA certificate, the server's TLS certificate and key.

cd ~/ldap
rm -Rf CA
rm -f *.pem
./xCA.pl -newca
openssl req -new -nodes -keyout alice.company.com.key -out alice.company.com.pem
./xCA.pl -sign
cp -f alice.company.com.pem /etc/pki/tls/certs
cp -f alice.company.com.key /etc/pki/tls/certs
cp -f CA/cacert.pem /etc/pki/tls/certs

Test to see if the new files work as they should?

openssl s_client -connect `hostname`:636 -showcerts -state -CAfile /etc/pki/tls/certs/cacert.pem

Fix permissions.

sudo chown ldap:ldap /etc/pki/tls/certs/alice.company.com.pem /etc/pki/tls/certs/alice.company.com.key
sudo chown root:root /etc/pki/tls/certs/cacert.pem
sudo chmod 600 /etc/pki/tls/certs/alice.company.com.key

Assuming OpenLDAP is running, add the new configuration.

sudo ldapmodify -Y EXTERNAL -H ldapi:/// <-EOF
dn: cn=config
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/pki/tls/certs/alice.company.com.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/pki/tls/certs/alice.company.com.key
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/pki/tls/certs/cacert.pem
EOF

Now the OpenLDAP server should work with TLS extensions. We can double-check this with the following query :

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i tls

Local CA via the Microsoft Certificate Authority


To use a local CA. To have it signed, we first need to create a TLS certificate signing request and key. We will then have the certificate signing request file signed by a local CA. In this document, we use a local Windows 2003 Certification Service as the trusted CA. Simply because it was available in our production environment. If you're a systems administrator, chances are you will also have one at your site. Of course, any other CA is good, just as long as all the servers and clients agree on who's the trusted CA. One day I would very much like to give OpenCA a try.

So let's go ahead and create the Certificate Signing Request ( .csr) and associated Key ( .key). WARNING : be sure to use the real hostname here and NOT a DNS CNAME. Don't forget to edit this command with your own settings.

openssl req -newkey rsa:2048 -keyout `hostname`.key -nodes -out `hostname`.req -subj /CN=alice.company.com/O=Company/C=CA/ST=QC/L=Montreal


Upload the .req file to the CA machine.
Login to the Windows CA machine and run certuil without options to know what to use with the -config option later.

C:\Documents and Settings\drobilla\Desktop>certutil | find "Config"
  Config:                       `caserver.company.com\Company CA'

We now know that the config is `caserver.company.com\Company CA'. We can now sign the .req file with the Microsoft Certreq command.

certreq -submit -attrib "CertificateTemplate:WebServer" -config "caserver.company.com\Company CA" alice.company.com.req alice.company.com.pem

This will create the alice.company.com.pem file. Keep it handy.
While we're on the Windows CA, if we don't have a copy of the CA's certificate, now's the time to get it. We only need the lines between the BEGIN and END certificate. Copy and paste these lines into a new file called companyCA.crt with the ouput below. The file must contain both the BEGIN and END lines as well. (Note that the file below is not valid and is only there for demonstration purposes).

certutil -v -ca.cert -config "caserver.company.com\Company CA" C:\companyCA.crt

-----BEGIN CERTIFICATE-----
MIIDpjCCA1CgAwIBAgIQEzzFpHh0nbZEfMnwfsX4ZjANBgkqhkiG9w0BAQUFADCB
A1UEBhMCQ0ExDzANBgNVBAgTBlF1ZWJlYzERMA8GA1UEBxMITW9udHJlYWwxEDAO
b24gQ0EwHhcNMDYwNTI0MTQ0MTAxWhcNMTYwNTI0MTQ1MDQwWjCBlDEoMCYGCSqG
SIb3DQEJARYZYWRtaW5pc3RyYXRvckBjYXByaW9uLmNvbTELMAkGA1UEBhMCQ0Ex
DzANBgNVBAgTBlF1ZWJlYzERMA8GA1UEBxMITW9udHJlYWwxEDAOBgNVBAoTB0Nh
cHJpb24xEDAOBgNVBAsTB0NhcHJpb24xEzARBgNVBAMTCkNhcHJpb24gQ0EwXDAN
BgkqhkiG9w0BAQEFAANLADBIAkEAvFSJcicZzL06ZiH3iX74TQjjViH73bn5ax0N
Ay2vyhGwCMUw8DiGVq7xZ3n19HjDgfYJBISf6S3p6smiV6b5qwIDAQABo4IBejCC
AXYwEwYJKwYBBAGCNxQCBAYeBABDAEEwCwYDVR0PBAQDAgFGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFCxt/TUosXol3ngeFlMp/twwB8WVMIIBDgYDVR0fBIIB
BTCCAQEwgb6ggbuggbiGgbVsZGFwOi8vL0NOPUNhcHJpb24lMjBDQSxDTj1lbmNl
bGFkdXMsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZp
y2vZlenopunVBMzPz3VyYXRpb24sREM9Y2FwcmlvbixEQz1jb20/Y2VydGlmaWNh
dGVSZXZvY2F0aW9uTGLZDd9IyxnLp29IamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlv
blBvaW50MD6gPKA6hjhodHRwOi8vZW5jzwXHzhvZlMnHChJpb24uY29tL0NlcnRF
bnJvbGwvQ2FwcmlvbiUyMENBLmNybDAQBgkrBgEEAYI3FQeeaWibadanbGKqhkiG
9w0BAQUFAANBAEqnFfQe8AGPA8/FJURJdgUs0Nb4qGWuGtxJXwJgo/CyS1W+Vi7x
+9/zNtsflae1Czy8O1JI6z9v9tBUKMebRSc=
-----END CERTIFICATE-----

Transfer this companyCA.crt file and the new alice.company.com.pem files to the CentOS machine.

Double-check to see if the new .pem file is good?

openssl verify -purpose sslserver -CAfile companyCA.crt alice.company.com.pem

Now place the certificate, the key and the CA certificate into the /etc/pki/tls/certs directory.

sudo mv alice.company.com.pem alice.company.com.key companyCA.crt /etc/pki/tls/certs

Fix permissions.

sudo chown ldap:ldap /etc/pki/tls/certs/alice.company.com.pem /etc/pki/tls/certs/alice.company.com.key
sudo chown root:root /etc/pki/tls/certs/companyCA.crt
sudo chmod 600 /etc/pki/tls/certs/alice.company.com.key

Check our current cn=config to see if we already have TLS configurations?

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i tls
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
olcTLSVerifyClient: never


Ah ha, so we already have olcTLSVerifyClient: set to never. This is what we want, so we'll leave it as it is. To configure TLS, create an LDIF file with the following data.

vi ~/ldap/tls.ldif

Install these new configurations into our server.

sudo ldapmodify -vY EXTERNAL -H ldapi:/// -f ~/ldap/tls.ldif

Test TLS Configuration


If we query our configuration, we now have our TLS configured.

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i tls
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
olcTLSVerifyClient: never
olcTLSCertificateFile: /etc/pki/tls/certs/alice.company.com.pem
olcTLSCertificateKeyFile: /etc/pki/tls/certs/alice.company.com.key
olcTLSCACertificateFile: /etc/pki/tls/certs/companyCA.crt


Revist the LDAP client configuration file to enable the TLS configs.

Normally with the cn=config setup, we don't have to restart the daemon. But for TLS, I had to. Go figure?

sudo /etc/init.d/slapd restart

Test a TLS encrypted connection to our OpenLDAP server.

ldapsearch -ZxLLLWD cn=admin,dc=company,dc=com -b cn=config -s base

Notice that we didn't have to use any -H ldap://alice.company.com in the previous command. That's because it's now listed in the /etc/openldap/ldap.conf file. We also were able to trust the certificate from alice.company.com because we have the TLS_CACERT configuration in the /etc/openldap/ldap.conf file.

Ok, so far so good. We now have a TLS enabled OpenLDAP server! We can cross our second goal now.
  1. Install OpenLDAP 2.4.
  2. Configure Transport Layer Security (TLS).
  3. Manage users and groups in OpenLDAP.
  4. Configure pam_ldap to authenticate users via OpenLDAP.
  5. Use OpenLDAP as sudo's configuration repository.
  6. Use OpenLDAP as automount map repository for autofs.
  7. Use OpenLDAP as NFS netgroup repository again for autofs.
  8. Use OpenLDAP as the Kerberos principal repository.
  9. Setup OpenLDAP backup and recovery.
  10. Setup OpenLDAP replication.
See you at my next post!

DA+

References


133 comments:

  1. Hi,

    Follow the instructions on a newly installed Centos 6.2 install and always get an error:

    slaptest -uF ~/ldap/cn=config
    slaptest: bad configuration directory!

    Any ideas?

    ReplyDelete
    Replies
    1. If I do slaptest -uF ~/ldap/ it works ok but if I proceed and move the folder into the /etc/openldap folder and do the service restart:

      root@ldap ldap]# service slapd restart
      Stopping slapd: [FAILED]
      DB_CONFIG is not readable by "ldap" [WARNING]
      Checking configuration files for slapd: [FAILED]
      olcDbDirectory: value #0: invalid path: Permission denied
      config error processing olcDatabase={1}bdb,cn=config: olcDbDirectory: value #0: invalid path: Permission denied
      slaptest: bad configuration file!

      Delete
    2. @Anonymous 1 : I think you have a syntax error. If your cn=config.ldif file and cn=config directory live under ~/ldap, then instead of this...

      slaptest -uF ~/ldap/cn=config

      ...you should probably try that :

      slaptest -uF ~/ldap

      DA+

      Delete
    3. @Anonymous 2: you seem to have several permission problems. To fix the issue, simply check that your /var/lib/ldap directory (or whatever the olcDbDirectory: value is) has the proper permissions. They are :

      sudo ls -alF /var/lib | grep ldap
      drwx------ 2 ldap ldap 4096 May 11 07:00 ldap/

      sudo ls -alF /var/lib/ldap/DB_CONFIG
      -rw-r----- 1 ldap ldap 921 May 4 15:42 /var/lib/ldap/DB_CONFIG

      HTH,

      DA+

      Delete
    4. The easiest way to do fix permissions is this :

      sudo chown -R ldap:ldap /var/lib/ldap
      sudo chmod 700 /var/lib/ldap
      sudo chmod 640 /var/lib/ldap/DB_CONFIG

      Then try to start the daemon.

      DA+

      Delete
  2. Hi I am having when i test the conf.

    [N@CENTOS62 ~]$ sudo slaptest -uf ~/ldap/slapd.conf.temp
    /etc/openldap/schema/collective.schema: line 65 attributeType: AttributeType not found: "l"
    slaptest: bad configuration file!

    can any one help thanks!

    ReplyDelete
  3. This type of error is normally due to the order in which your schema are placed inside your ~/ldap/slapd.conf.temp file. Try placing the collective.schema line lower and see what happens.

    ReplyDelete
    Replies
    1. Thanks David.
      I have started the slapd daemon without errors. Wheew.

      Delete
  4. Excellent post. Thank you very much for taking the time to share this.

    ReplyDelete
  5. @mark and Anonymous: Good to know I was of any help :)

    ReplyDelete
  6. Hello David! thank you for your posts! I'm training with LDAP and find your series very helpful and clear. Anyway, I stuck with tls configuration. I've read a lot of documentation, and messed more... Could you please explain TLS section only for linux hosts. How can I configure it only with openssl cmd. Thank you!

    ReplyDelete
  7. Hello once again!
    Got it! Should better read docs. Here is a good description of TLS:
    http://www.openldap.org/pub/ksoper/OpenLDAP_TLS.html#5.1.1
    At first time I can't got, why are U using 2k3 server for CA, and why can i signed it on my own vm =) Anyway thank you! moving to the next post.

    ReplyDelete
  8. Hi Andy,

    Glad you made it! :)

    To answer you question, I'm using a Windows Server 2003 machine as the CA simply because it was there and available.

    You can use any one of those CAs :

    - a commercial CA (i.e. thawte, entrust, verisign, etc).
    - a CA local to your corporation (i.e. a Win2k3 machine, OpenCA, etc)
    - a local CA created via OpenSSL which signs all your SSL or TLS certificates.

    It just happens that at my work we have an Active Directory domain which uses a Windows Server 2003 machine as the CA. Since it was there when I came on board, instead of reinventing the wheel, I used it.

    At my previous job we ran a PKI based on Entrust. So we used that CA instead.

    In the end, the OS or software the CA is based on is not important. What's important is the security of that CA's private key and the fact that all participants (i.e. all certificates) agree that this is the one and only true secure CA.

    Have fun with my other posts! Keep in mind that I'll update them to use DropBox URLs for the files because Blogger has some issues with file formats (extra empty lines and such). It's quite a problem with LDIF files as empty lines are quite important!

    Please let me know if something doesn't work and I'll update my posts :)

    HTH,

    DA+

    ReplyDelete
  9. This comment has been removed by the author.

    ReplyDelete
  10. [updated]
    Applying tls.ldif produced the following error :

    ldap_modify: Other (e.g., implementation specific) error (80)
    additional info: internal error (cannot create file)

    It turns out that this was caused by SELinux.

    When we rename the old /etc/openldap/slapd.d to slapd.d.unused, we get this :

    ls -Z
    drwxr-xr-x. ldap ldap unconfined_u:object_r:etc_t:s0 slapd.d
    drwx------. ldap ldap system_u:object_r:slapd_db_t:s0 slapd.d.unused

    We must fix this using :

    sudo chcon -R -u system_u -t etc_t /etc/openldap/slapd.d

    ReplyDelete
  11. @Jérôme : excellent comment. Thanks for the info. I must admit SELinux is disabled on this host so I never saw the error. I don't have an SELinux enabled machine handy. But from what I remember in my RHCE, we should do this instead, right?

    sudo rm -rf /etc/openldap/slapd.d/*

    The reason I used a mv(1) instead of rm(1) was to keep a backup in case think went wrong. But after so many trials and error, I now know this extra precaution isn't valid anymore :)

    Thanks again,

    DA+

    ReplyDelete
  12. The command

    sudo chmod 640 /var/lib/ldap

    is incorrect. It made slapd start fail. It suffice to make the mode 700.

    ReplyDelete
  13. @Anonymous : you're absolutely right. Thanks, I've updated the post.

    DA+

    ReplyDelete
  14. If I use

    ldapmodify -vWD cn=admin,dc=company,dc=com -H ldapi:/// -f ~/ldap/tls.ldif

    the entries are inserted ok. However, after this, "slaptest -u" or "service slapd restart" all show the annoying warning message:

    PROXIED attributeDescription "DC" inserted.

    This warning is not present if I use this command instead:

    ldapmodify -Y EXTERNAL -H ldapi:/// -f tls.ldif

    It would be nice if someone can explain why this is the case.

    In light of this, I think the latter command should be used in this very helpful blog post.

    ReplyDelete
    Replies
    1. Why I got an error with this if issue this command
      ldapmodify -Y EXTERNAL -H ldapi:/// -f tls.ldif

      ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)

      I'm stuck with this, any reasons what's behind with it? But using ldapadd it's working but I think it different scenario - add or modify
      ldapadd -x -h 192.168.1.1 -D 'cn=admin, dc=company,dc=com' -f tls.ldif

      A little bit confused...

      Delete
    2. @Ambot : Sorry about this. The post originally had the « ldapmodify -vWD cn=admin,dc=company,dc=com -H ldapi:/// -f ~/ldap/tls.ldif » command. But Anonymous here posted that it gave him an error. So I changed the post to use the « ldapmodify -Y EXTERNAL -H ldapi:/// -f tls.ldif » command instead.

      But looking at your problem, it seems like you have to specify the IP address of the server in the command that works with « -h 192.168.1.1 ». Are you sure your OpenLDAP server is listening on a UNIX socket and not only on TCP?

      To verify this, run « netstat -alnA unix | grep ldapi » This should yield an output similar to this :

      unix 2 [ ACC ] STREAM LISTENING 7840 /var/run/ldapi
      unix 3 [ ] STREAM CONNECTED 8682 /var/run/ldapi
      unix 3 [ ] STREAM CONNECTED 8680 /var/run/ldapi
      unix 3 [ ] STREAM CONNECTED 8678 /var/run/ldapi
      unix 3 [ ] STREAM CONNECTED 8676 /var/run/ldapi
      unix 3 [ ] STREAM CONNECTED 8674 /var/run/ldapi
      unix 3 [ ] STREAM CONNECTED 8632 /var/run/ldapi
      unix 3 [ ] STREAM CONNECTED 8630 /var/run/ldapi
      unix 3 [ ] STREAM CONNECTED 8628 /var/run/ldapi
      unix 3 [ ] STREAM CONNECTED 8626 /var/run/ldapi
      unix 3 [ ] STREAM CONNECTED 8624 /var/run/ldapi

      If you don't have this, then double-check the /etc/sysconfig/ldap file. It should have « SLAPD_LDAPI=yes » specified. If SLAPD_LDAPI isn't equal to « yes », then make sure it does and restart the OpenLDAP daemon with « sudo /etc/init.d/slapd restart » and run the netstat command again to be sure the OpenLDAP daemons is now listening on the UNIX socket. If it does, then try the « ldapadd -Y EXTERNAL... » command again and see if it works?

      HTH,

      DA+

      Delete
    3. It seems doesn't work for me either, and the command « netstat -alnA unix | grep ldapi » no results given.

      Regarding with the /etc/sysconfig/ldap everything are yes.
      SLAPD_LDAP=yes
      SLAPD_LDAPI=yes
      SLAPD_LDAPS=yes

      Even using phpldapadmin, i can't use https. Does it mean that ssl or tls is not working?

      Delete
    4. Ah... it's now working.. the problem is on my certificates coz I given a long name of the organization about 40-46 character long.. i can now get

      netstat -alnA unix | grep ldapi
      unix 2 [ ACC ] STREAM LISTENING 37626 /var/run/ldapi

      but this one doesn't work.
      ldapsearch -ZxLLLWD cn=admin,dc=company,dc=com -b cn=config -s base
      ldap_start_tls: Can't contact LDAP server (-1)

      these work with some error(warning at the last) with same results the two commands.
      a) ldapmodify -vWD cn=admin,dc=company,dc=com -H ldapi:/// -f ~/ldap/tls.ldif

      b) ldapmodify -Y EXTERNAL -H ldapi:/// -f tls.ldif

      modifying entry "cn=config"
      ldap_modify: Insufficient access (50)

      Thank you so much David for your fantastic articles. I learned a lot from here, understand a little bit because of your responses on the comments. You're indeed an expert. Keep up. Need to proceed to the next articles. I'm very interested on this topic.

      Delete
    5. @Ambot : whenever you have the « Insufficient access (50) » error, that means you must double-check the ACLs. One of them is preventing you from accessing the cn=config data with read/write permission.

      Be *very* carefull when working with ACLs, you can seriously break your OpenLDAP setup. A good habit to prevent yourself some pain is to simply do this before you update your ACLs :

      sudo /etc/init.d/slapd stop
      sudo tar zcvf /etc/openldap.backup.`date +%Y%m%d`.tar.gz /etc/openldap
      sudo /etc/init.d/slapd start

      That way if your ACL modification gets you into trouble, you can simply revert back to the previous state by doing this :

      sudo /etc/init.d/slapd stop
      sudo mv /etc/openldap /etc/openldap.broken
      sudo tar zxvf /etc/openldap.backup.`date +%Y%m%d`.tar.gz
      sudo /etc/init.d/slapd start

      And then fix your ACL LDIF file ;)

      HTH,

      DA+

      Delete
    6. @Ambot : and thank you very much for the good words! :-D

      Delete
  15. @Anonymous : very interesting. You don't have the « proxied... » error with the external SASL authentication?! I'll update the blog post with it then.

    I did some research on this error and most answers I found were not satisfactory. The LDAP services are still working and so I learned to live with the (annoying) warning.

    Thanks for the good words and for this info!

    DA+

    ReplyDelete
  16. I googled that warning and found this http://www.openldap.org/lists/openldap-technical/200912/msg00152.html.

    Says that it is because the name of the modifier, in this case I guess would be cn=admin,dc=company,dc=com, is outside of cn=config.

    ReplyDelete
    Replies
    1. @jbnewyorker : yes, Thanks. I did find the exact same mailing list archive. And decided to use the advice « it's just a warning, ignore it ».

      I guess we could move the cn=admin user into cn=config and thus use cn=admin,cn=config as the OpenLDAP super-user. But that required quite a bit of work and I was short on time (and, I must admit, short on motivation too).

      But if using -Y EXTERNAL works without warning, then that's a good solution too. I just haven't tried it yet.

      DA+

      Delete
  17. Hi David,

    Thanks for your great post. I have a problem to tls.ldif to cn=config. Here is the error message I got. Please help. Thanks.
    --
    [root@ncv2 openldap]# ldapmodify -vY EXTERNAL -H ldapi:/// -f ~/tsl.ldif
    ldap_initialize( ldapi:///??base )
    SASL/EXTERNAL authentication started
    SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
    SASL SSF: 0
    add olcTLSCertificateFile:
    /etc/pki/tls/certs/ldap1.crt
    modifying entry "cn=config"
    ldap_modify: Inappropriate matching (18)
    additional info: modify/add: olcTLSCertificateFile: no equality matching rule

    ReplyDelete
    Replies
    1. Hello Anonymous,

      > Thanks for your great post.

      Thanks for the good words :)

      > I have a problem to tls.ldif to cn=config. Here is the error message I got. Please help. Thanks.

      Sure! Can you please post the syslog messages that are displayed in /var/log/messages when you issue the ldapmodify statement. They will help us narrow down and fix the problem.

      Cheers,

      DA+

      Delete
    2. Hi David,

      Thanks for the prompt reply. I checked the /var/log/messages, but did not find an entry associated with ldapmodify command. Here I describe what I have done,which may help you narrow down the problem.
      The operating system is CentOS 6.2. I installed openldap and related programs using yum. I already configured ldap to work without tls. I created a key and self signed it. I configured slapd using tls, and checked it with 'ldapsearch -x -ZZ', and got expected return. When I tried to add tls.ldif and got the error message showed in the previous post.

      Delete
    3. Hi David,
      I think I didn't have config database. See the message below.
      Thanks.
      --
      [root@ncv2 ~]# ldapsearch -xLLWD cn=manager,dc=ncv2,dc=com -b cn=config dn
      Enter LDAP Password:
      version: 1

      No such object (32)
      ------[root@ncv2 ~]# ldapmodify -vY EXTERNAL -H ldapi:/// -f ~/tsl.ldif
      ldap_initialize( ldapi:///??base )
      SASL/EXTERNAL authentication started
      SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
      SASL SSF: 0
      add olcTLSCertificateFile:
      /etc/pki/tls/certs/ldap1.crt
      modifying entry "cn=config"
      ldap_modify: Inappropriate matching (18)
      additional info: modify/add: olcTLSCertificateFile: no equality matching rule

      Delete
    4. Hello again,

      Sorry for the late reply, I've been quite busy at work.

      The « No such object (32) » error is sometimes caused by the OpenLDAP ACL which prevents your user to see the data. Try accessing it another way. Such as this :

      ssh your.ldap.server
      sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config dn

      If you have a result instead of the error, then you need to fix your ACLs.

      Let me know how it goes?

      HTH,

      DA+

      Delete
    5. Oh! And can you please post the contents of your tls.ldif file? Sometimes the LDIF files are syntax sensitve.

      Delete
    6. in tls.ldif, change "add" to "replace", for example:
      add: olcTLSCertificateFile
      ==>
      replace: olcTLSCertificateFile

      Delete
    7. Hello harvey,

      Did you try this? Has it fixed your problem?

      Many thanks,

      David

      Delete
    8. It is working you can use "replace" or "add". The only difference is that if not exist the entry you will use "add", it is useful if you make it from scratch. But if you previously done it, you need the word "replace" and want to change you need this coz "add" will get you an error.

      Thanks again.

      Delete
  18. Hello, This tutorial gives me Error using this step:


    sudo slaptest-uF ~ / ldap

    The error is as follows:

    olcAttributeTypes: value # 0 olcAttributeTypes: Syntax not found: ""
    Error processing config cn = {10} pmi, cn = schema, cn = config: olcAttributeTypes: Syntax not found: ""
    slaptest: bad configuration directory!

    Please I need your help.

    ReplyDelete
    Replies
    1. Hello Ing. Tony Medina,

      That's strange, it's the first time someone tells me he has an error at this step. In your post, there seems to be a space between the tilde « ~ » and the forward slash « / ». Maybe that's just a Blogger comment error, but anyways, please make sure there are no spaces there. It should not be « sudo slaptest-uF ~ / ldap » but this « sudo slaptest-uF ~/ldap »

      HTH,

      DA+

      Delete
    2. I had the exact same error message. In my particular case I could 'fix' it by removing the 'include /etc/openldap/schema/pmi.schema' from the config file. Apparently it doesn't work with that schema.

      I hope this helps you as well....

      Delete
    3. Hello Bas van Wetten,

      Interesting, I never included that schema in my blog posts. I double checked my servers and they don't have the pmi.schema.

      Did you manually add the pmi schema? Or was it placed there automagically when you installed the openldap-servers rpm?

      Thanks for the info, it's going to help a lot!

      DA+

      Delete
  19. Hi...

    I am also getting the same error..


    sudo slaptest-uF ~ / ldap

    The error is as follows:

    olcAttributeTypes: value # 0 olcAttributeTypes: Syntax not found: ""
    Error processing config cn = {10} pmi, cn = schema, cn = config: olcAttributeTypes: Syntax not found: ""
    slaptest: bad configuration directory!

    Please I need your help.

    ReplyDelete
    Replies
    1. Hello Malayamanas Panda,

      Ah well, again this error. I'll have to go through my blog post again to fix it. But in your post, there seems to be a space between the tilde « ~ » and the forward slash « / ». Maybe that's just a Blogger comment error, but anyways, please make sure there are no spaces there. It should not be « sudo slaptest-uF ~ / ldap » but this « sudo slaptest-uF ~/ldap »

      Can you try this and let me know if this works?


      HTH,

      Delete
    2. Hi David.

      I have checked without ~ (shortcut for user home directory in bash) and giving full path to the ldap folder path.

      Still no luck

      I think there are some bug in particular version of RPM.

      mine is 2.4.23

      Delete
    3. Hello Malayamanas Panda,

      Check out the above comment from Bas van Wetten. It seems that the latest openldap-servers rpm installs the pmi.schema. That schema causes the error you're getting :

      « Error processing config cn = {10} pmi, cn = schema, cn = config: olcAttributeTypes: Syntax not found: "" »

      You just might be right about the bug in OpenLDAP. Then again, when we don't understand a problem, it's not necessarily a bug.

      Try removing the pmi.schema from your configuration and see if it fixes the problem?

      HTH,

      DA+

      Delete
  20. I noticed that a few values in the LDAP directory seem wrong after the above cn=config work...

    Specifically olcConfigDir is set to /root/ldap/ and olcConfigFile is set to /root/ldap/slapd.conf.temp

    I don't think either are an issue but wanted to raise it and wondering if it can cause any problems down the line?

    ReplyDelete
    Replies
    1. Hello Robert,

      These two values point to the location where you initially built the sldap.conf file which was used to kickstart the cn=config data. For example, mine point to these values :

      olcConfigDir: /export/home/drobilla/slapd.d
      olcConfigFile: slapd.conf.temp

      In the OpenLDAP cn=config schema, they are described like this (with data removed for clarity) :

      NAME 'olcConfigFile' DESC 'File for slapd configuration directives'
      NAME 'olcConfigDir' DESC 'Directory for slapd configuration backend'

      I'm not 100 % sure, but I haven't had any problems with any of those two values while running OpenLDAP.

      HTH,

      DA+

      Delete
  21. Hi David,

    Thanks David for incorporating my comments to your excellent blogs, you awaken my sharingan (a jutsu ni Naruto - colloquial term to knowledge) that's the result. I am happy that I able to contribute in your article.

    Cheers.

    ReplyDelete
    Replies
    1. Hi Ambot,

      My pleasure! Thanks for taking the time to respond :)

      Cheers,

      DA+

      Delete
  22. Hi David,

    Many thanks for the excellent article how-to OpenLDAP that many of us are loss without your incredible knowledge, contribution and lead.


    I kept getting the following error messages when ran:

    # ldapsearch -x -b "dc=domain,dc=com" -ZZ
    ldap_start_tls: Connect error (-11)
    additional info: TLS error -5938:Encountered end of file


    Saw the following error in slapd.log:

    Dec 3 23:04:19 ldapserver slapd[22004]: conn=1006 fd=13 ACCEPT from IP=x.x.x.28:50829 (IP=0.0.0.0:389)
    Dec 3 23:04:19 ldapserver slapd[22004]: conn=1006 op=0 EXT oid=1.3.6.1.4.1.1466.20037
    Dec 3 23:04:19 ldapserver slapd[22004]: conn=1006 op=0 STARTTLS
    Dec 3 23:04:19 ldapserver slapd[22004]: conn=1006 op=0 RESULT oid= err=0 text=
    Dec 3 23:04:19 ldapserver slapd[22004]: conn=1006 fd=13 closed (TLS negotiation failure)


    Any suggestion what cause TLS negotiation failure? I truly appreciated for any tip or hint. None TLS/SSL, it works fine.

    Thanks

    ReplyDelete
    Replies
    1. Hello Anonymous,

      I'd start with this line :

      additional info: TLS error -5938:Encountered end of file

      Hummmm. Looks like either the certificate file is corrupted or the network layer fails somehow. But since we always think that it's the network, I'd check the certificate instead. 50 % of the network administrator's job is to demonstrate that, in fact, the network is operating a peak efficicency ;)

      There are some tools to check if an SSL certificate is valid. In this post I use this to check my certificates :

      openssl verify -purpose sslserver -CAfile companyCA.crt alice.company.com.pem

      Try this on you own certificates and see any errors pop?

      Let me know how it goes, we might have to dig deeper to fix your issue.

      Have fun!

      DA+

      Delete
    2. During the process of generating self-signed cert, I saw error messages... please see below. In addition in the last line, I can't seems to find the newcert.pem file in pwd or /etc/pki/tls/certs or sub-dirs. I don't know if xCA.pl scriptwas working for me. What is the manual process of creating a self-sign cert without using xCA.pl script?

      Many thanks again!


      # openssl req -new -nodes -keyout ldapserver.domain.com.pem -out ldapserver.domain.com.pem
      Generating a 2048 bit RSA private key
      ....+++
      ..........................+++
      writing new private key to 'ldapserver.domain.com.pem'
      -----
      You are about to be asked to enter information that will be incorporated
      into your certificate request.
      What you are about to enter is what is called a Distinguished Name or a DN.
      There are quite a few fields but you can leave some blank
      For some fields there will be a default value,
      If you enter '.', the field will be left blank.
      -----
      Country Name (2 letter code) [US]:
      State or Province Name (full name) []:
      Locality Name (eg, city) []:
      Organization Name (eg, company) []:
      Organizational Unit Name (eg, section) []:
      Common Name (eg, your name or your server's hostname) []:ldapserver.domain.com
      Email Address []:

      Please enter the following 'extra' attributes
      to be sent with your certificate request
      A challenge password []:
      An optional company name []:
      [root@openldap1 cert]# ls
      CA old ldapserver.domain.com.pem tls.ldif xCA.pl
      # ./xCA.pl -sign
      Using configuration from /etc/pki/tls/openssl.cnf
      unable to load CA private key
      140399959799624:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:698:Expecting: ANY PRIVATE KEY
      Signed certificate is in newcert.pem
      #

      Delete
    3. Hi David,

      I think I gotten the certs/key generated correctly. I must enter paraphrase during cert creations. The cert checked out fine.

      # openssl verify -purpose sslserver -CAfile cacert.pem slapdcert.pem
      slapdcert.pem: OK
      #


      Now, I encountered different errors:

      # ldapsearch -x -ZZ -d1 -H ldap://ldapserver.domain.com
      ldap_url_parse_ext(ldap://ldapserver.domain.com)
      ldap_create
      ldap_url_parse_ext(ldap://ldapserver.domain.com:389/??base)
      ldap_extended_operation_s
      ldap_extended_operation
      ldap_send_initial_request
      ldap_new_connection 1 1 0
      ldap_int_open_connection
      ldap_connect_to_host: TCP ldapserver.domain.com:389
      ldap_new_socket: 3
      ldap_prepare_socket: 3
      ldap_connect_to_host: Trying x.x.x.28:389
      ldap_pvt_connect: fd: 3 tm: -1 async: 0
      ldap_open_defconn: successful
      ldap_send_server_request
      ber_scanf fmt ({it) ber:
      ber_scanf fmt ({) ber:
      ber_flush2: 31 bytes to sd 3
      ldap_result ld 0x24c8390 msgid 1
      wait4msg ld 0x24c8390 msgid 1 (timeout 20000000 usec)
      wait4msg continue ld 0x24c8390 msgid 1 all 1
      ** ld 0x24c8390 Connections:
      * host: ldapserver.domain.com port: 389 (default)
      refcnt: 2 status: Connected
      last used: Tue Dec 4 12:15:52 2012


      ** ld 0x24c8390 Outstanding Requests:
      * msgid 1, origid 1, status InProgress
      outstanding referrals 0, parent count 0
      ld 0x24c8390 request count 1 (abandoned 0)
      ** ld 0x24c8390 Response Queue:
      Empty
      ld 0x24c8390 response count 0
      ldap_chkResponseList ld 0x24c8390 msgid 1 all 1
      ldap_chkResponseList returns ld 0x24c8390 NULL
      ldap_int_select
      read1msg: ld 0x24c8390 msgid 1 all 1
      ber_get_next
      ber_get_next: tag 0x30 len 12 contents:
      read1msg: ld 0x24c8390 msgid 1 message type extended-result
      ber_scanf fmt ({eAA) ber:
      read1msg: ld 0x24c8390 0 new referrals
      read1msg: mark request completed, ld 0x24c8390 msgid 1
      request done: ld 0x24c8390 msgid 1
      res_errno: 0, res_error: <>, res_matched: <>
      ldap_free_request (origid 1, msgid 1)
      ldap_parse_extended_result
      ber_scanf fmt ({eAA) ber:
      ldap_msgfree
      TLS: loaded CA certificate file /etc/openldap/certs/cacert.pem.
      TLS: certificate [E=noreply@domain.com,CN=ldapserver.domain.com,O=someorg,O=someorg,L=place,ST=XX,C=US] is valid
      TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
      TLS: error: connect - force handshake failure: errno 21 - moznss error -5938
      TLS: can't connect: TLS error -5938:Encountered end of file.
      ldap_err2string
      ldap_start_tls: Connect error (-11)
      additional info: TLS error -5938:Encountered end of file
      #

      Delete
    4. I had a similar issue. The problem is related to that your OpenLDAP is trying to use NSS. A solution at http://www.openldap.org/lists/openldap-technical/201202/msg00460.html helped me to solve the issue

      Delete
    5. Hi guys,

      The error line I'm interested by is this one :

      TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory

      What's your TLS configuration? Would you mind posting this?

      Cheers,

      DA+

      Delete
    6. Sorry guys and not responded as early as possible (my fellowmen had been hit by the latest Typhoon Bopha - Bagyong Pablo in local).

      I forgot to mention that I used to modify the file /etc/pki/tls/openssl.cnf under CA_default (use search in editor)

      $sudo vi /etc/pki/tls/openssl.cnf

      dir = /etc/pki/CA --> (the default) changed to --> dir /srv/CA
      or it depends on where do you want to store your generated certificate. It is the critical part, coz you still got wrong certificate copied to your ssl location.

      Then you need to have a paraphrase in creating a certificate else generate an errors as experienced.

      To summarize:
      It generate newcert.pem and newreq.pem in your current directory where you run the command and cacert.pem is located in /srv/CA (check the /etc/pki/tls/openssl.cnf for the exact location, the _default mentioned are optional, so that I can just press enter instead of typing the entries, coz it will be asked after after the paraphrase, which is hassle on my side and for retesting).

      If you didn't modify the openssl.cnf then your cacert.pem is located in /etc/pki/CA

      There is manual creating a certificate but there are some error I got, need to verify and further testing before posting. Or you can see the xCA.pl script it's a python (to get it manually.)

      Hope it helps.

      Delete
    7. I also received the errors:
      TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
      TLS: error: connect - force handshake failure: errno 21 - moznss error -5938
      TLS: can't connect: TLS error -5938:Encountered end of file.

      This can be caused by selinux, I resolved this by relabelling the crt and key files with chcon after copying them to /etc/pki/tls/certs/:

      chcon -R -u system_u -t cert_t rootca.crt
      chcon -R -u system_u -t cert_t hostname.key
      chcon -R -u system_u -t cert_t hostname.crt

      Then restarted slapd

      Delete
    8. I don't run SELinux, so I didn't catch that one. Thanks!

      Makes me think I should rewrite this with SELinux enabled...

      Delete
  23. hi ,

    ı try to create self sign certiface.I create xCa.pl and openssl commoand .when i use xCa.pl -sign than i have error like this ;

    [root@ldap xca]# ./xCA.pl -sign
    Using configuration from /etc/pki/tls/openssl.cnf
    Enter pass phrase for /root/ldap/xca/CA/private/cakey.pem:
    newreq.pem: No such file or directory
    139868667844424:error:02001002:system library:fopen:No such file or directory:bss_file.c:355:fopen('newreq.pem','r')
    139868667844424:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:357:
    Signed certificate is in newcert.pem

    could you please give me any advice to solution this error.
    Thanks

    ReplyDelete
  24. Please do from scratch: (referring to Akin comment)
    sudo rm -Rf /root/ldap/xca/CA
    sudo rm -f *.pem
    sudo ./xCA.pl -newca
    sudo openssl req -new -nodes -keyout newreq.pem -out newreq.pem
    sudo ./xCA.pl -sign

    as previous comment, check/edit the /etc/pki/tls/openssl.cnf
    dir = /root/ldap/xca/CA
    #just referring to your posted comments,as your location

    And also one thing just leave blank if it will ask the 'extra' attributes --> just press the 'enter key'.

    Please enter the following 'extra' attributes
    to be sent with the certificate request
    A challenge password []: <--enter
    An optional company name []: <--enter

    Another note your challenge password should be minimum of 4 characters and maximum of 20. Or you can change it in /etc/pki/tls/openssl.cnf (challengePassword_min and challengePassword_max respectively).


    Wishing you all for any helps for my fellowmen whom struck by the typhoon.
    TA..

    ReplyDelete
    Replies
    1. Thanks very much your kindly interest my issue.Everting works success.

      Delete
    2. No worries, my pleasure to help coz before it took me many months to figure it out and lots of research done see my previous comments. But this blog helps me in better understanding of OpenLDAP and the SSL certification which are the important.

      Delete
  25. Thanks for this. I followed it through with the one mistake (I assume) of doing it all logged in as root. I've been a while out of the Linux game and was never a high-level user to begin with. My CentOS 6.3 implementation didn't have my user in sudoers so I found it faster just to run this stuff as root.

    I am trying to quickly get an OpenLDAP server up and running to use as an LDAP proxy to AD for a Cisco IPT deployment.

    I did an ldapadd using an LDIF to create some basic entries so I can confirm a working LDAP before I try doing the Proxy.

    I am now being plagued by "32 No such object" when trying to query LDAP for the entries I made. I can see they are there if I use slapcat, but I can't query them in a search.

    I even wiped the database and recreated it NOT as root, but using sudo instead. But I still have this error. No search on the error comes up with any useful pointers on fixing this.

    Do you have any suggestions short of reinstalling the entire system?

    Thanks.

    ReplyDelete
    Replies
    1. Hi James,

      Please do NOT reinstall all your system. A lot of hard work has been put into it, so let's not destroy everything just yet! :)

      Working as root or via sudo should not pose too much of a difference as far as OpenLDAP is concerned. It's just that IMHO (and as a CISSP) working as root isn't a good idea since there's not trace of what you're doing. While with sudo, all your commands are logged. When you're the only admin, it's not that important. But when you're a team, it becomes very important.

      That being said and looking at your problem, I would check your OpenLDAP Access Control Lists (or ACL for short). Be *very* careful when working with ACLs, as you can seriously break your OpenLDAP setup. A good habit to prevent yourself some pain is to simply do this before you update your ACLs :

      sudo /etc/init.d/slapd stop
      sudo tar zcvf /etc/openldap.backup.`date +%Y%m%d`.tar.gz /etc/openldap
      sudo /etc/init.d/slapd start

      That way if your ACL modification gets you into trouble, you can simply revert back to the previous state by doing this :

      sudo /etc/init.d/slapd stop
      sudo mv /etc/openldap /etc/openldap.broken
      sudo tar zxvf /etc/openldap.backup.`date +%Y%m%d`.tar.gz
      sudo /etc/init.d/slapd start

      And then fix your ACL LDIF file ;)

      HTH,

      DA+

      Delete
    2. Now to learn about how to configure LDAP ACLs. :(

      Does this have anything to do with it:

      In /etc/openldap/slapd.d/cn=config.ldif are the following lines:

      olcConfigFile: /root/ldap/slapd.conf.fix
      olcConfigDir: /root/ldap

      Delete
    3. Hello James,

      Don't worry, OpenLDAP ACLs are not that hard to understand. Please go and read the Kerberos section of this blog post series on OpenLDAP (it's found at http://itdavid.blogspot.ca/2012/05/howto-centos-62-kerberos-kdc-with.html) In the Kerberos section, I talk about how to setup, check, modify and test your ACLs. Be sure to follow my suggestion in my previous answer to you when you work with ACLs.

      Let me know how it goes?

      HTH,

      DA+

      Delete
    4. Oh! And don't confuse the Kerberos ACL file with the OpenLDAP ACLs. They're not related at all. The point here is not to learn how to setup a Kerberos Key Distribution Center, but to learn about the OpenLDAP ACLs.

      Of course, if you'd like to learn Kerberos, that's fine too! :)

      DA+

      Delete
  26. Hi David,

    First of all, thanks for sharing this knowledge!

    I have some difficulties creating certificates, this is my first time so I'm sure I'm making a lot of mistakes :)

    These are the steps I haven taken so far:
    1. openssl req -new -nodes -keyout ldap.inertnal.pem -out ldap.internal.pem
    Generating a 2048 bit RSA private key
    ## This took me to the section below, which I populated ##
    Country Name (2 letter code) [PH]:
    State or Province Name (full name) [Mindanao]:
    Locality Name (eg, city) [Aurora]:
    Organization Name (eg, company) [Ambot Lang Bisdak]:
    Organizational Unit Name (eg, section) [Mga Lumad]:
    Common Name (eg, your name or your server's hostname) [alice.company.com]:
    Email Address [root@127.0.0.1]:

    2. I downloaded the script xCA.pl to ~/ldap
    3. ran the script : perl -w xCA.pl
    I'm getting an error message here......

    Use of uninitialized value $SSLEAY_CONFIG in concatenation (.) or string at xCA.pl line 50.
    Use of uninitialized value $SSLEAY_CONFIG in concatenation (.) or string at xCA.pl line 51.

    Are these the correct steps to take?
    And how can I resolve the error message when I'm running the script.

    Thanks!

    ReplyDelete
    Replies
    1. Hello Anonymous,

      You can try to setup your own self-signed certificate without using the perl script. Try this :

      # First, change your umask value so that the new file will
      # have user read and write permissions only.

      umask 066

      # Then, generate a private RSA key. Keep it secret, keep it safe!

      openssl genrsa -out privkey.pem 2048

      # Now create a Certificate Signing Request file (.csr).
      # Simply answer the various questions. I prefer not to use a
      # challenge password. Why? Well because if you do, then you
      # will need to enter it every time you start the services.
      # When prompted for the common name, enter either your machine's
      # FQDN or a CNAME by which the service will be configured by the
      # clients.

      openssl req -new -key privkey.pem -out server.csr

      # Normally, you would then send this csr file to be signed by a
      # real, trusted Certificate Authority. But in our case, we do not
      # want to pay for this service or we don't have an internal CA
      # or it's a dev machine or we just don't care. So we self-sign it.

      openssl x509 -req -days 1095 -in server.csr -signkey privkey.pem -out server.crt

      # We can then place the files in their respective locations.
      # Just make sure you configure your OpenLDAP server with the appropriate
      # paths to where the files are stored. Be sure to change file
      # permissions on them.

      chmod 400 server.crt
      sudo chown root:root server.crt

      chmod 400 server.key
      sudo chown root:root server.key

      HTH,

      David

      Delete
  27. I'm setting up the TLS with a self-signed cert/key/CA. The ldapmodify is working and I can connect to it via TLS immediately after I add the TLS setting in cn=config but as soon as I restart slapd the setting are gone.
    I'm using CentOS 6.3 and openldap-2.4.23-26.el6_3.2.x86_64, openldap-servers-2.4.23-26.el6_3.2.x86_64, and
    openldap-clients-2.4.23-26.el6_3.2.x86_64

    For example
    # ldapmodify -vY EXTERNAL -H ldapi:/// -f ~/ldap/tls.ldif
    ldap_initialize( ldapi:///??base )
    SASL/EXTERNAL authentication started
    SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
    SASL SSF: 0
    add olcTLSCertificateFile:
    /etc/openldap/certs/secauth1.si-consulting.us.crt
    add olcTLSCertificateKeyFile:
    /etc/openldap/certs/secauth1.si-consulting.us.key
    add olcTLSCACertificateFile:
    /etc/openldap/certs/SIC_CA.crt
    modifying entry "cn=config"
    modify complete

    # ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i tls
    SASL/EXTERNAL authentication started
    SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
    SASL SSF: 0
    olcTLSVerifyClient: never
    olcTLSCertificateFile: /etc/openldap/certs/secauth1.si-consulting.us.crt
    olcTLSCertificateKeyFile: /etc/openldap/certs/secauth1.si-consulting.us.key
    olcTLSCACertificateFile: /etc/openldap/certs/SIC_CA.crt

    And the TLS connection works!!!
    # ldapsearch -ZxLLLWD cn=admin,dc=si-consulting,dc=us -b cn=config -s base
    Enter LDAP Password:
    dn: cn=config
    objectClass: olcGlobal
    cn: config
    olcConfigFile: /etc/openldap/slapd.conf
    olcArgsFile: /var/run/openldap/slapd.args
    ...
    olcTLSVerifyClient: never
    olcToolThreads: 1
    olcWriteTimeout: 0
    olcTLSCertificateFile: /etc/openldap/certs/secauth1.si-consulting.us.crt
    olcTLSCertificateKeyFile: /etc/openldap/certs/secauth1.si-consulting.us.key
    olcTLSCACertificateFile: /etc/openldap/certs/SIC_CA.crt

    But after I restart....
    # service slapd restart
    Stopping slapd: [ OK ]
    Starting slapd: [ OK ]

    It all disappears!!
    # ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i tls
    SASL/EXTERNAL authentication started
    SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
    SASL SSF: 0
    olcTLSVerifyClient: never

    And TLS doesn't work
    # ldapsearch -ZxLLLWD cn=admin,dc=si-consulting,dc=us -b cn=config -s base
    ldap_start_tls: Protocol error (2)
    additional info: unsupported extended operation
    Enter LDAP Password:
    dn: cn=config
    objectClass: olcGlobal
    cn: config
    olcConfigFile: /etc/openldap/slapd.conf
    olcArgsFile: /var/run/openldap/slapd.args
    ....
    olcTLSVerifyClient: never
    olcToolThreads: 1
    olcWriteTimeout: 0

    The DB seems to be getting updated
    # ll /var/lib/ldap/
    total 11480
    -rw-r--r--. 1 ldap ldap 2048 Feb 27 00:09 alock
    -rw-------. 1 ldap ldap 24576 Feb 27 00:09 __db.001
    -rw-------. 1 ldap ldap 9093120 Feb 27 00:09 __db.002
    -rw-------. 1 ldap ldap 335552512 Feb 27 00:09 __db.003
    -rw-------. 1 ldap ldap 2359296 Feb 27 00:09 __db.004
    -rw-------. 1 ldap ldap 753664 Feb 27 00:09 __db.005
    -rw-------. 1 ldap ldap 32768 Feb 27 00:09 __db.006
    -rw-r--r--. 1 root root 921 Feb 26 11:39 DB_CONFIG
    -rw-------. 1 ldap ldap 8192 Feb 26 11:55 dn2id.bdb
    -rw-------. 1 ldap ldap 32768 Feb 26 11:55 id2entry.bdb
    -rw-------. 1 ldap ldap 10485760 Feb 27 00:09 log.0000000001

    Any ideas??
    -Scott

    ReplyDelete
    Replies
    1. Hello Scott,

      That behavior is quite strange. It's the first time I've seen this to be honest. Are the files stored under /etc/openldap/certs still there after the service restart?

      Let's try several different debugging techniques. First, reconfigure your OpenLDAP server with your TLS settings.

      Once that's done, make sure you have good log files in which we can see what's happening during startup, shutdown and binding operations. Since we're debugging, we are going to crank up the debug operations a bit. To do so, edit your /etc/sysconfig/ldap file and add the desired debug flag to SLAPD_OPTIONS. Check out my example ldap file at https://dl.dropbox.com/u/72609528/blog/openldap/etc.sysconfig.ldap for info on which debug code to use. These debug codes will only take effect once we reboot slapd.

      Once that's done and you can bind with TLS enabled, then create a full OpenLDAP backup. Check out bullet point number 9 on this blog series to learn how to perform backup and recovery of your OpenLDAP setup (or go to http://itdavid.blogspot.ca/2012/05/howto-openldap-24-backup-recovery-on.html) The idea is to have a fully TLS configured setup before we restart it. So you don't have to reconfigure everything again and again.

      Once the backup is done, try to launch the init script with the -x switch. Like this :

      sudo sh -x /etc/init.d/slapd stop

      This will debug the startup script itself. DON'T start it just yet. First copy the log file on the side and clean-up the logs. Like this :

      sudo cp /var/log/ldap /var/log/ldap.old
      sudo cp /dev/null /var/log/ldap

      Now in one shell, issue a...

      sudo tail -F /var/log/ldap

      ...and then from another shell, keeping the first one in sight, start the daemon like this :

      sudo sh -x /etc/init.d/slapd start

      Look at the output and try to see if some operation overwrites a file under your cn=config directory?

      And double check your log files. There should now be quite a lot of lines in there. Check them to see what happens. And keep checking them when you issue a ldapsearch with TLS enabled. What's does the logs tell you?

      HTH,

      DA+

      Delete
  28. I don't understand why you have no CA wth the self-signing method.

    Could you explain ?

    Doesn't SSL/LDAP require the olcCACertificateFile to work ?

    I am lost, please help

    ReplyDelete
    Replies
    1. Hello Thms,

      The « self-signing » method does not require an external CA or Certificate Authority because it's a « self-signing » method. Normally, that is, without the « self-signing » method, you would generate a CSR file which stands for Certificate Signing Request. You would then send this CSR to a trusted CA so that it could sign it and return the file as a CRT or CeRTificate. Then when a client would come and try to establish a TLS session with your server, you server would present that CRT file to the client. The client would look at who signed the CRT file, find out that it's an external CA, query that external CA to see if, indeed, he did sign for the CRT file being presented to him and if so, accept the CRT file as legitimate and then proceed with the TLS setup of an encrypted session between the client and your server.

      In the « self-signing » method, there is NO CA because you self-signed it. In other words, there is no trusted third party to vouch for the validity of the certificate your server sends to a client.

      Does that make sense?

      HTH,

      DA+

      Delete
  29. Hello David,
    Brilliant tutorial, thanks!
    I've come unstuck with the TLS section though - I can't make your steps work... In the self-signing section you ask us to
    $ chmod 400 server.key
    but we haven't created a server.key! Or have we? We created a privkey.pem - is that what we should be chmodding? And where's the server.crm gone? Oh I'm so confused. It must be me - nobody else has mentioned it.
    Thanks for any pointers you can give,
    Matt

    ReplyDelete
    Replies
    1. Hello mousematt,

      My mistake! The right file is indeed the « privkey.pem » and not the « server.key » file. I apologize for the confusion and will correct this typo right now.

      I must admit I wrote the self-signed section a bit fast. I'll correct it. Once it's modified, would you be so kind as to test it again and let me know if bugs are still lurking?

      Many thanks,

      David

      Delete
    2. Hi David,
      Thanks for the reply and for confirming my sanity. I'll try it again from scratch now and let you know the results.
      When I asked about the server.crm, I meant of course server.csr, and your reply to Thms above explains that one.
      Once again, thanks for this excellent blog and for taking the trouble to keep it maintained and help us all out!
      All the best,
      Matt

      Delete
    3. Hi David,
      Still a couple of problems:
      1) We have created .pem & .key and moved them to /etc/pki/tls/certs BUT then we go on to specify the path /etc/openldap/certs using ldapmodify. Shouldn't the two paths match?
      2)I think the command << sudo ldapmodify -Y EXTERNAL -H ldapi:/// <-EOF >> might need a gt sign, not lt. At least, it won't work as it is and it will work with lt. However, having said that, the << EOF >> line at the end of the ldapmodify code throws this error:
      ldapmodify: invalid format (line 7) entry: "cn=config"
      which probably doesn't matter.
      3) After issuing the ldapsearch command to test the TLS connection the certificates at /etc/pki/tls/certs are returned as expected (I changed the ldapmodify code to this path - was that right?), but we also get
      olcTLSVerifyClient: never
      Could that explain why, when moving on to the adding users section I get this error when changing passwords:
      ldap_start_tls: Connect error (-11)
      additional info: TLS error -5938:Encountered end of file
      I'll keep working on it!
      All the best,
      Matt

      Delete
    4. This comment has been removed by the author.

      Delete
    5. Hi Matt,

      Yeah, you're right. These paths should match. I'll check the blog document to make sure they do. I'll need to check the TLS error you're having.

      DA+

      Delete
  30. Hi David,

    I am really so thankful to find this post. It's a gem!
    Unfortunately, I am stuck with "Self-Signed Certificate via the OpenSSL Command" part.
    Every command goes well until "sudo ldapmodify -Y EXTERNAL -H ldapi:/// <-EOF".
    it gives me an error:
    bash: -EOF: No such file or directory

    Here is the full prompt before i met the error:

    [root@localhost smile]# umask 066
    [root@localhost smile]# openssl genrsa -out privkey.pem 2048
    Generating RSA private key, 2048 bit long modulus
    ..................................+++
    ..+++
    e is 65537 (0x10001)
    [root@localhost smile]# openssl req -new -key privkey.pem -out server.csr
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    What you are about to enter is what is called a Distinguished Name or a DN.
    There are quite a few fields but you can leave some blank
    For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    -----
    Country Name (2 letter code) [XX]:PH
    State or Province Name (full name) []:Lanao del Norte
    Locality Name (eg, city) [Default City]:Iligan City
    Organization Name (eg, company) [Default Company Ltd]:Internship 2013
    Organizational Unit Name (eg, section) []:Mice
    Common Name (eg, your name or your server's hostname) []:localhost.localdomain
    Email Address []:clint.pacillos@gmail.com

    Please enter the following 'extra' attributes
    to be sent with your certificate request
    A challenge password []:
    An optional company name []:
    [root@localhost smile]# openssl x509 -req -days 1095 -in server.csr -signkey privkey.pem -out server.pem
    Signature ok
    subject=/C=PH/ST=Lanao del Norte/L=Iligan City/O=Internship 2013/OU=Mice/CN=localhost.localdomain/emailAddress=clint.pacillos@gmail.com
    Getting Private key
    [root@localhost smile]# chmod 400 server.pem
    [root@localhost smile]# sudo chown ldap:ldap server.pem
    [root@localhost smile]# sudo mv server.pem /etc/pki/tls/certs/localhost.localdomain.pem
    [root@localhost smile]# chmod 400 privkey.pem
    [root@localhost smile]# sudo chown ldap:ldap privkey.pem
    [root@localhost smile]# sudo mv privkey.pem /etc/pki/tls/certs/localhost.localdomain.key
    [root@localhost smile]# sudo ldapmodify -Y EXTERNAL -H ldapi:/// <-EOF
    bash: -EOF: No such file or directory
    [root@localhost smile]#

    I am very new to Ldap and I am so much looking forward for your help and updates to
    come.

    ReplyDelete
    Replies
    1. Hi Christopher,

      I believe the error comes from the fact that you should have two « << » in front of the « -EOF ». According to the comment you posted, your command is like this :

      sudo ldapmodify -Y EXTERNAL -H ldapi:/// <-EOF

      But it should be like this :

      sudo ldapmodify -Y EXTERNAL -H ldapi:/// <<-EOF

      Try this please and let me know if it works?

      Cheers,

      DA+

      Delete
    2. Ah well, I just realized that it's my own blog post that has this mistake! Sorry about this. I'll correct it right now.

      Also, you might want to use something more descriptive than « localhost.localdomain » for your setup. The real fully qualified domain name of the server is ideal. Or the DNS CNAME you plan to use in the client configurations is also an excellent choice.

      HTH,

      DA+

      Delete
    3. Hi David,

      Thank you so much for a quick reply. Proves that this blog is so much reliable.

      I tried the command "sudo ldapmodify -Y EXTERNAL -H ldapi:/// <<-EOF" and it goes without error. It seem to end when it reads an EOF string, anyway, after the EOF it gives an error that says like this:

      ldap_modify: Inappropriate matching (18)
      additional info: modify/add: olcTLSCertificateFile: no equality matching rule

      thank you so much David.

      Delete
    4. Hi David,

      I am also wondering about the "olcTLSCACertificateFile" thing added in the ldapmodify in the section "Self-Signed Certificate via the CA.pl Script". I am kinda confused why it is not present in the section "Self-Signed Certificate via the OpenSSL Command".

      to point it out more clearly:

      Self-Signed Certificate via the OpenSSL Command:

      sudo ldapmodify -Y EXTERNAL -H ldapi:/// <<-EOF
      dn: cn=config
      add: olcTLSCertificateFile
      olcTLSCertificateFile: /etc/pki/tls/certs/alice.company.com.pem
      -
      add: olcTLSCertificateKeyFile
      olcTLSCertificateKeyFile: /etc/pki/tls/certs/alice.company.com.key
      EOF

      Self-Signed Certificate via the CA.pl Script

      sudo ldapmodify -Y EXTERNAL -H ldapi:/// <-EOF
      dn: cn=config
      add: olcTLSCertificateFile
      olcTLSCertificateFile: /etc/pki/tls/certs/alice.company.com.pem
      -
      add: olcTLSCertificateKeyFile
      olcTLSCertificateKeyFile: /etc/pki/tls/certs/alice.company.com.key
      -
      add: olcTLSCACertificateFile
      olcTLSCACertificateFile: /etc/pki/tls/certs/cacert.pem
      EOF


      I am guessing this is the reason why i get error when i assign a new password for user "nsssproxy". (I actually managed getting to this part "Manage users and groups in OpenLDAP" by using ctrl+d at the end of "ldapmodify").

      The error i get when i issue a new password for nsssproxy is:

      [root@localhost smile]# ldappasswd -xZWD cn=admin,dc=company,dc=com -S cn=nssproxy,ou=users,dc=company,dc=com
      New password:
      Re-enter new password:
      ldap_start_tls: Connect error (-11)
      additional info: TLS error -5938:Encountered end of file
      Enter LDAP Password:
      ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

      This error may apply when issuing new passwords for other users as well.

      Thanks so much for the help.

      Delete
    5. Hi Christopher,

      When you see a construct such as the one using « <<-EOF » you know that, in UNIX, this is called a « here document » You can read on the here documents at http://en.wikipedia.org/wiki/Here_document

      Now, you're having a new error : the no equality matching rule. This is strange. Can you please copy/paste what you're doing when you get to this error? And does your OpenLDAP server has the new configurations? You can check your current cn=config to see if it already has your new TLS configurations with this command :

      sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i tls

      Would you please paste the output of this command?

      And what does the log file says when you run the here document?

      HTH,

      DA+

      Delete
    6. Hi David,

      I think I have missed something prior to this step. I'll work on it from the top and see if I can make it through. I re-installed my CentOS 6.2 to really start it from scratch. I am using CentOS as a virtual machine. Is there any other way I can start from scratch without re-installing my OS in virtual machine? I'll also follow your advise regarding the hostname. Will still continue using this blog, my work have been much more productive using this guide.

      More power!

      Thank you so much David.

      Delete
    7. Good morning Christopher,

      > I am using CentOS as a virtual machine. Is there any other way I can start from scratch
      > without re-installing my OS in virtual machine?

      Of course. Depending on your Hypervisor, you should be able to create VM snapshots. Most hypervisors do (i.e. VMware, VirtualBox). Just prior to the OpenLDAP intall, just take a snapshot of the VM. Then, once you want to restart your setup, instead of starting from scratch, simply revert to the snapshot. Voilà!

      > I'll work on it from the top and see if I can make it through.

      Cool, please let me know if you hit any roadblocks, if I have to modify the blog, I'll do it.

      Good luck and thanks for the good words :)

      DA+

      Delete
    8. I have started it all over from the top and still encountered problems in the "Self-Signed Certificate via the OpenSSL Command" part. Here is the whole prompt until I encountered the error:

      [root@localhost smile]# umask 066
      [root@localhost smile]# openssl genrsa -out privkey.pem 2048
      Generating RSA private key, 2048 bit long modulus
      ....................+++
      ................+++
      e is 65537 (0x10001)
      [root@localhost smile]# openssl req -new -key privkey.pem -out server.csr
      You are about to be asked to enter information that will be incorporated
      into your certificate request.
      What you are about to enter is what is called a Distinguished Name or a DN.
      There are quite a few fields but you can leave some blank
      For some fields there will be a default value,
      If you enter '.', the field will be left blank.
      -----
      Country Name (2 letter code) [XX]:PH
      State or Province Name (full name) []:Lanao del Norte
      Locality Name (eg, city) [Default City]:Iligan City
      Organization Name (eg, company) [Default Company Ltd]:Internship 2013
      Organizational Unit Name (eg, section) []:Mice
      Common Name (eg, your name or your server's hostname) []:smile.domain.com
      Email Address []:clint.pacillos@gmail.com

      Please enter the following 'extra' attributes
      to be sent with your certificate request
      A challenge password []:
      An optional company name []:
      [root@localhost smile]# openssl x509 -req -days 1095 -in server.csr -signkey privkey.pem -out server.pem
      Signature ok
      subject=/C=PH/ST=Lanao del Norte/L=Iligan City/O=Internship 2013/OU=Mice/CN=smile.domain.com/emailAddress=clint.pacillos@gmail.com
      Getting Private key
      [root@localhost smile]# chmod 400 server.pem
      [root@localhost smile]# sudo chown ldap:ldap server.pem
      [root@localhost smile]# sudo mv server.pem /etc/pki/tls/certs/smile.domain.com.pem
      [root@localhost smile]# sudo mv privkey.pem /etc/pki/tls/certs/smile.domain.com.key
      [root@localhost smile]# sudo ldapmodify -Y EXTERNAL -H ldapi:/// > dn: cn=config
      > add: olcTLSCertificateFile
      > olcTLSCertificateFile: /etc/pki/tls/certs/smile.domain.com.pem
      > -
      > add: olcTLSCertificateKeyFile
      > olcTLSCertificateKeyFile: /etc/pki/tls/certs/smile.domain.com.key
      > EOF
      SASL/EXTERNAL authentication started
      SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
      SASL SSF: 0
      modifying entry "cn=config"
      ldap_modify: Other (e.g., implementation specific) error (80)
      additional info: internal error (cannot create file)

      [root@localhost smile]


      Again, thank you David! :)

      Delete
    9. Hello Christopher,

      The command you're running at the very end does not seem to be correct. You posted this...

      sudo ldapmodify -Y EXTERNAL -H ldapi:/// > dn: cn=config

      ...while the correct syntax is this one :

      sudo ldapmodify -Y EXTERNAL -H ldapi:/// <<-EOF

      And from the error listed (i.e. additional info: internal error (cannot create file) ) we can clearly see that the command tries to create the cn=config file because of the redirect (i.e. > dn: cn=config).

      Would you be so kind as to retry the last command with the proper syntax?

      And what does the log file says when your command fails? A good debug trick is to open two terminal windows. In the first one, you issue a « sudo tail -F /path/to/your/ldap/logfile » and in the second one, you try the configuration commands. This way it's easy to spot which lines of log is generated with which commands.

      HTH,

      DA+

      Delete
  31. Hi David,

    Thank you for the prompt reply. As you have told me, i retried issuing the command « sudo sudo ldapmodify -Y EXTERNAL -H ldapi:/// <<-EOF » and entered the addition of olcTLSCertificateFile and olcTLSCertificateKeyFile. I also followed your debugging tip. I still came up with the same error.

    Main terminal prompt:

    SASL/EXTERNAL authentication started
    SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
    SASL SSF: 0
    modifying entry "cn=config"
    ldap_modify: Other (e.g., implementation specific) error (80)
    additional info: internal error (cannot create file)

    Secondary terminal prompt (debugging):

    Apr 15 21:51:19 localhost slapd[1581]: conn=1010 op=1 MOD attr=olcTLSCertificateFile olcTLSCertificateKeyFile
    Apr 15 21:51:19 localhost slapd[1581]: ldif_write_entry: cannot create file for "cn=config": Permission denied
    Apr 15 21:51:19 localhost slapd[1581]: conn=1010 op=2 UNBIND
    Apr 15 21:51:19 localhost slapd[1581]: conn=1010 op=1 RESULT tag=103 err=80 text
    =internal error(cannot create file)
    Apr 15 21:51:19 localhost slapd[1581]: connn=1010 fd=12 closed

    Thanks David :)

    ReplyDelete
    Replies
    1. Hi Christopher,

      We can see that you have permission issues. This line is pretty clear :

      Apr 15 21:51:19 localhost slapd[1581]: ldif_write_entry: cannot create file for "cn=config": Permission denied

      Your OpenLDAP daemon (i.e. slapd) doesn't have the right to write to the OpenLDAP configuration directory tree (i.e. /etc/openldap). Normally, the slapd process runs as the UID ldap and the GID ldap. Make sure you're OpenLDAP configuration directory tree is owned by this user and that it has read/write permissions on the directory. Something like this should help.

      sudo /etc/init.d/ldap stop # Or /etc/init.d/slapd, I don't remember.
      sudo chown -R ldap:ldap /etc/openldap
      sudo find /etc/openldap -type d -exec chmod u+rwx {} \;
      sudo find /etc/openldap -type f -exec chmod u+rw {} \;
      sudo /etc/init.d/ldap start

      Then retry your ldapmodify command and see if that works? Don't forget to use the same debug technique to check the logs as they are created.

      HTH,

      DA+

      Delete
    2. Hi, actually i have this problem too, i tried with this

      sudo /etc/init.d/ldap stop # Or /etc/init.d/slapd, I don't remember.
      sudo chown -R ldap:ldap /etc/openldap
      sudo find /etc/openldap -type d -exec chmod u+rwx {} \;
      sudo find /etc/openldap -type f -exec chmod u+rw {} \;
      sudo /etc/init.d/ldap start

      but the problem is still there.

      Thanks for your time :)

      Delete
  32. This post is great !! But I have a problem , upto 4th step it is working but after that if I try to use "id test.user" from client then it was showing me "user does not exist". That means I am not able to login using any user name which is there in ldap server and I am using centos 6.3.

    ReplyDelete
    Replies
    1. Hello Anonymous,

      Thanks for the good words :)

      Let's check your /etc/nsswitch.conf file. What's the result of this query?

      egrep -i '^passwd:|^shadow:|^group:' /etc/nsswitch.conf

      And do you have both /etc/openldap/ldap.conf and /etc/ldap.conf configured?

      Can you do an ldapsearch with the DN user and password stored in those files and get the contents of the OU which has your users, passwds and groups?

      HTH,

      DA+

      Delete
  33. Thanks for your replay.

    1.the output of the nsswitch file:
    passwd: files ldap
    shadow: files ldap
    group: files ldap
    hosts: files dns
    netmasks: files
    networks: files
    protocols: files
    rpc: files
    services: files ldap
    netgroup: nisplus ldap
    publickey: nisplus
    automount: files ldap
    aliases: files nisplus
    sudoers: files ldap

    2. content of ldap.conf

    BASE dc=suri,dc=com
    URI ldap://centosserver.suri.com
    TLS_CACERT /etc/pki/tls/certs/suri.com.pem
    TLS_REQCERT allow

    3. content of nslcd.conf file:

    uis nslcd
    gid ldap
    # This comment prevents repeated auto-migration of settings.
    uri ldap://centosserver.suri.com
    base dc=suri,dc=com
    binddn cn=admin,dc=suri,dc=com
    bindpw redhat
    rootpwmoddn cn=admin,dc=suri,dc=com
    base group ou=groups,dc=suri,dc=com
    base passwd ou=users,dc=suri,dc=com
    base shadow ou=users,dc=suri,dc=com
    bind_timelimit 5
    timelimit 10
    idle_timelimit 60
    ssl start_tls
    tls_reqcert never
    tls_cacertfile /etc/pki/tls/certs/suri.com.pem
    nss_initgroups_ignoreusers admin,bin,daemon,dbus,ftp
    nss_initgroups_ignoreusers games,gopher,halt,lp,mail,mailnull
    nss_initgroups_ignoreusers nfsnobody,nobody,nscd,nslcd,ntp,operator
    nss_initgroups_ignoreusers panic,qpidd,root,rpc,rpcuser,saslauth
    nss_initgroups_ignoreusers shutdown,smmsp,sshd,sync,uucp,vcsa

    4. I also update system auth file :(as per your blog)

    5. I can able to use ldapsearch command . like..
    "ldapsearch -xWD cn=admin,dc=suri,dc=com -b dc=suri,dc=com"
    an it was a success .

    BUT I AM NOT GATTING ANY SUCCESS WHEN I AM USEING "GETENT" AND "ID" AND "SU" ON SERVE
    as WELL AS IN CLIENT ALSO.

    6. I disable iptables and selinux both on server as well as in client also.

    THANKS!!!

    ReplyDelete
    Replies
    1. Hello,

      Ok, funny question, but I have to ask : did you create the test.user in the ldap server? And if so, is he in the ou=users,dc=suri,dc=com container?

      Also, if you can search the directory with your admin user, but not with any other users, it's quite probably an ACL problem.

      And what does the log file says when your ldapsearch command fails with a normal user? A good debug trick is to open two terminal windows. In the first one, you issue a « sudo tail -F /path/to/your/ldap/logfile » and in the second one, you try the ldapsearch commands. This way it's easy to spot which lines of log is generated with which commands.

      Please try this and post the logs.

      HTH,

      DA+

      Delete
  34. And another thing i.e I am not able to use ldap search with the user whose password stored in database but with admin I can.

    Thanks!!

    ReplyDelete
  35. hi!!
    thanks for replay.
    1. ldapsearch with normal user:
    Apr 24 21:52:46 centosserver slapd[3571]: conn=1021 fd=24 ACCEPT from IP=192.168.0.78:47769 (IP=0.0.0.0:389)
    Apr 24 21:52:46 centosserver slapd[3571]: conn=1021 op=0 EXT oid=1.3.6.1.4.1.1466.20037
    Apr 24 21:52:46 centosserver slapd[3571]: conn=1021 op=0 STARTTLS
    Apr 24 21:52:46 centosserver slapd[3571]: conn=1021 op=0 RESULT oid= err=0 text=
    Apr 24 21:52:46 centosserver slapd[3571]: conn=1021 fd=24 closed (TLS negotiation failure)
    Apr 24 21:53:04 centosserver slapd[3571]: conn=1022 fd=24 ACCEPT from IP=192.168.0.78:47770 (IP=0.0.0.0:389)
    Apr 24 21:53:04 centosserver slapd[3571]: conn=1022 op=0 EXT oid=1.3.6.1.4.1.1466.20037
    Apr 24 21:53:04 centosserver slapd[3571]: conn=1022 op=0 STARTTLS
    Apr 24 21:53:04 centosserver slapd[3571]: conn=1022 op=0 RESULT oid= err=0 text=
    Apr 24 21:53:04 centosserver slapd[3571]: conn=1022 fd=24 closed (TLS negotiation failure)
    Apr 24 21:54:49 centosserver slapd[3571]: conn=1023 fd=24 ACCEPT from IP=192.168.0.78:47771 (IP=0.0.0.0:389)
    Apr 24 21:54:49 centosserver slapd[3571]: conn=1023 op=0 BIND dn="" method=128
    Apr 24 21:54:49 centosserver slapd[3571]: conn=1023 op=0 RESULT tag=97 err=0 text=
    Apr 24 21:54:49 centosserver slapd[3571]: conn=1023 op=1 SRCH base="cn=angshu,dc=suri,dc=com" scope=2 deref=0 filter="(objectClass=*)"
    Apr 24 21:54:49 centosserver slapd[3571]: conn=1023 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=
    Apr 24 21:54:49 centosserver slapd[3571]: conn=1023 op=2 UNBIND
    Apr 24 21:54:49 centosserver slapd[3571]: conn=1023 fd=24 closed

    ReplyDelete
  36. But when I try to use ldapsearch with -ZZ option from client and server, it gives me this..
    Apr 24 21:51:48 centosserver slapd[3571]: conn=1020 op=0 RESULT tag=97 err=0 text=
    Apr 24 21:51:48 centosserver slapd[3571]: conn=1020 op=1 SRCH base="cn=angshu,dc=suri,dc=com" scope=2 deref=0 filter="(objectClass=*)"
    Apr 24 21:51:48 centosserver slapd[3571]: conn=1020 op=2 UNBIND
    Apr 24 21:51:48 centosserver slapd[3571]: conn=1020 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=
    Apr 24 21:51:48 centosserver slapd[3571]: conn=1020 fd=24 closed
    Apr 24 21:52:46 centosserver slapd[3571]: conn=1021 fd=24 ACCEPT from IP=192.168.0.78:47769 (IP=0.0.0.0:389)
    Apr 24 21:52:46 centosserver slapd[3571]: conn=1021 op=0 EXT oid=1.3.6.1.4.1.1466.20037
    Apr 24 21:52:46 centosserver slapd[3571]: conn=1021 op=0 STARTTLS
    Apr 24 21:52:46 centosserver slapd[3571]: conn=1021 op=0 RESULT oid= err=0 text=
    Apr 24 21:52:46 centosserver slapd[3571]: conn=1021 fd=24 closed (TLS negotiation failure)
    Apr 24 21:53:04 centosserver slapd[3571]: conn=1022 fd=24 ACCEPT from IP=192.168.0.78:47770 (IP=0.0.0.0:389)
    Apr 24 21:53:04 centosserver slapd[3571]: conn=1022 op=0 EXT oid=1.3.6.1.4.1.1466.20037
    Apr 24 21:53:04 centosserver slapd[3571]: conn=1022 op=0 STARTTLS
    Apr 24 21:53:04 centosserver slapd[3571]: conn=1022 op=0 RESULT oid= err=0 text=
    Apr 24 21:53:04 centosserver slapd[3571]: conn=1022 fd=24 closed (TLS negotiation failure)

    ReplyDelete
    Replies
    1. Hello again,

      In both of the logs you posted, there is a TLS negotiation failure. You might want to check your TLS configuration.

      Also, in the first post, the bind DN is « BIND dn="" » which means you did not use any user to connect to the ldap server.

      Let's try something. What are the results and logs of these commands when they are executed from the client, not from the server :

      a) ldapsearch -xWD cn=admin,dc=suri,dc=com -b dc=suri,dc=com

      b) ldapsearch -xZZWD cn=admin,dc=suri,dc=com -b dc=suri,dc=com

      Command a) tris a bind without SSL while b) uses SSL. Send me both the command output and the logs they generated.

      HTH,

      DA+

      Delete
  37. Thanks for your replay.
    Here is the out put of a) ldapsearch -xWD cn=admin,dc=suri,dc=com -b dc=suri,dc=com

    Apr 26 15:42:19 centosserver slapd[2429]: @(#) $OpenLDAP: slapd 2.4.23 (Jun 22 2012 13:57:29) $#012#011mockbuild@c6b10.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd
    Apr 26 15:42:19 centosserver slapd[2430]: slapd starting
    Apr 26 15:47:07 centosserver slapd[2430]: conn=1000 fd=13 ACCEPT from IP=192.168.0.93:47591 (IP=0.0.0.0:389)
    Apr 26 15:47:07 centosserver slapd[2430]: conn=1000 op=0 BIND dn="cn=admin,dc=suri,dc=com" method=128
    Apr 26 15:47:07 centosserver slapd[2430]: conn=1000 op=0 BIND dn="cn=admin,dc=suri,dc=com" mech=SIMPLE ssf=0
    Apr 26 15:47:07 centosserver slapd[2430]: conn=1000 op=0 RESULT tag=97 err=0 text=
    Apr 26 15:47:07 centosserver slapd[2430]: conn=1000 op=1 SRCH base="dc=suri,dc=com" scope=2 deref=0 filter="(objectClass=*)"
    Apr 26 15:47:07 centosserver slapd[2430]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=17 text=
    Apr 26 15:47:07 centosserver slapd[2430]: conn=1000 op=2 UNBIND
    Apr 26 15:47:07 centosserver slapd[2430]: conn=1000 fd=13 closed

    NOW THE OUT PUT FOR b) ldapsearch -xZZWD cn=admin,dc=suri,dc=com -b dc=suri,dc=com

    Apr 26 15:48:04 centosserver slapd[2430]: conn=1001 fd=13 ACCEPT from IP=192.168.0.93:47592 (IP=0.0.0.0:389)
    Apr 26 15:48:04 centosserver slapd[2430]: conn=1001 op=0 EXT oid=1.3.6.1.4.1.1466.20037
    Apr 26 15:48:04 centosserver slapd[2430]: conn=1001 op=0 STARTTLS
    Apr 26 15:48:04 centosserver slapd[2430]: conn=1001 op=0 RESULT oid= err=0 text=
    Apr 26 15:48:04 centosserver slapd[2430]: conn=1001 fd=13 closed (TLS negotiation failure)
    Apr 26 15:48:32 centosserver slapd[2430]: conn=1002 fd=13 ACCEPT from IP=192.168.0.93:47593 (IP=0.0.0.0:389)
    Apr 26 15:48:32 centosserver slapd[2430]: conn=1002 op=0 EXT oid=1.3.6.1.4.1.1466.20037
    Apr 26 15:48:32 centosserver slapd[2430]: conn=1002 op=0 STARTTLS
    Apr 26 15:48:32 centosserver slapd[2430]: conn=1002 op=0 RESULT oid= err=0 text=
    Apr 26 15:48:32 centosserver slapd[2430]: conn=1002 fd=13 closed (TLS negotiation failure)

    ReplyDelete
    Replies
    1. Hello again,

      When we compare a) to b), we can clearly see that the TLS connection failure. That means you need to debug your TLS setup. Make sure the client and server have the CA certificate properly configured along with the server's certificate and keys.

      HTH,

      DA+

      Delete
  38. Hello David,
    Thanks you your replay.
    IF I USE "Self-Signed Certificate via the OpenSSL Command" option (which is the first option in your blog)Then where do I find CA certificate.

    Thanks!!!

    ReplyDelete
  39. Hi, just a moment back I was searching for the information on the same topic and now I am here. So much information, really well executed blog. This is really informative and I will for sure refer my friends the same. Thanks
    moving services California

    ReplyDelete
  40. [root@server1 home]# rpm -ql openldap-servers krb5-server-ldap | grep '\.schema$' | sed -e "/README/d" -e "s/^/include /g" | tee -a ~/ldap/slapd.conf.temp

    tee: /root/ldap/slapd.conf.temp: No such file or directory

    ReplyDelete
    Replies
    1. Hi Vetal,

      The tee error your having simply means that the file /root/ldap/slapd.conf.temp does not exist. Either create the directory structure. Like this...

      sudo mkdir /root/ldap

      ...and then run the command again.

      Or, simply send the tee output to another directory. Like /tmp.

      HTH,

      DA+

      Delete
  41. @David,

    thank you for sharing your excellent guide. It was successfully followed on Fedora 17 (soon I'll be going to CentOS).
    It was crystal clear and very smooth...


    Just one point: for those fellows that are facing the issue when they try to test the TLS encrypted connection:

    ldapsearch -ZxLLLWD cn=admin,dc=company,dc=com -b cn=config -s base
    ==============================================================
    ldap_start_tls: Connect error (-11)
    additional info: TLS error -5938:Encountered end of file
    Enter LDAP Password:
    ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
    ==============================================================

    As David pointed at the beginning of the TLS configuration part:

    "IMPORTANT : You only need to use ONE of those techniques to configure TLS. Not all of them!"

    Everything will go smooth till the creation of the ~/ldap/tls.ldif file.

    If you chose to follow the "Self-Signed Certificate via OpenSSL" path, you don't need to create this file, as you already added the olcTLSCertificateFile and olcTLSCertificateKeyFile before and you wont need a CA's certificate.

    the ~/ldap/tls.ldif file will add a CA's certificate (which you did not generate for the self signed cert):

    # This is our local CA's certificate.
    add: olcTLSCACertificateFile
    olcTLSCACertificateFile: /etc/pki/tls/certs/companyCA.crt

    This part is only useful for those whom are following the "Local CA via the Microsoft Certificate Authority" option.

    Hence if you are following the first option, you don't need to create tls.ldif, consequently, neither need to execute
    << sudo ldapmodify -vY EXTERNAL -H ldapi:/// -f ~/ldap/tls.ldif >>, neither add the following line
    << TLS_CACERT /etc/pki/tls/certs/companyCA.crt >> in the file /etc/openldap/ldap.conf

    You are already good to go, and test it with:

    ldapsearch -ZxLLLWD cn=admin,dc=company,dc=com -b cn=config -s base

    In the case you mistakenly followed the "tls.ldif" file step and added it your server, just execute the following in order to remove the olcTLSCACertificateFile attribute:

    sudo ldapmodify -Y EXTERNAL -H ldapi:/// <<-EOF
    dn: cn=config
    delete: olcTLSCACertificateFile
    EOF

    Cheers...
    Andre.

    ReplyDelete
    Replies
    1. @Andre

      Thanks for the good words and the very detailed description. I'll make sure to update the blog post with this!

      Cheers,

      DA+

      Delete
  42. Hi! see i have this problem, but i really don't know what's going on, i hope you can help me.

    [root@resolutionmd-mexico ~]# service slapd start
    Checking configuration files for slapd: [FAILED]
    olcAttributeTypes: value #0 olcAttributeTypes: Syntax not found: ""
    config error processing cn={12}pmi,cn=schema,cn=config: olcAttributeTypes: Syntax not found: ""
    slaptest: bad configuration file!

    ReplyDelete
    Replies
    1. Hello Anonymous,

      Did you read this part of the blog :

      Update! The latest version of OpenLDAP installs the pmi schema. The presence of this schema causes an error when running slaptest later in this tutorial. Since most of us don't need this schema, then we will remove it right here and now by running this command :

      sed -e "/pmi/d" ~/ldap/slapd.conf.temp | tee -a ~/ldap/slapd.conf.fix

      Thanks to Bas van Wetten for pointing this fix.

      HTH,

      David

      Delete
    2. Hey David, thanks for your answer. I skip that step, cause my OpenLDAP version it's not the lastest version and i thought it wasn't necessary.

      Regards

      Delete
  43. Where does one GET a sample slapd.conf in order to start from square-0 in order to even be able to convert to the slapd-config (cn=config) format?

    I am working with CentOS-6.2 + openldap-2.4.23 and I want to set up authentication on a client CentOS-6.2 machine to use my LDAP DIT in which I already have a user record inside.

    Everyonce says its deprecated, the problem is you can't jump from slapd.conf to slapd-config _without_ the slapd.conf to begin with. CentOS-6.2 + openldap-2.4.23 combination does not include slapd.conf.

    So where is square-0, so that I can fight through the rest of the steps to get some progress.

    ReplyDelete
    Replies
    1. Hi Warron,

      A default slapd.conf file is included with the openldap-server rpm. When you install it, you have access to the file. You then modify the default example file to your taste and then convert it to the cn=config setup. I'm doing this here :

      The general idea is to build a startup slapd.conf(5) file and then convert it to the new cn=config setup. List all the new schema files installed on the machine and dump them to a temporary configuration file.

      rpm -ql openldap-servers krb5-server-ldap | grep '\.schema$' | sed -e "/README/d" -e "s/^/include /g" | tee -a ~/ldap/slapd.conf.temp
      rpm -ql sudo | grep -i schema.openldap | sed "s/^/include /g" | tee -a ~/ldap/slapd.conf.temp

      Don't forget to get rid of the PMI configuration as per the blog update.

      HTH,

      DA+

      Delete
  44. Hey! I really want to thank you for your work with this HOWTO. It really help me. Now, i'm a little confuse with TLS, i've done all the steps for Self-Signed Certificate via the OpenSSL Command, but i don't know if i have to create the tls.ldif too and the other steps after that. I'm truly sorry, my english it's not the best and i don't know if i understood at all.

    Thanks for your time.

    Tony


    ReplyDelete
    Replies
    1. Hi Tony,

      Well, makes me think I should revisit the blog to make it clearer. So, when you take a look at the tls.ldif file, it has basically three configurations :

      1) olcTLSCertificateFile: /etc/pki/tls/certs/angel.company.com.pem
      2) olcTLSCertificateKeyFile: /etc/pki/tls/certs/angel.company.com.key
      3) olcTLSCACertificateFile: /etc/pki/tls/certs/companyCA.crt

      Number 1) is the server's certificate that is signed by the CA (or self-signed). It is also known as the .crt file which is created by signing the .csr file (.crl is Certificate Signing Request and .crt is CeRTificate file).

      Number 2) is the key that is required to open the .pem or .crt file listed in number 1). Since this is a key, it has to be kept secret. That's why we fix permissons on this file more tight than the other files.

      Number 3) is the Certificate Authority (CA) certificate. The one that signed the .pem or .crt file listed in number 1). If it's a self-signed certificate, then be sure to distribute the fake CA you used to all the machines in your realm. If not, then place the commercial CA certificate there.

      HTH,

      DA+

      Delete
    2. Hey! Thank you very much David, my LDAP server it's working without problems. So, now i'm facing another problem with my client. See, everything is going well, i have no error codes or problems of any kind, but when i'm using this command "getent passwd test.user". Nothing happened.

      So, my question is, when i created my gruops and my users, have i created in my system, too or just in my ldap directory?

      Thanks again for your time.

      Tony

      Delete
  45. Hi David, great tutorial, helped me to understand the configuration of the TLS
    I used the debian squeeze and it worked perfectly, but instead of openssl use, I used gnutls-bin.
    Anyway, thank you for sharing knowledge and sorry for poor english.
    Adauto

    ReplyDelete
    Replies
    1. Hello Adauto,

      Thanks for the good words, I'm glad I could help. And don't excuse yourself, your english is quite good!

      Cheers,

      DA+

      Delete
  46. Hi David,
    I am unable to add the module ldif . Below is the error.

    [root@host2 cn=config]# ldapadd -x -D cn=Manager,cn=config -W -f /root/ldap/module.ldif
    Enter LDAP Password:
    adding new entry "cn=module,cn=config"
    ldap_add: Protocol error (2)
    additional info: no attributes provided

    [root@host2 cn=config]# cat /root/ldap/module.ldif
    # Add the cn=module configuration.
    dn: cn=module,cn=config

    changetype: add
    modify: cn=module
    objectClass: olcModuleList
    cn: module
    olcModulePath: /usr/lib64/openldap
    olcModuleLoad: accesslog.la
    olcModuleLoad: syncprov.la

    ReplyDelete
    Replies
    1. Hello again,

      The LDIF syntax is very picky. In the post you just sent, there is an empty line between the « dn: cn=module,cn=config » line and the « changetype: add » line. This empty line is the problem. Remove the empty line and try again.

      Also, you state a changetype of « add: » but then you say « modify: » which will confuse LDAP.

      For example, my module.ldif file was :

      # Add the cn=module configuration.
      dn: cn=module,cn=config
      objectClass: olcModuleList
      cn: module
      olcModulePath: /usr/lib/openldap
      olcModuleLoad: accesslog.la
      olcModuleLoad: syncprov.la

      Let me know how it goes?

      HTH,

      David

      Delete
  47. Hello David,
    yet another one who will say that you are doing a fantastic job with this blog - keep it up !

    Coming to my own problem now:

    At this step:
    sudo /etc/init.d/slapd start

    using Fedora 19, I start the deamon through systemctl start (I guess that is not an issue), however I get the below reaction:

    # systemctl status slapd

    slapd.service - OpenLDAP Server Daemon
    Loaded: loaded (/usr/lib/systemd/system/slapd.service; disabled)
    Active: failed (Result: timeout) since Sun 2013-10-27 21:31:21 EET; 2min 48s ago
    Process: 3027 ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS (code=exited, status=0/SUCCESS)
    Process: 2997 ExecStartPre=/usr/libexec/openldap/check-config.sh (code=exited, status=0/SUCCESS)

    Oct 27 21:29:51 shadowfax.dynalink.org systemd[1]: PID file /var/run/openldap/slapd.pid not readable (yet...art.
    Oct 27 21:31:21 shadowfax.dynalink.org systemd[1]: slapd.service operation timed out. Terminating.

    Hope you could figure out how to get out of this mess :)
    Thanks a lot in advance, Greetings from Greece
    Stelios


    ReplyDelete
    Replies
    1. Hello Stelios,

      Thanks for the nice words :)

      Now, I've never worked with a Fedora machine. I'm more used to RedHat/CentOS, Solaris, AIX and FreeBSD systems. So systemctl is new to me. But it's clear that permissions on the /var/run/openldap/slapd.pid file or directory are wrong. I would also look into the (/usr/lib/systemd/system/slapd.service file and see if there's a flag to enable/disable a service in there?

      Another thing you do not mention are log files. Do you have anything in /var/log/messages or /var/log/slapd.log?

      HTH,

      David

      Delete
  48. Hi David,

    after a few coffee cups here is where I am:

    first of all, systemctl is a replacement for init.d so, for Fedora things should be more or less the same.
    It proved they are.

    The issue with the pid was not on security, which I also though off, resulting in even killing selinux from the kernel.

    The problem was that due to copy-paste in the .conf.fix file, I missed one line with dc=example, dc=com pair. Stupid enough to make even openLDAP have a BSOD....

    After correcting this, the deamon launched and is now flying.

    The whole thing proved one thing: That your guidelines are flawless and even replicable to other systems that yours :) Again keep it up, your contributions are clean and neat.

    Stelios

    ReplyDelete
    Replies
    1. Hello Stelios,

      Ah great news! I'm glad you found the error. Indeed, your DIT [1] needs to be the same all the time, otherwise OpenLDAP gets quite confused :)

      Keep up the good work (and don't forget that cup of cofee :)

      Cheers,

      DA+

      [1] http://en.wikipedia.org/wiki/Directory_information_tree

      Delete
  49. Hello David!
    Great guide!
    One thing we encountered was the problem with the .pid-file.
    After checking the slapd.conf.fix we saw that there was an error in the line;
    rootdn cn=admin,dc=company,dc=com
    We changed to:
    rootdn "cn=admin,dc=company,dc=com"
    The syntax-error probably stoped the reading of the file and the .pid was therefore never declared.

    /We

    ReplyDelete
    Replies
    1. Hello Jonas,

      Thanks for the good words, I'm glad you liked it :)

      I've updated the file, so hopefully the next one reading this guide should not have this bug.

      Thanks for reporting it, it's really appreciated!

      Cheers,

      DA+

      Delete
  50. Hi David,

    This is one of the HowTos well written with clear steps together with example of configuration files.
    I would like to say big thanks to you as I learned so much abt krb+ldap after reading your blog!

    And, Merry X'mas to you and your family.

    ReplyDelete
    Replies
    1. Hi LC,

      Thanks! It's a lot of work, but it's worth it.

      And merry Christmas to you and your family as well :)

      David

      Delete
  51. David hello! I thank you so very much for these tutorials. They are very clear and I am learning a lot. When I found your article, I am already set with installing openldap in a debian, but with hdb(and just following steps, without much understanding, so your article is finally teaching me). I'm a real starter on this, would you recommend me to switch to bdb? Is there a reason for one or another? Also. I installed LAM for managing users and groups. I seta couple of groups and users and while ID shows me the right information, and getent group shows me all the local groups and at the end the LDAP groups I created, getent group | grep "user" won't bring anything. Can you show me how to find where am I failing?
    Thank you a lot David.

    Javier Sánchez

    ReplyDelete
    Replies
    1. Hi Javier,

      Thanks for the good words :)

      You have two questions here : a) which OpenLDAP backend should you use and b) why don't you see the username in the getent group call?.

      Let's start by the backend question. I recommend that you read the documentation on this subject : http://www.openldap.org/doc/admin24/backends.html. You will see that it states :

      « hdb is a variant of the original bdb backend which was first written for use with BDB. hdb uses a hierarchical database layout which supports subtree renames. It is otherwise identical to the bdb behavior, and all the same configuration options apply. »

      It also says :

      « Note: The hdb backend has superseded the bdb backend, and both will soon be deprecated in favor of the new mdb backend. See below. »

      Which means, to be fair, that I should rewrite this whole set of OpenLDAP blog to use the mdb backend! :)

      Now for the username in the getent group query :

      In your case, if you can see the OpenLDAP configured groups with the getent(1) command, it doesn't automatically mean that you'll also see the user's name in there. Why? Simple, let's take an example user. When I run the id(1) command, this is what I get :

      [davidr@host] ~ {1002}$ id
      uid=2000(davidr) gid=2000(sysadmin) groups=2000(sysadmin)

      If we then double check the sysadmin group with getent(1), this is what we get :

      [davidr@host] ~ {1006}$ getent group sysadmin
      sysadmin:x:2000:

      See? No davidr user is displayed. That's because the user davidr has a single group which is configured neither in the /etc/group file nor the OpenLDAP group DIT. It's configured in the /etc/passwd file or the OpenLDAP passwd DIT. As we can see here :

      [davidr@host] ~ {1008}$ getent passwd davidr
      davidr:x:2000:2000:David Robillard:/nfs/home/davidr:/bin/bash

      But if we have a user who's part of multiple groups, then we would see him with getent(1). For example, let's check the oracle user. It's default group is oinstall and it's configured in his /etc/passwd or OpenLDAP passwd DIT :

      [davidr@host] ~ {1002}$ id oracle
      uid=800(oracle) gid=800(oinstall) groups=800(oinstall),801(dba),802(asmadm)

      If we check the dba group, which is configured in OpenLDAP, we will see more people there, but not the oracle user.

      [davidr@host] ~ {1006}$ getent group dba
      dba:x:801:alice,bob

      That's because in the OpenLDAP group DIT, we have « memberUid » attributes which point to the other users. Like this :

      [davidr@host] ~ {1026}$ ldapsearch -LLL -b ou=groups,dc=example,dc=com cn=dba
      dn: cn=dba,ou=groups,dc=example,dc=com
      cn: dba
      objectClass: top
      objectClass: posixGroup
      gidNumber: 801
      description: Oracle Database Administrators (DBA)
      memberUid: alice
      memberUid: bob

      See the two memberUid attributes there? That's what gets returned in the getent(1) command previously.

      So, if you want your users to show up in getent(1), simply add them to the groups you desire as memberUid attributes.

      HTH,

      David

      Delete
    2. David thanks a lot for the answers!
      I will read the article as well, excellent resource.
      So, for getents, it is not wrong then. I don't really need users to show up, I saw in a tutorial they do, and I was confused about why they don't in my installation. I'm still learning on how do the name and group resolution work. Thank you very very much David, you really rock.

      Javier Sánchez

      Delete
    3. Glad I could help. Thanks man :)

      Delete