LDAPv3 – Why bother

One of the main points (for me at least) to use Kerberos together with SSL/TLS was so that I could have a secure and encrypted authentication and communication between the master and slave LDAP server(s) without having passwords etc in cleartext located in files etc.

It is important for security reasons to encrypt all the traffic between the LDAP server and it's clients (or slave servers) because when we grow (that is, more machines are added to the network) all the machines (new and old) where, with OpenLDAP v1.x (here after referred to as OpenLDAP1), accessing the user database on the LDAP server using unencrypted communications. And if the traffic isn't encrypted between the host machine and the database server, any passwords will travel in cleartext on the network when a user tries to login (either to the system, or when binding to the LDAP server in one way or the other).

To try this out, I will demonstrate how you can and (for safety reasons) should have a slave server running on localhost. This replica should (when you consider the implications of user database uptime to be critical) be moved to a separate machine, maybe even doing load balancing. The reason we want to do this, is so that when doing backups of the LDAP database, we don't need to take down the master database, only the read-only replica. This means that we don't have any downtime on the LDAP server itself. This read-only replica, if sitting on a separate machine, can be something as simple as a 486, because the required CPU power is very low, and updated occure quite seldom (only when users change password and when users are added/removed from the system). So any machine you can find in the nearest dumpster will do (as long as it works, that is :)!

Even if you decide to setup a main (ie, master) LDAP server on machine 1, a second (ie, slave) LDAP server on another machine, I still recommend that you have a slave on the first machine. There are no limits on how many slave servers one can use, so it's just as well to have at least one master and one slave on the same machine. As said above, when you want/need more redundancy, it's just a matter of installing a second machine and copy (not move) the database to that machine as well.

In this chapter I will show you a couple of different flows that the information can take, depending on what system we are building, and I will 'prove' that doing it the LDAPv3 way is the best. In these examples, the --> is the communication that takes place over the network (if putting the LDAP server on one, separate, machine, and the Kerberos server on another).

