|< Day Day Up >|| |
The previously described installations provide a server speaking with its clients "in clear." This is acceptable if your server is handling data intended for public use. However, you will need to add security protection if the server is handling sensitive data that is not intended to become available for everyone who connects to the server. As mentioned previously, the LDAP protocol knows two ways of securing the conversation between the partners. The term "partners" is used because you need to secure not only the conversation between client and server, but also between server and server, for example, in the case of replication or chaining.
In this section, we will see two brief examples featuring the OpenLDAP and the Sun One servers. Exhibit 12 shows the underlying architecture for a security solution. SSL or TLS is a layer placed on top of the TCP/IP protocol to provide privacy and security that the underlying layers do not offer.
Exhibit 12: SSL/TLS Layer between the TCP/IP Stack and the Application Layer
For both OpenLDAP and Sun One servers, you need the SSL/TLS libraries to get LDAP working above the secure layer. Sun delivers all you need. With the open-source software product OpenLDAP, you have to provide your own security layer. One possible solution would be to use OpenSSL. As the name suggests OpenSSL is also an open-source project. You can get the source code from http://www.openssl.org.
Another security option is to use SASL to secure your server. LDAP (v3)-compliant servers should implement SASL as an extended operation. SASL allows the partners to negotiate the security mechanism used for communication. During the communication, both partners can change their agreements about the security level used, either raising or lowering it. The LDAP server should also provide the client with information about the SASL security mechanisms that it supports.
One of the mechanisms that SASL supports is Kerberos. The Kerberos architecture is a very robust framework that offers to the communicating partners a third authority (security server) that grants tickets to the partners, allowing them to authenticate themselves. In this way, both partners are sure that the other partner really is who it claims to be. To use the Kerberos framework, you have to install Kerberos at your site. You can get the Kerberos software and documentation from http://web.mit.edu/kerberos/www. However, there are restrictions about the use of the software, depending on your physical location and the version of Kerberos you wish to use. At the time of this writing, the most recent version (Kerberos version 5) is available from MIT for residents in Canada or the United States only. The previous version (Kerberos version 4) is available from a number of universities. If you reside outside Canada or the United States and need to run Kerberos version 5 on your network, you can get a distribution from one of the following two locations:
Both of these distributions declare that they are not limited by the export conditions of the United States. Both sites also provide you with the legal background I would recommend that you read carefully.
This section is not intended to be a substitute for the documentation shipped with the Sun One directory server, so we will not get into the specific details of setting up the security mechanisms for the Sun One server. However, this section will give you an idea of how security has to be configured in a commercial software product.
At the time of this writing, the Sun One server is available as version 5.1, which supports only SSL and certificates. SASL can be used if you install a plug-in. Kerberos functionality is not yet available. Version 5.2, which is expected to accommodate both SASL and Kerberos, may be available by the time you read this book. Have a look at the site of Sun Microsystems if you are interested.
Setting up the Sun One directory server to use SSL is very easy because everything you need is shipped with the software. You simply go into the configuration menu of the administration interface and click on the "enable SSL" radio button. You then have to restart the LDAP server. Check the port number for the encrypted directory server. The typical port number for the encrypted LDAP server is 636, but you can change it to whatever you want. However, it is a good idea to keep the standard to avoid the possibility of confusing the clients connecting to the server.
You may also wish to use a certificate on the server to prove to your clients that you really are who you claim to be. The Sun One software has a "certificate wizard" that enables you to make a request to the certificate authority of your choice. The wizard creates an encrypted certificate request that you can either send to the certificate authority (CA) you chose or paste into the online form of a CA. Once you get your certificate, you reopen the administration tool and install the certificate into the server.
The whole process is described in detail in the administrator's guide, also available via the Web from Sun Microsystems. Other commercial software products have similar utilities to install and configure security layers. We used the Sun One software as an example because it was easy to download a trial version. The choice of the Sun One product is not, in any way, intended to imply that this software is better than any other commercial LDAP product.
Setting up security mechanisms in OpenLDAP is not easy because the OpenLDAP server software is not delivered with the necessary libraries. You have a choice of which libraries you want to use. Because the libraries have to be compiled into the OpenLDAP directory-server software, you will have to recompile your directory server if you later decide to use security mechanisms.
The first step in setting up security in OpenLDAP is to get the security software. You can get the various products at the following Web sites:
Each of these software packages ships with "readme" and "install" files, and you should actually read these files before beginning the installation. Like the OpenLDAP software package, all these open-source packages have the same installation steps.
Configure: In this step, the configure procedure tries to detect the hardware and software architecture, the system, and the language libraries installed. It then writes the makefiles. You can give hints and constraints to the configure procedure, for example, the database libraries to use, which compiler to use (the compiler distributed by the vendor of the operating system or the GNU compiler) and other system-dependent information. Do not confuse the configure procedure with the compilation of the software configuration that you will do once the software is installed.
Make: Some software requires a "make depend" first to resolve dependencies for the makefiles. Then you launch the make that actually compiles the software for your particular software and hardware configuration.
Test: Most software also has a test suite allowing you to test what you have compiled. This can be done with a "make test," also called a "make check" in some test suites.
Install: Once you have compiled and tested the software, you can install it with the command "make install."
If you wish to use SASL with the Kerberos authentication method, you have to compile and install Kerberos before you configure the SASL compilation process. Once you have compiled and installed the security software you intend to use, you have to recompile OpenLDAP. To do so, you have to launch the configure process for OpenLDAP. If you are lucky, the "configure" scripts will detect the libraries and include the files of the SSL/TLS or SASL. Or, you may have to use the specific switches:
./configure - with-ssl for SSL/TLS ./configure - with-sasl for SASL
|An important note:|| |
All configure procedures allow you to decide the location for the installed software. The location of the libraries and "include" files are of particular importance. Every system has a standard location where the compiler and linker search the libraries and "include" files. If you use locations not included in the compiler search path, you have to declare this fact to the configure procedure to get the correct "make" files. You will declare two environment variables to achieve this:
For example, let us assume that we have installed the SSL libraries in:
and the SSL "include" files in:
Therefore, you should launch the configure procedure and insert the following:
CPPFLAGS="-I/usr/local/openssl/include" \ LDFLAGS="-L/usr/local/openssl/lib" \ CC=gcc \ ./configure - with-ssl
After the configuration, you have to launch "make depend" and compile the OpenLDAP software with "make." After compilation, you should test out the software using "make test." If all tests finish successfully, you can install the software with "make install."
Note that if you have some libraries in a nonstandard location, it may be that the slapd daemon does not start and the tests will not run. Some of the libraries may be linked dynamically, but only at run time. If the libraries to be linked dynamically are not in standard locations, the link loader needs to know where to find these libraries. You should therefore set the environment variable LD_LIBRARY_PATH before starting the slapd daemon. Remember to set this variable also in your start scripts. Here is an example:
export LD_LIBRARY_PATH=/usr/local/openssl/lib:/usr/local/BerkeleyDB4.2/lib ./slapd
This brief introduction did not cover all aspects of the OpenLDAP installation with SSL/TLS and SASL. If you need more information, there is an excellent description of how to install a security layer under OpenLDAP available at http://www.bayour.com/LDAPv3-HOWTO.html. This page, created and maintained by Turbo Fredriksson, describes where you can get the software, how to install it, and how to configure your OpenLDAP server to use the relevant security mechanisms.
|< Day Day Up >|| |