The ABCs of LDAP: How to Install, Run, and Administer LDAP Services

In this hook I tried to remain as vendor independent as possible; therefore, I concentrated the discussion on the LDAP protocol and not on a particular implementation of an LDAP server. On the other hand, I repeatedly stated that it is a good idea to start with the open-source implementation of LDAP (OpenLDAP) to start your experiments and to gain a deeper understanding of the LDAP protocol. Chapter 7 demonstrated how to compile, install, and configure OpenLDAP, but there were a few things I did not mention so as not to go too far beyond the scope of the subject of system administration. Therefore, in this appendix I will discuss a few OpenLDAP-specific features that I have found very handy, using the example of a somewhat more complex installation: the back end of OpenLDAP. This also gives me the opportunity to explain how an LDAP proxy server works and how it can be configured. It will also give you a feeling of what an LDAP proxy server can be used for.

The Back End

The OpenLDAP server basically consists of a front end and a back end. The front end is what the client will see, and it runs on the LDAP protocol. The protocol has been the focus of this book, therefore we have not discussed the back end, OpenLDAP, until now; every LDAP implementation consists of the back end. I mentioned it briefly in Chapter 7 when discussing installation. During installation, you have the choice of which database to install "under the LDAP server," i.e., the back end.

In Chapter 7, I stated that you have the choice between ldbm and bdb, but this is not the only choice available for the back end.

To understand what we will achieve with this particular configuration, I will explain first the requirements. We should install a directory that contains global data used enterprisewide and local data used and maintained locally. We will assume that this configuration will be implemented in all the countries in which the enterprise is operating. Therefore, the global part of the data is maintained in a global directory, and the local copies are only replicas of the global data. The local data, however, is maintained locally and may have a different structure in different countries. In a configuration where all traffic of directory clients is directed to the LDAP proxy server, the directory server holding global data is called by the proxy if the client needs data from the global part of the directory information tree; meanwhile the local directory server is called if the proxy server understands that the client needs data held in the local tree.

I will keep the examples very simple, and assume all user-related data is global. There will be global groupings of users expressed in terms of groupOfUniqueNames objects and located on the global server. There can also be local groupings of users expressed in terms of groupOfUniqueNames objects maintained locally. For your specific implementation, check the directory information tree (DIT) of the LDAP servers.

Looking at the DIT, you may wonder why the data partitioning described in Chapter 5 was not used. First of all, you are right: the architecture can be achieved using referrals. The LDAP proxy server, however, does much more, and in this case is required. The LDAP proxy server will rewrite your requests to somewhat suit our requirements. We would like every location to have a branch called "ou=Local Groups" without the need of the client to specify which of the local groups branch it really means. I think it is enough that you contact the local LDAP server and say "local groups." It should be the job of the LDAP proxy server to be aware of the fact that local group means "de" when you are at the Munich site, "UK" when you are at the London site, or "Es" if you are at the site in Madrid (more about the rewrite abilities of the OpenLDAP proxy server later).