Linux Network Administratoramp;#039;s Guide (3rd Edition) [Electronic resources] نسخه متنی

17.2. Obtaining OpenLDAP

The
current home of OpenLDAP is http://www.openldap.org. All current stable
and beta versions can be acquired from this site along with an
"Issue Tracking" engine, should you
encounter any bugs that you wish to report.

While the temptation of downloading and
using beta versions is always there, because of the promise of
increased functionality, unless you are installing the software on a
test server, it is best to use only known stable versions.

Having downloaded and extracted the source archive, it is generally a
good idea to briefly review any README files that may be contained
within the archive. The five minutes spent reading these files can
save five times the initial time investment should there be any
problems during install.

17.2.1. Dependencies

Like many software packages, OpenLDAP is
not without its dependencies. With OpenLDAP, you will need to have
the latest version of OpenSSL installed and configured. If you do not
yet have this package, it can be found at http://www.openssl.org, along with
installation instructions.

SASL from Cyrus is also required for
OpenLDAP. As defined by its name, Simple Authentication and
Security Layer (SASL) provides an easy-to-use security
framework. Many Linux distributions have this package installed by
default; however, should you need to install this yourself, it can be
found at http://asg.web.cmu.edu/sasl/sasl-libraryl
or by using a package search engine such as RPMfind.

OpenLDAP supports Kerberos as an option
rather than a requirement. If you are currently using Kerberos in
your environment, you will want to make sure that you have it
installed on your OpenLDAP server machine. If you're
not currently using Kerberos, it may not be of great value to enable
it especially for OpenLDAP. There is a great deal of Kerberos
information available on which you can base your decision as to
whether or not to enable it.

Another optional component is
for the OpenLDAP backend database (BDB). In order to use BDB, you
will need something like the BerkeleyDB from Sleepycat Software. This
is a very commonly used package that is often installed by default on
many Linux distributions. If your system does not have this
installed, you can find it at http://www.sleepycat.com. Alternately, other
BDBs exist; for example, MySQL may be appropriate in your
environment. It is important to note that this is a matter of
personal preference, and for most users the default OpenLDAP database
is acceptable.

17.2.2. Compiling OpenLDAP

Building OpenLDAP is fairly
straightforward once you have selected the options you wish to have
built into the software. A list of available options can be retrieved
with the configure program. One option that you
may wish to enable is -with-tls. This will
enable SSL support in OpenLDAP, which we will discuss later in this
chapter.

vlager# ./configure -with-tls
Copyright 1998-2003 The OpenLDAP Foundation,  All Rights Reserved.
Restrictions apply, see COPYRIGHT and LICENSE files.
Configuring OpenLDAP 2.1.22-Release ...
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking for a BSD compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gnutar... no
checking for gtar... no
.
.
vlager#

After configuring the
makefile, the next step is to attempt to compile
the package. With most software, the next step is to run
make. However, it is recommended when building
OpenLDAP to run a make depend first. The
configure script will even remind you of this, should you forget.

When the dependencies have been built,
you can now safely issue the make command and
wait for the software to build. Upon completion, you may wish to
verify that the build process has completed properly. Using
make test will run a series of checks and inform
you of any problems with the build.

Assuming all has gone successfully, you
can now become root and install the software automatically by using
the make install option. By default, OpenLDAP will place its
configuration files in /usr/local/etc/openldap.
Users of some distributions will choose to have these files placed in
/etc/openldap for consistency. The option to do
this should be set in the ./configure command
line.

17.2.3. Configuring the OpenLDAP Server

If you were watching the installation
of the software, you may have noticed that it created two programs,
slapd and slurpd. These are
the two daemons used with an OpenLDAP installation.

The
first step in understanding how to configure the OpenLDAP server is
to look at its configuration files. On our sample host, vlager, we have placed the configuration
scripts in the /usr/local/etc/openldap
directory. Looking at the slapd.conf file, we
see a few places that must be customized. It will be necessary to
update any of the following values to make them consistent with your
site:

include        /usr/local/etc/openldap/schema/core.schema
include        /usr/local/etc/openldap/schema/cosine.schema
include        /usr/local/etc/openldap/schema/inetorgperson.schema
database        ldbm
suffix        "o=vbrew"
suffix        "dc=ldap,dc=vbrew,dc=com"
rootdn        "cn=JaneAdmin,o=vbrew"
rootpw        secret
directory        /usr/local/var/openldap-vbrew
defaultaccess    read
schemacheck        on
lastmod        on

