Learn the ins and outs of LDAP as well as how to build your own LDAP server in this four-part series. The final installment of the series covers adding security to your OpenLDAP server.
So, you have come back for more OpenLDAP fun (you glutton for punishment, you). Welcome to the final installment of this series, where we'll be discussing how to add security to our OpenLDAP server.
As a quick review of the series, part 1 served as an introduction to the Lightweight Directory Access Protocol, with a breakdown of what the protocol can and cannot do. In part 2 we covered installation and a very basic configuration, while part 3 looked at populating a directory with actual data as well as how to avoid some of the more common showstoppers.
Let's start today's security coverage with a quick look at how to hash your password.
We don't want to store the rootpw in cleartext on the server, so we need to hash it instead. There are several commonly-used hashing methods available via the slappasswd command, including SHA, SSHA, MD5, and CRYPT. CRYPT is the weakest; don't use it. SSHA is the default, and MD5 is good as well. Use slappasswd to generate a nice hashed rootpw:
Re-enter new password:
Now copy & paste this nice fresh hash into /etc/ldap/slapd.conf:
This can be a permanent arrangement. It's fine for a small, simple LAN. An even better solution would be to create an LDAP record that defines the LDAP administrator, and then define access rights for the LDAP admin using ACLs (access control lists) in slapd.conf. Please see the OpenLDAP Administrator's Guide for an excellent chapter on ACLs — it's the best tutorial I've seen on ACLs.
By default, OpenLDAP sends traffic over the network in cleartext, including passwords and logins. Adding encryption foils snoopers and eavesdroppers. To add it, you'll need:
These should already exist on your system. If they're not, first take a minute to cuss and then visit your installation disks or your distribution's Web site to get them. On Debian, look for libssl and libsasl; on RPM-based systems, look for openssl, cyrus-sasl, and cyrus-sasl-md5. (If you feel the need to freak out at this point, go ahead. LDAP is quite complex, so freaking out is an accepted, normal reaction.)
Page 2: Generating a TLS Certificate
Generating a TLS Certificate
First we must generate a server certificate. This is a self-generated certificate for only slapd to use. This method works fine if you don't need to set up a "Certificate Authority" to authorize other certificates and don't need some sort of trusted third-party certificate authority, like Thawte.
Run the following command in the directory that holds slapd.conf. This will generate a new X509 certificate, without a password. It names the certificate slapd_cert.pem, and it names the key slapd_key.pem, and gives it a lifetime of one year:
root@windbag:/etc/ldap/# openssl req -new -x509 -nodes -out slapd_cert.pem -keyout slapd_key.pem -days 365
Generating a 1024 bit RSA private key
writing new private key to 'slapd_key.pem'
Then it asks you a bunch of questions. Go ahead and tell it everything it wants to know. Both of these files must be owned by the the ldap user, which on Red Hat is 'ldap.' (On Debian it's 'root.') Now set your permissions — slapd_cert.pem must be world-readable, and slapd_key.pem must be readable only by the ldap user, and writable by no one.
Edit slapd.conf Yet Again
Next we need to tell slapd where to find these files:
# The base of your directory in database #1
# Where the database file is physically stored for database #1
#TLS keyfile locations
How do you know what ciphers to name? First see what your OpenSSL supports:
$ openssl ciphers -v
This will generate a long, impressive list. The terms used in the example above are wildcards. HIGH means use all ciphers with key lengths longer than 128 bits (MEDIUM = 128 bits). I don't believe we want to use LOW, which includes 56 and 64-bit strengths. (Visit OpenSSL.org to find out more about these things.)
Now we need to restart the ldap daemon. On Red Hat, type:
# /etc/init.d/ldap restart
# /etc/init.d/slapd restart
Page 3: Migrating User Data
This article was originally published on Wednesday Dec 10th 2003
Migrating User Data
There are some lovely scripts provided by PADL Software to ease the chore of populating your LDAP directory. These extract your existing user data and create nice LDAP directory entries. Look for "Migration Tools" on their website. You'll need to edit migrate_common.ph to include your specific network settings.
It doesn't make sense to throw an inordinate burden on the LDAP server by cluttering it with things like /etc/services or /etc/protocols. These are quite static and common to Linux systems; you don't need LDAP to serve them up. Start out with migrating /etc/passwd and /etc/group. I recommend making copies of /etc/passwd and /etc/group, and running the appropriate scripts first on the copies (migrate_group.pl, migrate_passwd.pl).
This will generate .ldif files that you can examine to make sure they're done the way you like. The scripts are easy as pie to use:
# migrate_passwd.pl /etc/passwd passwd.ldif
Then add the .ldif files to the database in the usual manner, via ldapadd:
# ldapadd -x -D "cn=Manager,dc=carlasworld,dc=net" -W -f passwd.ldif
OpenLDAP is a great program. It's also hugely complicated. Hopefully this series has helped you get over the initial speed bumps, and you now have a running server to test and learn on. In Resources I've listed what I've found to be the most helpful resources for understanding the most difficult LDAP components: schema, ACLs, and encryption.
I also recommend looking for useful documentation included with your Linux distribution, as there are a number of variations in the way each distribution installs and configures OpenLDAP, as well as things like TLS and SASL.
Building an Address Book with OpenLDAP
Using OpenLDAP For Authentication; Revision 2 – This is an excellent document that also teaches client configuration
See All Articles by Columnist Carla Schroder