For those of you that more or less picked this book of the shelf, or just wanted to know what all this about LDAP is, without any real intention to implement such a big and quite complicated system on there own home system, I will try to show why anyone would want to go for such a complicated beast as LDAPv3 instead of the UNIX old-timer flatfiles (or NIS/NIS+ for that matter). And if you do have a network (either you own or your company's), but not that many systems, the question can be heard way over here. Why complicate things?

3.1. Papadoc, before conversion

To describe how LDAPv3 is supposed to work, and it's usage, I will give you my real life examples.

I have only one machine at the moment, called papadoc for 'historical' reasons but are currently building a replacement for that. This system 'only' hosts ten private domains, with about 50 users (most of them family and close friends). Having users (and all there relevant information, such as UID/GID number, home directory, passwords, mail address, mail aliases etc, etc) in an LDAP database, using libpam-ldap and libnss-ldap to help authentication, was my main reason for LDAP. Also, I didn't want to have separate user databases (ie, one /etc/passwd file etc on each machine when more machines where added). Be able to structure users in a treelike fashion, to allow for distributed and delegated responsabilities, with the possibility to have a fail over system (an extra LDAP database, or replica) is a very nice feature and to have users authenticate with the same password on all my machines which they have access to. See the accessTo attribute in my LDAP object on page 31 for more about this).

At a previous job, we had the exact same system, but with a lot more domains, a lot more users and finally, a lot more machines. Since this was an ISP, redundancy was vital. So a replica was quickly setup (so that we could have an online backup of the user/mail database). Using round-robin ("poor mans load-balancer") reduced the load of the master database. This system was designed to swallow over 100,000 users with accompanying mail addresses and aliases. It could very well scale beyond that by adding more load-balanced mail servers, and replicated LDAP servers.

3.2. Why use SSL and/or TLS?

Here came (and comes for me to when, not if, I add a second DB or a second machine, be it shell, mail server or other type of system) the first big gripe I had with OpenLDAP1 (that is, a pre-2.x OpenLDAP server). Since OpenLDAP1 don't have built in support for SSL/TLS (or any other secure authentication mechanism), all communication between the master and slave (or by any of the other machines on the network, about 50 or so at last count) is done in cleartext! It's quite easy for someone on the same network segment (yes, EVEN if it's a switched network!) to listen on the communication and retrieving all the passwords etc. This can be avoided to some extent by using external programs to do the SSL tunneling, such as stunnel (see chapter 9, reference material). My experience with this, is that it isn't that reliable. Stunnel dies every now and then, and it's difficult to automate the process. Another big gripe I had, was the fact that the replication DN and password (options replica and bindmethod in the SLAPd configuration file) have to be stored in cleartext in the configuration file. And the third thing is that libpam-ldap is doing the authentication in cleartext as well.

This is, however not true any more since the latest version (v99 at the time of this writing), can be compiled to use SSL for communication encryption and security.

3.2.a. Authentication flow - Using PAM-LDAP

Also imagine adding a second system, or putting the LDAP server on it's own machine. All logins (be it login/imap/pop/ssh/ftp etc) is verified in cleartext between the system and the machine where the LDAP database is residing. Now we have tree machines, the actual server, the master LDAP database and the slave database (or a second login system). Login in this text does refer to a software that does some kind of user authentication, not necessary the program login. All communication back and forth is done in cleartext, giving anyone (basically) the chance to discover the password. The service labeled login here could very well (and would in most situations) be situated on a totally separate machine.

3.3. Why use Kerberos?

But why store the user passwords in the Kerberos database in the first place? Why not just use it for/when we need a replica (or replicas)? We only really need Kerberos so that the communication and authentication is secure between the master LDAP server and it's replica(-s), right? Nope, not quite true. The answer is quite simple actually. Kerberos is designed solely as a secure password storage database (with a secure authentication protocol) on an insecure network. And contrary to popular belief, a local network IS NOT to be considered a secure environment! LDAP, on the other hand, is designed to be a database for distributed, public information, and that means that the security is not 'automatically built in'.

3.3.a. Kerberos replacement software

Put simply, passwords are more secure in a Kerberos database, than in a LDAP ditto (because that is, as I said in the previous paragraph, it's primary design). Besides, with at least MIT Kerberos, there are special Kerberized binaries that replace the original ones. This will give you a more secure way of authentication (you don't have to go through PAM etc). The software to let this be possible, is libnss-ldap. It will get all the public information (such as UID/GID numbers, home directory etc, etc) from LDAP, but look at the Kerberos server for the password. Thus, all sensitive information is encrypted, even before leaving the service. The binaries/services that can be replaced right-out-of-the-box is login, ftpd, ftp, rlogind, rlogin, rshd, rsh, telnetd, telnet and passwd.

3.4. Why use SASL?

Oki, I guess I have convinced you why it is imperative to use SSL/TLS, and we have discussed some of the nice things about Kerberos. But why use SASL? Where does that come into play? Well, when using the combination SASL and Kerberos V (SASL can use other means of storing password, Kerberos is just my choice), we can use a Kerberos V keytab to authenticate securely the master database with the slave. We naturally want this so that there is no arbitrary writing to the slave database. Thus, there is no need for any passwords etc in the slapd configuration file as was needed with OpenLDAP1 and previous. See the section about creating a replication principal on page 58 for more about this. The reason we use SASL, is because SASL is really designed as a middle-layer. That is, it sits between the LDAP server and the authentication system (in this case, Kerberos) much like PAM, with minor differences (see below).

As mentioned, SASL could just as well use any other authentication system, such as the default UNIX way (/etc/passwd, /etc/group etc), it's own database file (usually /etc/sasldb) etc. In theory, it can even use a LDAP database (which might be a little redundant, and difficult do obtain, without creating authentication loops). With a little code writing, it's even possible to use a Kerberos IV server. Some use libpam-smb to look-up the user/password on a Windows PDC.

Simply, SASL is designed as a modular authentication protocol, and it's usage is as a middle-layer. The difference between SASL and PAM (which in many ways resembles each other) is that SASL have integrity and confidentiality protection, while PAM don't have anything like that. It is also (in many's opinion, better and more thought out and well designed).

As said above, we can make SASL store the passwords instead of using Kerberos and we will discuss this matter in section 4.4.e (on page 50). If you want to go this route, and not involve MIT Kerberos V, then please exchange the Kerberos V part in the authentication flows below for SASLdb.

3.4.a. Authentication flow - Full LDAPv3 system

With all this stuff we have discussed (LDAP, SSL/TLS, SASL and Kerberos), we get this flow of authentication (remember the flow, libpam-ldap on page 39?):

If we only want the UID/GID number etc (like when doing ls -l etc), the communication stops at the LDAP server, and don't continue with SASL/Kerberos.

There are still many hops the information have to travel, many of them not that very secure (like PAM).

3.4.b. Authentication flow - using NSS-LDAP and Kerberos V

To minimize this shortcoming, we could replace many (preferably all) of the programs with proper Kerberized binaries (see the section about Kerberos replacement software on page ). That will create the following authentication flow.

Much cleaner, don't you think? A nice feature would be to have SSL/TLS to the libnss-ldap software, but I'm not quite that paranoid yet :). It might already have that option, I just haven't bothered to check...

Update: I just recompiled the libnss-ldap package, and if the OpenSSL development package (libssl09-dev) are installed, libnss-ldap will come with SSL/TLS.

By compiling libnss-ldap with SSL/TLS support, we will get this authentication flow for the public information instead of the one above, using only NSS/NSS-LDAP.

Page 1 from 1

Chapter 3. LDAPv3 – Why bother