You should also change the
rootpw from secret to something
that makes sense to you. This is the password you will need to use to
make changes to your LDAP directory.

With these changes made, you are now ready to run the OpenLDAP
server, which we will discuss in the next section.

17.2.4. Running OpenLDAP

The
standalone OpenLDAP server is called slapd and,
if you have not changed any of the default paths, it will have
installed in /usr/local/libexec/. This program
simply listens on the LDAP port (TCP 389) for incoming connections,
and then processes the requests accordingly. Since this process runs
on a reserved port, you will need to start it with root privileges.
The quickest way to do this is as follows:

vlager# su root -c /usr/local/libexec/slapd

To verify that the service has started, you can use
netstat to see that it is listening on port 389:

vlager# netstat -aunt | grep 389
tcp        0      0 0.0.0.0:389              0.0.0.0:*          LISTEN

At this
point, you should also verify that the service itself is working by
issuing a query to it using the ldapsearch
command:

vlager# ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
version: 2
#
# filter: (objectclass=*)
# requesting: namingContexts
#
#
dn:
namingContexts: dc=vbrew,dc=com
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
vlager#

This
query is designed to do a wildcard search on your database; it should
therefore retrieve everything stored within. If your configuration
was completed properly, you will see your own domain name in the
dc field.

17.2.4.1 Adding entries to your directory

Now that the LDAP server is operational, it
makes sense to add some entries. OpenLDAP comes with a utility called
ldapadd, which inserts records into your LDAP
database. The program only accepts additions from LDAP Data
Interchange files (LDIF), so in order to add a record, you will need
to create this file. More information about the LDIF file format can
be found in RFC 2849. Fortunately, creating LDIF files is a very easy
stepa sample file looks like:

# Organization for Virtual Brewery Corporation
dn: dc=vbrew,dc=com
objectClass: dcObject
objectClass: organization
dc: example
o: VirtualBrew Corporation
description: The Virtual Brewery Corporation
# Organizational Role for Directory Manager
dn: cn=Manager,dc=vbrew,dc=com
objectClass: organizationalRole
cn: Manager
description: Directory Manager
dn: dc=ldap,dc=vbrew,dc=com
objectClass: top
objectClass: dcObject
objectClass: orginization
dc: vbrew
o: vbrew
description: Virtual Brewing Company LDAP Domain
dn: o=vbrew
objectClass: top
objectClass: organization
o: vbrew
description: Virtual Brewery
dn: cn=JaneAdmin,o=vbrew
objectClass: organizationalRole
cn: JaneAdmin
description: Linux System Admin Guru
dn: ou=Marketing,o=vbrew
ou: Marketing
objectClass: top
objectClass: organizationalUnit
description: The Marketing Department
dn: ou=Engineering,o=vbrew
ou: Engineering
objectClass: top
objectClass: organizationalUnit
description: Engineering team
dn: ou=Brewers,o=vbrew
ou: Brewers
objectClass: top
objectClass: orginazationalUnit
description: Brewing team
dn: cn=Joe Slick,ou=Marketing,o=vbrew
cn: Joe Slick
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
mail: jslick@vbrew.com
firstname: Joe
lasname: Slick
ou: Marketing
uid: 1001
postalAddress: 10 Westwood Lane
l: Chicago
st: IL
zipcode: 12394
phoneNumber: 312-555-1212
dn: cn=Mary Smith,ou=Engineering,o=vbrew
cn: Mary Smith
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
mail: msmith@vbrew.com
firstname: Mary
lasname: Smith
ou: Engineering
uid: 1002
postalAddress: 123 4th Street
l: San Francisco
st: CA
zipcode: 12312
phoneNumber: 415-555-1212
dn: cn=Bill Peris,ou=Brewing,o=vbrew
cn: Bill Peris
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
mail: per@vbrew.com
firstname: Bill
lasname: Peris
ou: Brewing
uid: 1003
postalAddress: 8181 Binary Blvd
l: New York
st: NY
zipcode: 12344
phoneNumber: 212-555-1212

Once the LDIF file is ready, it is added to the LDAP directory using
the following command:

vlager# ldapadd -x -D "cn=Manager,dc=vbrew,dc=com" -W -f goo.ldif
Enter LDAP Password:
adding new entry "dc=vbrew,dc=com"
adding new entry "cn=Manager,dc=vbrew,dc=com"
vlager#

You can search for your new directory
entries using the ldapsearch command described
earlier.

17.2.5. Using OpenLDAP

