The -nodes switch is important in order to create an unencrypted certificate, so that it will work with LDAP. Again, when asked for the CN, it needs to be the FQDN (fully qualified domain name) of your server, e.g.ldapserver.example.com.

Sign the certificate:/usr/lib/ssl/misc/CA.sh -signcert

Again, do not use a challenge password. The new certificate will be in newcert.pem. (Note: this script looks for the file newreq.pem and signs that; if you have used another file in the certificate creation you will need to rename or copy it.)

If you want Verisign or another Certificate Authority to sign your certificate, the process is easier — you only need step 2, and should leave out the -x509 switch. Check the instructions from your CA as to what you should do with the certificate request.

Once LDAP is installed, you will move the certificate files to the LDAP directory as explained below.

LDAP server setup

The Debian packages you need are libldap2, slapd, ldap-utils, libdb3-dev, and libdb3 (these last two provide the BerkeleyDB database backend). Set the admin password when asked during dpkg-configure.

To use SASL correctly, you need to put the certificates generated above in the correct places:

Note that you must not have comment lines between the ‘access’ and ‘by’ lines in this file, or it won’t work.

The ACLs should also go before the database backend definitions (so they apply globally) — this means that the include slapd.access line in /etc/ldap/slapd.conf must occur before the database backend definitions.

Put this line in /etc/ldap/ldap.conf:

TLS_REQCERT allow

This allows clients to request the TLS server certificate from the server, thus saving you having to copy it everywhere.

You should extract the server key to a keytab other than the system one at /etc/krb5.keytab (this is what the -k flag does), since the LDAP keytab must be owned by the LDAP user. Change the file ownership appropriately.

You also need to ensure that slapd is looking at this keytab. Add the following line to /etc/default/slapd:

export KRB5_KTNAME=/etc/ldap/ldap.keytab

Now, restart slapd.

If there are problems with startup, change the log level in /etc/ldap/slapd.conf to 16383 to get verbose logging in the log file. Change it back before you go into production, as verbose logging makes the server very slow.

Setting up the database

To set up the database, you first use the authentication in the rootdn and rootpw directives, to add the root entry, the People group, and an admin user (e.g. ldapadm — you should have added this user when you set up Kerberos).

For this you need to create a “setup” LDIF file (setup.ldif). You need to choose your base domain, which will depend on your organization. It’s a good idea to use a base domain that is related to your Kerberos domain and also to your IP domain. Here we use dc=example,dc=com.

Add -d 16383 to the ldapsearch line to enable copious debugging output.

Check the permissions on /etc/ldap/cacert.pem — it needs to be world-readable.

Check /etc/hosts if the hostname is resolving incorrectly (this will show up in the debugging output — your client needs to be trying server.example.com, not just server).

If you get the error “Key version for principal in keytable is incorrect”, there is a mismatch between the kerberos keytab and the master server. On the LDAP host, run kadmin -p krbadm and execute the following:

If you get the error “GSSAPI Error: Miscellaneous failure (Permission denied)”, check that the LDAP keytab is readable by the ldap user, and that slapd is looking at the correct keytab. You can test this quickly by also adding ldap/server.example.com to the system keytab at /etc/krb5.keytab and making that world-readable. If that starts things working then your keytab may be the problem. Remember to change it back to root-only afterwards!

Note that having high levels of debugging will slow things down dramatically — turn debugging off or down once things are working. If you are not getting errors, but ldapsearch appears to be hanging, try reducing the log levels in /etc/ldap/slapd.conf and restarting slapd.

Populating the LDAP database

You have many options to populate the database. If you already have users, you’ll want to migrate your data — PADL provide tools (the migrationtools package on Debian). This works fine for regular Unix setup (/etc/passwd, /etc/shadow, /etc/groups), and also for NIS. With some adjustment it will also work for NIS+.

You will, however, need to migrate your passwords to Kerberos by hand. This may be a good time to make everyone change their passwords.

To import an existing database: stop slapd, run slapadd -l existing_database.ldif, and restart slapd (where existing_database.ldif is an LDIF dump of an existing database).

You may need to empty the database first: do this by stopping slapd and removing the contents of the database directory — this is specified in /etc/ldap/slapd.conf by the directory directive.

Remove the rootdn and rootpw entries from slapd.conf, then start and stop slapd again before importing the database. If you have startup problems, check that the database directory is owned by the LDAP user (openldap on Debian).

Finally, you need to make sure that you have no password references in your user database — Kerberos will be handling passwords for you, and the easiest way to make this happen is simply to remove all password references from LDAP.

Run kinit ldapadm, and then use ldapsearch to get the attributes for any user: for example, to search for a user named “jkemp” you’d use ldapsearch ("uid=jkemp"). Look for any password attributes. Then for any individual user, you can create the following ldapmodify file:

It’s important that compat and files entries appear before ldap for passwd, shadow, and group — otherwise if your LDAP server fails (or the client connection to it does) you won’t be able to log in at all. You can use ldap for hosts as well if you prefer.

The last line enables the client to request the server’s certificate, and saves you installing it on every client.

To set up automount to read from LDAP, you need the autofs-ldap package. Note that you want to use files in /etc/nsswitch.conf (as above) rather than ldap — this seems more reliable. Edit /etc/auto.master as follows:

/home ldap:nisMapName=auto_home,dc=example,dc=com

Customize as appropriate for your setup. Here the dn uses nisMapName, which is for automounts which were converted from NIS+. You can also use automountMapName.

To test your setup, try the following on the client:

ldapsearch -d 1 -x

You should see the TLS info at the top and bottom of the debug output (generated with the -d 1 flag). If you have any problems, try specifying the server with -H ldaps://ldapserver.example.com — if this works, check the values in /etc/ldap/ldap.conf.

Finally, test that Kerberos auth is working by typing kinit, then ldapsearch (i.e. without the -x simple bind option).

Now you’re there!

Using LDAP

The basic LDAP commands are ldapadd, ldapmodify, and ldapdelete. Execute kinit ldapadm before any of these, to authenticate yourself.

Run ldapdelete "cn=isis,ou=Hosts,dc=example,dc=com" — you need to specify the DN of the entity you wish to delete.

You can also use ldapdelete -f file, where file contains a list of DNs, one per line, all of which will be deleted in turn.

Your site should now be happily Kerberized and LDAP-ized. You can set up various other applications to use LDAP as a directory server (e.g. mail clients, to get an address book) and Kerberos for authentication (e.g. your Web server).

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.