|
8.2. Configuring an OpenLDAP ServerThe first step in using LDAP as a distributed login database is to get the server software running. This process entails obtaining and installing the software, setting it up to handle your domain, setting encryption options, and running the server. The Section 8.3 will show you how to create a directory that contains all your site's user accounts. 8.2.1. Obtaining and Installing OpenLDAPOpenLDAP's official home page is http://www.openldap.org. You can obtain the OpenLDAP source code from this site, but the OpenLDAP site doesn't host any precompiled binaries. Fortunately, most major Linux distributions provide such binaries, usually under the name openldap or openldap2 (the current OpenLDAP major version number is 2, hence that digit at the end of some OpenLDAP package names). Because most Linux distributions ship with OpenLDAP packages, the assumption in this chapter is that you're installing the server in this way. If you compile the server from source code, you may need to adjust some filesystem directory paths in the coming descriptions because OpenLDAP installs in /usr/local by default, compared to /usr for most precompiled Linux OpenLDAP binaries. Whether you install a binary package or compile OpenLDAP from source code, you may need to install several dependencies. These programs are either required for proper OpenLDAP functioning or are optional tools that OpenLDAP can use to provide improved security or other features:
In addition to these packages, binary distributions are likely to have more mundane dependencies, such as a requirement that glibc be installed. If you're using a tool such as the Advanced Package Tool's (APT's) apt-get (used mainly with Debian but also available for many RPM-based distributions) or Gentoo's emerge, dependencies should be installed automatically when you install OpenLDAP. If you use a lower-level tool such as rpm or dpkg, however, you may see errors about missing dependencies. To correct them, you need to locate and install the dependencies. The OpenLDAP package contains several programs. Only one is the actual server program; others are support tools of various types, including:
You needn't be too concerned about the details of how these programs work just yet. The upcoming pages describe how to use some of them to help create and maintain your OpenLDAP server and an account directory for it. For more information, consult these programs' manpages. One point to note, though, is that the utilities whose names begin with slap operate on the directory that's housed on the local computer; that is, they must be run from the OpenLDAP server computer. The programs whose names begin with ldap, by contrast, are network tools; you can run them on the OpenLDAP server or any of its clients, provided they've been properly configured to refer to the LDAP server. 8.2.2. Basic OpenLDAP ConfigurationOpenLDAP's main server configuration file is slapd.conf. It usually resides in /etc/openldap, but it might appear in another location, particularly if you compile from source.
The slapd.conf file is a typical Linux text-mode configuration file. Hash marks (#) denote comments; lines beginning with this character are ignored. Parameters are identified by name with one or more values following them; equal signs are not used. One unusual feature of the slapd.conf format is that a line that begins with a space is interpreted as a continuation of the preceding line. This convention is used instead of the more common backslash (\) at the end of the first line to denote a line continuation. The slapd.conf file begins with a series of lines that specify the server's overall performancewhat schemas it uses, where it stores its PID number, and so on. Following this global configuration are one or more sections, each beginning with the keyword database, that define directories. Each database section continues until the next database section or until the end of the file. These sections include options that specify the backend database type (the database directive itself does this, in fact), where the database is to be stored, the root of the directory tree, and so on. Consider Example 8-1. This listing is a complete (if simple) slapd.conf file that's suitable for handling an LDAP server that functions solely as a remote authentication system. Example 8-1. A Sample slapd.conf file#### # Global section # Load schemas for storing user accounts include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema # Logging options loglevel 296 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args # TLS options TLSCipherSuite HIGH TLSCertificateFile /etc/openldap/ssl/slapd-cert.crt TLSCertificateKeyFile /etc/openldap/ssl/slapd-key.pem # Set high security security ssf=128 # Miscellaneous security options password-hash {SSHA} # Default access level defaultaccess search #### # Database section database bdb # The root suffix for the directory suffix "dc=pangaea,dc=edu" # The root DN for administration rootdn "cn=Manager,dc=pangaea,dc=edu" # The password used for administrative access rootpw {SSHA}vHVUhjRetxArbQCTPOhyXC1a0s9z3Ej1 # Linux directory housing database files directory /var/lib/ldap/ # Ensure that files may be read ONLY by their owner mode 0600 ## ACLs to control access to the directory # Allow users to authenticate against and modify their own # passwords access to attrs=userPassword by self write by * auth # Allow users to read all non-password data access to * by * read Of course, Example 8-1 is only a starting point; you'll need to customize several of its entries for your system. The meanings of these options are:
Once you've tweaked Example 8-1 for your system, OpenLDAP is basically configured. You must still prepare the TLS certificates, though. Once that's done, you can start the slapd server. 8.2.3. Preparing Keys and CertificatesAlthough it's possible to run an LDAP server without using encryption, doing so is inadvisable, at least when the LDAP server is functioning as a network authentication tool. Encryption keeps your passwords secure; without it, passwords will be sent over the network in cleartext, which makes them susceptible to sniffing.
In Example 8-1, the three lines under the TLS options comment set options related to SSL and TLS encryption, enabling OpenLDAP to engage in encrypted communications. In order for this configuration to work, though, you must first configure the TLS and SSL encryption tool, which is provided by the OpenSSL package (http://www.openssl.org). This package should be a dependency of any binary OpenLDAP package that can use SSL or TLS encryption, and it's also required to compile OpenLDAP with support for these methods of encryption. (If you compile OpenLDAP yourself, you may need to install a separate OpenSSL development package.)
SSL and TLS support a set of encryption tools, some of which require one-time manual preparation before they can be used. Most notable among these are keys and certificates. A key is a numeric code that can encrypt or decrypt data. Once data is encrypted with a key, it can only be decrypted with a matching key. Keys can be generated fairly automatically, but certificates require at least minimal input from users. They're designed to authenticate a site's identity and are essentially files with information on the owner of a server, signed and encrypted with a key that the other system trusts. One type of certificate is created by Certificate Authorities (CAs), which are organizations founded to create certificates for the sake of e-commerce and the like. web sites that use encrypted transmissions usually employ certificates created for them by CAs; web browsers can then decrypt the certificates sent by web sites and verify that they were signed by a trusted CA. If a certificate's signature doesn't check out, the web browser notifies the user that the site might not be trustworthy. For in-house use, though, you don't need to go to a CA; you can create a certificate yourself. The OpenSSL package includes the tools necessary to do so. The simplest and most direct way is to call openssl with a series of options that cause it to generate a certificate and a key: # openssl req -x509 -days 365 -newkey rsa: -nodes \ -keyout slapd-key.pem -out slapd-cert.crt Generating a 1024 bit RSA private key ..........................++++++ .....++++++ writing new private key to 'server.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:RI Locality Name (eg, city) [ ]:Woonsocket Organization Name (eg, company) [Internet Widgits Pty Ltd]:Very Old University Organizational Unit Name (eg, section) [ ]:CS Dept Common Name (eg, YOUR name) [ ]:ldap.pangaea.edu Email Address [ ]:johndoe@pangaea.edu Of course, you should customize the information in the certificate to describe your organization. Pay particular attention to the data you enter at the Common Name (eg, YOUR name) prompt; some clients, including the Windows LDAP authentication client, require this to match the hostname or IP address of the LDAP server. The result of running this command is two files: slapd-key.pem and slapd-cert.crt. These files contain a private key and a public certificate, respectively. Be sure that the private key can be read only by its owner; 600 (rw-------) permissions are appropriate, so type chmod 600 slapd-key.pem to set this file mode. (Some other OpenLDAP files, such as slapd.conf, should be readable to all users, though.) Ordinarily, slapd runs as a specific user (such as ldap, although this username varies from one distribution to another), so you should give ownership of the file to that user. If you run into problems launching the server you should check to see what user is running the server and adjust ownership of this file accordingly. You should now move the sldapd-key.pem and slapd-cert.crt files to the location specified by the TLSCertificateKeyFile and TLSCertificateFile parameters in slapd.conf/etc/openldap/ssl in Example 8-1. 8.2.4. Running the ServerAt this point, it's time to run the server. You can run slapd on a one-time basis by typing the server's filename (you may need to include the full path) or by using a SysV startup script. For instance, on a SuSE system, the SysV startup script is /etc/init.d/ldap, so the following command does the trick: # /etc/init.d/ldap start As you test the server, you're likely to start and stop it frequently. Once it's running the way you want it to run, you'll probably want to configure your system to launch slapd at startup. You can do this as you would any other server that runs constantly. (Typically, slapd is run from a SysV or local startup script, not from a super server.) Typing chkconfig ldap on will do this on many systems, but some distributions use other commands instead of or in addition to chkconfig. Consult distribution-specific documentation if you need help with this task. One problem you may encounter is getting the server to bind to appropriate ports, particularly if you intend to use SSL encryption. By default, slapd binds to port 389, which is used for cleartext connections and those that negotiate TLS encryption after making an initial connection. Some clients, though, including the pGina tool that's described in Section 8.5, must use a dedicated SSL LDAP (that is, LDAPS) encryption port, 636. To force slapd to bind to this port, you must pass an appropriate parameter to the server with the -h option. Passing -h ldap:/// causes slapd to bind to port 389 only, whereas passing -h ldap:/// ldaps:/// causes it to bind to both ports 389 and 636. You may need to modify your slapd SysV startup script to add this option. Some SysV startup scripts, such as the one for SuSE Linux, include a variable in which you can pass these options; in the SuSE script, you edit the SLAPD_URLS variable to include ldaps:///. |
|