There
are a number of uses for an LDAP servertoo many to mention.
However, authentication is among the more useful to Linux network
administrators. For an administrator of many different machines, the
task of managing the password and authentication details for a large
number of users can quickly become daunting. An OpenLDAP directory
can be used to centrally manage the user accounts for a group of
systems, making it possible for an administrator to enable or disable
user accounts quickly and efficientlya process that, on
multiple systems, can be a chore.

The first step in configuring this
is to install the LDAP NSS and PAM libraries. Under Linux, NSS and
PAM handle authentication and tell the system where to look to verify
users. It is necessary to install two packages,
pam_ldap and nss_ldap,
which can be found at http://www.padl.com/OSS in the software
subsection. Most distributions have packages for these, and they are
often combined and named libnss-ldap. If you are
installing from source, the building of this software is
straightforward and can be accomplished with the standard
configure, make install
method. Along with installing this on your LDAP server, you will also
need to install these libraries on your client machines.

When these
libraries have been installed, you can now start configuring your
slapd OpenLDAP process. You will need to make a
few changes to your slapd.conf file, similar to
those which were covered earlier. The schema section as configured
earlier is sufficient; however, you will need to add some new
definitions in the database section.

#######################################################################
# ldbm database definitions
#######################################################################
database        ldbm
suffix          "o=vbrew,dc=com"
rootdn          "uid=root,ou=Engineering,o=vbrew,dc=com"
rootpw          secret
directory       /usr/local/etc/openldap/data
# Indices to maintain
index   objectClass,uid,uidNumber,gidNumber     eq
index   cn,mail,surname,givenname               eq,subinitial

This section will create the directory definitions for the structure
in which you will be storing your user data.

17.2.5.1 Adding access control lists (ACLs)

As this type of directory should not be
writable by any anonymous users, it is a good idea to include some
type of access list as well. Fortunately, OpenLDAP makes this type of
control quite easy.

# Access control listing - basic
#
access to dn=".*,ou=Engineering,o=vbrew,dc=com"
attr=userPassword
by self write
by dn="uid=root,ou=Engineering,o=vbrew,dc=com" write
by * auth
access to dn=".*,o=vbrew,dc=com"
by self write
by dn="uid=root,ou=Engineering,o=vbrew,dc=com" write
by * read
access to dn=".*,o=vbrew,dc=com"
by * read
defaultaccess read

This list does some basic locking down of the directory and makes it
more difficult for anyone to write to the directory. Once this
configuration has been completed, you can now safely start (or
restart) the OpenLDAP daemon.

17.2.5.2 Migrating to LDAP authentication

You now have
your empty directory created awaiting input and queries. For
administrators who have hundreds or thousands of user accounts across
many machines, the next step, migrating the authentication data into
the directory, may sound like a nightmare. Fortunately, there are
tools created to assist with this potentially difficult step. The
OpenLDAP migration tools from http://www.padl.com/OSS make the task of
populating the LDAP database from existing
/etc/passwd files simple. Each distribution or
package will likely place the files in the
/usr/share directory, but check the
documentation in your package for specifics.

In order for these scripts to work
properly, you will need to make a few minor changes to one of them.
The first one to update is migrage_common.ph.
Search for the following lines:

  #Default DNS domain
$DEFAULT_MAIL_DOMAIN = "padl.com";
#Default base
$DEFAULT_BASE = "dc=padl,dc=com";

And replace them with the values that are correct for your
environment. For our example, this would be:

  $DEFAULT_MAIL_DOMAIN = "vbrew.com";
$DEFAULT_BASE = "o=vbrew,dc=com";

Now,
verify that your OpenLDAP server is listening and that
you've saved the changes to the migration
configuration file. When all of this has been completed, you are now
ready to execute migrate_all_online.sh, which
will begin the process of moving your
/etc/passwd entries into your LDAP directory.

vlager# ./migrate_all_online.sh
Enter the Name of the X.500 naming context you wish to import into: [o=vbrew, dc=com]
Enter the name of your LDAP server [ldap]: vlager
Enter the manager DN: [cn=manager,o=vbrew,dc=com] cn=root,o=vbrew,dc=com
Enter the credentials to bind with: 
password
Importing into o=vbrew,dc=com...
Creating naming context entries...
Migrating aliases...
Migrating groups...
.
.
vlager#

At this point, you will now see that all
of your /etc/passwd entries have been
automatically entered into your LDAP directory. You may wish to use
the ldapsearch query tool now to see some of
your entries. With your directory service functional and now
populated with user entries, you now need to configure your clients
to query the LDAP server, which we will discuss in the next section.

17.2.5.3 Client LDAP configurations

Linux
distributions come configured by default to look at the
/etc/passwd file for authentication. This
default option is easily configurable once the
nss-ldap and PAM libraries are installed, as
described earlier. The first of the configuration files that need to
be changed is the /etc/nsswitch.conf file. You
simply need to tell the system to query LDAP.

passwd:    files ldap
group:     files ldap
shadow:    files ldap

You might be wondering why
we've left the files entry in the
configuration. It is strongly recommended that it be left in so
accounts such as root can still have access
should something happen to the LDAP server. If you delete this line,
and the LDAP server fails, you will be locked out of all of your
systems! This is, of course, where multiple servers come in handy.
Replication between LDAP servers is possible and a fairly
straightforward exercise. For information on building backup OpenLDAP
servers, check the OpenLDAP HOWTOs found on the
Linux Documentation Project web site.

Some
Linux distributions (Debian, for example) have the client
configuration in /etc/openldap.conf. Be careful
not to mistake this for the server configuration files found in
/etc/openldap.

The next file you need
to modify is the openldap.conf file. Like the
other configuration files, the location of this will vary between the
distributions. This file is very simple and has only a few
configurable options. You need to update it to reflect the URI of
your LDAP server and your base LDAP information.

URI  ldap://vlager.vbrew.com
BASE o=vbrew,dc=com

You should now attempt an LDAP query on one of your client machines.

client$ ldapsearch -x 'uid=bob'
version: 2
#
# filter: uid=bob
# requesting: ALL
#
# bob,Engineering,vbrew,com
dn: uid=bob,ou=Engineering,o=vbrew,c=com
uid: bob
cn: bob
sn: bob
mail: bob@vbrew.com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1003
gidNumber: 1003
homeDirectory: /home/bob
gecos: bob
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
client$

If your query resembled the above entry,
you know that your queries are working. Your OpenLDAP server is now
fully populated, can be queried from client machines, and is ready
for real use.

17.2.6. Adding SSL to OpenLDAP

As LDAP was designed to be a secure and
efficient method of serving up small amounts of data, by default it
runs in clear text. While this may be acceptable for certain uses, at
some point you may wish to add encryption to the data stream. This
will help preserve the confidentiality of your directory inquiries
and make it more difficult for attackers to gather information on
your network. If you are using LDAP for any kind of authentication,
encryption is highly recommended.

If you configured your
OpenLDAP at compile time using the -with-tls
option, your server is ready to use SSL. If not, you will need to
rebuild OpenLDAP before continuing.

Adding SSL to OpenLDAP requires only a few
simple changes to the OpenLDAP configuration file. You will need to
tell OpenLDAP which SSL cipher to use and tell it the locations of
your SSL certificate and key files, which you will create later.

TLSCipherSuite HIGH:MEDIUM:+SSLv3
TLSCertificateFile /etc/ssl/certs/slapd.pem
TLSCertificateKeyFile /etc/ssl/certs/slapd.pem

In this case, we've
specified that our OpenSSL certificates will be stored in the
/etc/ssl directory. This will vary between the
distributions; however, you can choose to store your SSL in
certificates any place you like. We've also
specified the type of cipher to use. Note that there are a number of
different choices available; you can choose whichever you prefer.
Since the server now expects to find certificate files when it is
restarted, we will need to create them. Information on how to do this
is covered in previous sections of this book or is available in the
OpenSSL documentation.

It is important to realize that this creates a self-signed
certificate, as opposed to one that is purchased from one of the
certificate providers. If an LDAP client were to check the validity
of your certificate, it would likely generate an error, just as a web
browser would when it detects a non-third-party signed certificate.
However, most LDAP clients do not check certificate validity, so this
isn't likely to create many issues. If you would
like to have a third party certificate, there are numerous vendors
who provide them.

Before you restart your server, you should also make sure that your
certificates are readable only by your LDAP server. They should not
be accessible or writable by any other user on the system. You should
also clean up any temporary files, such as those created in the
previous step before continuing. When these steps have been taken,
you can safely restart your LDAP server.

17.2.6.1 Testing SSL availability

There are a couple of quick tests
that can be done to see whether or not the SSL support has been
enabled. The easiest way to test whether or not the server is
listening is to use netstat, as we did in the
earlier example.

vlager# netstat -aunt | grep 636
tcp        0      0 0.0.0.0:636              0.0.0.0:*          LISTEN

Seeing that the server is listening on the LDAP SSL port is a good
start. This means that the server understood the request to run SSL
and is listening on the correct port. Next, you can choose to see
whether or not the process is actually working. An easy way to do
this is to request to see its digital certificates. The OpenSSL
package comes with a client that can be used to do this.

vlager# openssl s_client -connect vlager:636 -showcerts

The
output of this command will display the full technical information
about the digital certificate that you created at the beginning of
this section. If you aren't seeing any output from
this command, verify that you've started the service
and that something is listening on port 636. If you are still
receiving no response, check the troubleshooting section found later
in this chapter.

17.2.7. LDAP GUI Browsers

For those administrators who prefer a
GUI to a command line, there are a number of LDAP browsers available
for Linux. One of the more functional offerings is from Argonne
National Laboratory and is a Java applet available at http://www-unix.mcs.anl.gov/~gawor/ldap/applet/appletl.
As seen in Figure 17-2, the GUI allows you to easily
browse your directories and modify entries. This software also has
the advantage of running from any platform, easily and without any
installation hassles, provided that Java is available.

Figure 17-2. Java LDAP browser

Another
popular and very powerful LDAP frontend for Linux is GQ, illustrated
in Figure 17-3. It uses a GTK+-style interface and
gives administrators full control over their directories, allowing
them to add, modify, and remove entries, build templates, execute
advanced searches and more. GQ can be found at http://www.biot.com/gq, and requires a Linux
GTK+-compatible interface.

Figure 17-3. GQ in browsing mode

17.2.8. Troubleshooting OpenLDAP

Installing and configuring OpenLDAP can be
a tricky process, and there are a number of things that can go wrong.
As with many Linux server processes, the best place to start
debugging is the system log. There, you should see a line somewhat
similar to this one, which should give you an indication as to
whether your server has started properly.

Jun 15 11:33:39 vlager slapd[1323]: slapd starting

If you make
a typo in the slapd.conf file, the process is
often smart enough to just ignore the line and proceed. However, if
you happen to make a critical error, as we have in the following
example, slapd will fail to start.

Jul 25 11:45:25 vlager slapd[10872]: /etc/openldap/slapd.conf: line 46: unknown 
directive "odatabase" outside backend info and database definitions (ignored)
Jul 25 11:45:25 vlager slapd[10872]: /etc/openldap/slapd.conf: line 47: suffix line 
must appear inside a database definition (ignored)
Jul 25 11:45:25 vlager slapd[10872]: /etc/openldap/slapd.conf: line 49: rootdn line 
must appear inside a database definition (ignored)
Jul 25 11:45:25 vlager slapd[10872]: /etc/openldap/slapd.conf: line 54: rootpw line 
must appear inside a database definition (ignored)
Jul 25 11:45:25 vlager slapd[10872]: /etc/openldap/slapd.conf: line 57: unknown 
directive "directory" outside backend info and database definitions (ignored)
Jul 25 11:45:25 vlager slapd[10872]: /etc/openldap/slapd.conf: line 59: unknown 
directive "index" outside backend info and database definitions (ignored)
Jul 25 11:45:25 vlager slapd[10873]: backend_startup: 0 databases to startup.
Jul 25 11:45:25 vlager slapd[10873]: slapd stopped.
Jul 25 11:45:25 vlager slapd[10873]: connections_destroy: nothing to destroy.

In this example, we mistyped the word
"database," which is a critical
option in the configuration. As you can see, the server failed to
start, but still provided us with enough information to figure out
what went wrong.

If
you have verified that everything is running on the server, but
clients are unable to connect, you should verify that the LDAP ports
389 and 636 are not being blocked by a firewall. If your server is
running iptables with a default policy denying
any incoming connections, you will need to explicitly allow these two
ports.

Other common issues are caused by missing
or incomplete SSL certificates. An indication from the system log
that something is wrong with the SSL functioning is:

Jul 25 12:02:15 vlager slapd[11135]: main: TLS init def ctx failed: 0
Jul 25 12:02:15 vlager slapd[11135]: slapd stopped.
Jul 25 12:02:15 vlager slapd[11135]: connections_destroy: nothing to destroy.

The error in this case is very terse; however, the fact that TSL is
mentioned indicates a problem with SSL. If you are receiving this
error, you should check your certificate paths and permissions.
Often, the certificate files cannot be read by the LDAP server
because they are set to be readable only by the root
account.