Introduction

The OpenLDAP software provided in Linux distributions implements the Lightweight Directory Access Protocol (LDAP) as a client/server model. LDAP is designed to provide an efficient way to find and manage information. The OpenLDAP software and the packages it interfaces with provide tools to create a Directory Information Tree, a read-mostly database. This article shows you how to store user account information and modify the authentication services to use LDAP to retrieve needed information as well. The internal details are unimportant, as the tools give you a representation of the database in a text format, the LDAP Data Interchange Format (LDIF).

LDAP information is organized into collections of attributes and values, known as entries. An entry can have mandatory attributes or optional attributes. The attributes for an entry must follow rules that are defined in a schema file found in /etc/openldap/schema/. The rules are included in the entry the objectclass attribute. Looking at the relationship below, you can see that the posixAccount objectclass holds the information from the password file entry (the posixAccount userPassword is a base64 encoding of the file entry).

The file /etc/openldap/schema/nis.schema defines all the attributes and the objectclass for an entry in the posixAccount object class. For example, here is the uidNumber attribute description:

attributetype ( 1.3.6.1.1.1.1.0 NAME 'uidNumber'
   DESC 'An integer uniquely identifying a user in an administrative domain'
   EQUALITY integerMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

After all attribute types are defined, they are collected into the posixAccount objectclass. For example:

objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY
   DESC 'Abstraction of an account with POSIX attributes'
   MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
   MAY ( userPassword $ loginShell $ gecos $ description ) )

The ldapuser entry has a distinguished name attribute, dn, which is used as a user name and which, along with the userPassword, is used to log into, or bind, to the LDAP directory.

LDAP provides for special entries that act as containers to organize the entries into a tree structure. In the examples, you'll use a container, People, for user account information and another container, Groups, for group account information. The resulting Directory Information Tree is shown in Figure 2.

Let's look at how to configure the OpenLDAP server, migrate information from the system files to the LDAP directory, and configure an OpenLDAP client to authenticate users via LDAP. With a central authentication database, you should build in high availability by using replication to have a second LDAP server that can respond to requests in the event of any problems reaching the server. As authentication data such as passwords will be traveling over the network, you'll want to set up encrypted communications using the TSL protocol.

Our OpenLDAP servers and clients are Virtual Machines running Red Hat Enterprise Linux AS release 4 (Nahant Update 1). I used the systems listed in Table 1 in my examples. Use values appropriate for your setup if you choose to duplicate these examples.

Back to top

Configure the LDAP server

I used these Red Hat Enterprise Linux release 4 Update 1 packages to set up the server:

• openldap-2.2.13-2: Contains configuration files, libraries, and documentation for OpenLDAP
• openldap-servers-2.2.13-2: Contains the slapd and slurpd servers, migration scripts, and related files
• openldap-clients-2.2.13-2: Contains the client programs, used for accessing and modifying OpenLDAP directories

The OpenLDAP packages install a variety of programs on the server:

• Daemons:
  • slapd: The main LDAP server
  • slurpd: The server responsible for keeping replication LDAP servers synchronized
• Client programs that operate on the directory over the network. Here are a couple:
  • ldapadd: Opens a connection to an LDAP server, binds, and modifies or adds entries
  • ldapsearch: Opens a connection to an LDAP server, binds, and performs a search using specified parameters
• Server programs that operate on the databases on the local system:
  • slapadd: Adds entries specified in LDAP Directory Interchange Format (LDIF) to an LDAP database
  • slapcat: Opens the LDAP database and writes the corresponding entries in LDIF format

The main server configuration file for OpenLDAP is /etc/openldap/slapd.conf. The completed slapd.conf file for this example is given below in Listing 18. The slapd.conf file consists of a series of global configuration options that apply to slapd as a whole, followed by a database backend definition that contains information specific to our database. If a line begins with white space, it is considered a continuation of the previous line. Blank lines and comment lines beginning with a "#" character are ignored.

If you're working through this article as an exercise, you'll modify the sections as specified below to bring up the LDAP server. Once you verify that the server is working, you'll add replication and then security. First are the settings for the global configuration section. Beside each option is the value you want it to have.

As mentioned above, information is organized into collections of attributes and values, known as entries. The rules that the attributes for an entry must follow are organized using a special attribute called the objectclass attribute, defined in a schema file found in /etc/openldap/schema/. For authentication, you need the posixAccount and shadowAccount objectclasses defined in nis.schema:

include /etc/openldap/schema/nis.schema

The loglevel line sets logging options. Specify the level at which debugging statements and operation statistics should be logged to /var/log/slapd.log. Log levels are additive: 296 = 256 log connections/operations/results + 32 search filter processing + 8 connection management:

loglevel 296

The information is logged to the syslogd LOG_LOCAL4 facility. Also add the following to /etc/syslog.conf and have syslogd reread its configuration file:

local4.debug /var/log/slapd.log

The access line defines who has access to what in your directory. You want users to be able to change their passwords and update shadow information reflecting the change. You want authentication routines to be able to retrieve users' passwords. You want users to be able to read all of their other entries. Note that as the password entry is not readable, the only use of the shadow attributes is to manage password expiration.

access to attrs=shadowLastChange,userPassword
      by self write
      by * auth

access to *
      by * read

Next, in the database section, define the following.

Use the newer bdb backend database:

database bdb

Specify the DN suffix of queries that your backend will respond to. To ensure uniqueness, the root suffix should be built from your network's domain name. In my case, this would be .dc=svc,dc=beaverton,dc=ibm,dc=com., but to save space I've abbreviated it in my example:

suffix "dc=ibm,dc=com"

Specify the administrative DN, which not subject to access control or restrictions for operations on this database. You need not have an entry in your directory for the DN. Using the DN for the Manager with the rootpw password bypasses all access controls in the ACL rules:

rootdn "cn=Manager,dc=ibm,dc=com"
rootpw {MD5}ijFYNcSNctBYg

This concludes the options you'll want to set at this point. I'll return to the slapd.conf file later to configure replication and again to configure security.

Now, you want to add data to your directory and verify that you can access the information. To do this, you configure the server to use the ldap client tools such as ldapadd and ldapsearch. The configuration file for the ldap client tools is /etc/openldap/ldap.conf. The complete listing of the file I used is shown in Listing 19 toward the end of this article. To run the tools from the ldap server, you need only change this line like so:

BASE dc=ibm,dc=com

Set the startup script to launch LDAP for run levels 2, 3, and 5:

# chkconfig --levels 235 ldap on

Start the service from the command line:

# service ldap start
Starting slapd:                               [  OK  ]

The OpenLDAP daemon slapd should be running:

# ps -ef | grep slap
ldap   13521  1  0 Oct24 ?     00:00:00 /usr/sbin/slapd -u ldap -h ldap:/// ldaps:///

The ldapsearch -x command, while not returning any data, should complete successfully.

Back to top

Migrate the password and shadow information

The openldap-servers package provided by Red Hat includes MigrationTools from PADL Software Pty Ltd. You'll use them to migrate data from the Linux system files such as /etc/group and /etc/password to the LDAP LDIF format, a representation of the database in a text format. The format is line-delimited, colon-separated attribute-value pairs.

A collection of Perl scripts is installed in /usr/share/openldap/migration/ to perform the migration. The configuration information for these Perl scripts is contained at the beginning of the include file migrate_common.ph. For your purposes, it is sufficient to modify the variable for the naming suffix to use in entries' distinguished names, as follows:

$DEFAULT_BASE = "dc=ibm,dc=com"

After making this change, run the script migrate_base.pl, which creates the root entry and the next lower level organizational unit entries for Hosts, Networks, Group, and People, among others:

# migrate_base.pl > base.ldif

Edit base.ldif, removing all entries except as follows:

# cat base.ldif
dn: dc=ibm,dc=com
dc: ibm
objectClass: top
objectClass: domain

dn: ou=People,dc=ibm,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit

dn: ou=Group,dc=ibm,dc=com
ou: Group
objectClass: top
objectClass: organizationalUnit

Working from the LDAP server, insert the entries below into the database using the OpenLDAP client tool, ldapadd. Simple authentication must be specified with the option -x. The Distinguished Name to authenticate, the rootdn specified in slapd.conf, is "cn=Manager,dc=ibm,dc=com". For simple authentication, a password is required. The option -W forces a password prompt. This password is the value of the rootpw parameter specified in the slapd.conf file. The LDIF file containing the entries is specified with the option -f:

# ldapadd -x -D "cn=Manager,dc=ibm,dc=com" -W -f base.ldif

Next, migrate the ldapuser group from /etc/group:

# grep ldapuser /etc/group > group.in
# ./migrate_group.pl group.in > group.ldif

#  cat group.ldif
dn: cn=ldapuser,ou=Group,dc=ibm,dc=com
objectClass: posixGroup
objectClass: top
cn: ldapuser
userPassword: {crypt}x
gidNumber: 500

# ldapadd -x -D "cn=Manager,dc=ibm,dc=com" -W -f group.ldif

Finally, migrate the ldapuser information from /etc/passwd and /etc/shadow:

# grep ldapuser /etc/passwd > passwd.in
# ./migrate_passwd.pl passwd.in > passwd.ldif

# cat passwd.ldif
dn: uid=ldapuser,ou=People,dc=ibm,dc=com
uid: ldapuser
cn: ldapuser
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt$1$TeOlOcMc$cpQaa0WpLSFRC1HIHW5bt1
shadowLastChange: 13048
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 500
gidNumber: 500
homeDirectory: /home/ldapuser
gecos: ldapuser

# ldapadd -x -D "cn=Manager,dc=ibm,dc=com" -W -f passwd.ldif

At this point, check the information that has been added to the database. Listing 9 shows the complete output:

# ldapsearch -x

# extended LDIF
#
# LDAPv3
# base <> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#

# ibm.com
dn: dc=ibm,dc=com
dc: ibm
objectClass: top
objectClass: domain

# People, ibm.com
dn: ou=People,dc=ibm,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit

# Group, ibm.com
dn: ou=Group,dc=ibm,dc=com
ou: Group
objectClass: top
objectClass: organizationalUnit

# ldapuser, Group, ibm.com
dn: cn=ldapuser,ou=Group,dc=ibm,dc=com
objectClass: posixGroup
objectClass: top
cn: ldapuser
gidNumber: 500

# ldapuser, People, ibm.com
dn: uid=ldapuser,ou=People,dc=ibm,dc=com
uid: ldapuser
cn: ldapuser
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 500
gidNumber: 500
homeDirectory: /home/ldapuser
gecos: test2

# search result
search: 2
result: 0 Success

# numResponses: 6
# numEntries: 5

Back to top

Configure the LDAP client

The Red Hat Enterprise Linux release 4 Update 1 package used to set up the client consists of:

• nss_ldap-226-6: Includes two LDAP access clients: nss_ldap and pam_ldap
  • nss_ldap is a set of C library extensions that allow LDAP directory servers to be used as a primary source of user and group information.
  • pam_ldap is a module for Linux-PAM that supports authentication.

Two services need to be configured for LDAP authentication to work correctly, the system naming service and the authentication service.

The system naming service (NSS) needs to be configured to use LDAP to resolve resources such as user and group accounts. For example, while running the command ls -l, if a file inode gives the ownership as "user 501," then the naming service needs to resolve "uid 501" to the user name printed in the ls command output. Generally this is done by finding all user accounts in the /etc/passwd file. Since users will now be stored in an LDAP directory, the system will need to be configured to resolve accounts in both the passwd file and in the LDAP directory. This functionality is provided by the /usr/lib/libnss_ldap.so library.

The authentication service is the service that actually authenticates users to LDAP. The Pluggable Authentication Modules (PAM) provide the native Linux authentication service. Below, you'll configure PAM to check the local /etc/passwd file for a user account and then check the LDAP server. The PAM LDAP modules will be used to redirect authentication to the LDAP directory. The /lib/security/pam_ldap.so PAM module provides LDAP authentication.

Authentication itself is performed by the PAM routines by getting a username from the login candidate, binding to the OpenLDAP server, retrieving the DN associated with the uid entry (the username entry), getting a password from the login candidate, and then attempting to bind to the OpenLDAP server using the DN and password. If the bind is successful, PAM reports that the user has successfully passed the authentication test provided by pam_ldap.so. Depending upon how PAM is configured, other tests may be performed before the user sees the command line prompt.

You can configure the LDAP client in one of two ways. One quick and easy method is to run /usr/sbin/authconfig and enter information in two screens. Another method is by editing the client LDAP configuration file, /etc/ldap.conf, and then making changes to /etc/nsswitch.conf, /etc/sysconfig/authconfig, and /etc/pam.d/system-auth. First, look at running authconfig.

Make the selections as shown in Figure 3 and click Next.

Enter your corresponding information as shown on the second screen displayed in Figure 4, and click OK.

To configure an OpenLDAP client manually, follow the steps below.

The file used to track whether or not particular authentication mechanisms are enabled is /etc/sysconfig/. You want the entries below to have a value of "yes":

USELDAP=yes
USELDAPAUTH=yes
USEMD5=yes
USESHADOW=yes
USELOCAUTHORIZE=yes

The principal configuration file used by the PAM and NSS modules is /etc/ldap.conf. The host option specifies the LDAP server, the base option specifies the DN for the directory and, initially, you want encryption turned off:

host dhcp64-233.ibm.com
base dc=ibm,dc=com
ssl off

To have the NSS service consult the OpenLDAP server, add "ldap" to the passwd, shadow, and group lines in the /etc/nsswitch.conf lines, as shown:

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

To have the PAM authentication service consult the OpenLDAP server, add the pam_ldap lines to /etc/pam.d/system-auth after the corresponding standard pam_unix.so entries. Although other variations lead to the same results, this is the file I used:

auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass
auth required /lib/security/$ISA/pam_deny.so

account required /lib/security/$ISA/pam_unix.so broken_shadow
account sufficient /lib/security/$ISA/pam_localuser.so
account sufficient /lib/security/$ISA/pam_succeed_if.so uid %lt; 100 quiet
account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so
account required /lib/security/$ISA/pam_permit.so

password requisite /lib/security/$ISA/pam_cracklib.so retry=3
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password sufficient /lib/security/$ISA/pam_ldap.so use_authtok
password required /lib/security/$ISA/pam_deny.so

session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
session optional /lib/security/$ISA/pam_ldap.so

At this point, the user account information can be removed from the client system and be obtained from the LDAP directory. When the user attempts to log into the client system, the PAM authentication service gets the username, in our example ldapuser, from the user. PAM retrieves the distinguished name (DN) entry, .dn: uid=ldapuser, ou=People, dc=ibm, dc=com. from the LDAP server. PAM next gets the password from the user. PAM attempts to bind to the LDAP server using the DN and password. The DN and password are sent to the LDAP server in plain text. If, after hashing the password, the server can log the user in, a successful bind is reported back to PAM. The successful bind fulfills the PAM criteria for the pam_ldap module to report success, and if all other PAM criteria are met, the user is allowed to log in.

With authentication being handled by the LDAP server, you have two more issues to resolve to meet your goal of providing reliable and secure authentication. At this point, any inability of your client systems to communicate with the LDAP server will prevent users from logging into the client systems. You'll see how to remove this single point of failure in the next section, which shows how clients can access the LDAP directory from backup servers. With users' passwords traveling over the network in plain text, you do not meet the requirement for secure authentication. The section Configure TLS security addresses this.

Back to top

Configure replication

To prevent problems with users' ability to log on to a client should the LDAP server experience any problems, you employ replication to achieve your reliability goal. Replication is provided by the OpenLDAP replication daemon, slurpd, which periodically wakes up and checks a log file on the master for any updates. The updates are then propagated to the slave servers. Read requests can be resolved by either server, whereas updates can be performed only on the master. Update requests to a slave generate a referral message that gives the address of the master server. It is the client's responsibility to retry the update at the referral address.

To configure replication, stop the OpenLDAP server's slapd daemon:

# service ldap stop

Add the following to the server's /etc/openldap/slapd.conf to enable replication to the new slave server. The replogfile line specifies the file where the LDIF-like change will be written. The replica directive defines the host to which the change should be propagated:

#Replicas of this database
replogfile /var/lib/ldap/replog
replica host=dhcp64-253.ibm.com:389
        binddn="cn=Manager,dc=ibm,dc=com"
        credentials=secret
        bindmethod=simple

On the system that will run the slave OpenLDAP server, follow the steps given above in Configure the LDAP server. Then, copy the database from the master server to the replica by exporting the information to an ldif file and adding it to the slave server database.

On the master server:

# ldapsearch -x > database.ldif

On the replication server:

# ldapadd -x -D "cn=Manager,dc=ibm,dc=com" -W -f database.ldif

Add the following to the replica server's /etc/openldap/slapd.conf file. updatedn specifies the DN that the master slurpd daemon will use when updating the slave directory. updateref points to the master directory server. When an LDAP client is asking the slave to update, the slave points the client to this master server.

updatedn "cn=Manager,dc=ibm,dc=com"
updateref ldap://dhcp64-233.ibm.com:389/

Start the replica OpenLDAP server and, once it is running, start the master OpenLDAP server. On the master, both slapd and slurpd will start.

At this time, you can let the OpenLDAP client use the replica server in addition to the master server by either running authconfig and adding the replica host name to the Server line on the second screen, or by changing the host attribute in /etc/ldap.conf to this:

host dhcp64-253.ibm.com dhcp64-233.ibm.com

To verify that replication is working correctly, observe what happens when the gecos attribute is updated. The replication log uses a format similar to the LDIF. After reading the replogfile, slurpd copies the entry to its own replay log. The actual changes, in LDIF format, are located at /var/lib/ldap/replica/ on the master LDAP server in a file called slurpd.replog.

With the change in the file user_mod, the client routine ldapmodify is used to apply the change:

# cat user_mod
dn: uid=ldapuser,ou=People,dc=ibm,dc=com
changetype: modify
replace: gecos
gecos: test2

# tail -f /var/lib/ldap/replog &

# ldapmodify -x -r -f /home/ldapuser/user_mod -D'cn=Manager,dc=ibm,dc=com' -W
Enter LDAP Password:
modifying entry "uid=ldapuser,ou=People,dc=ibm,dc=com"

replica: dhcp64-253.ibm.com:389
time: 1130111686
dn: uid=ldapuser,ou=People,dc=ibm,dc=com
changetype: modify
replace: gecos
gecos: test2
-
replace: entryCSN
entryCSN: 20051023235446Z#000001#00#000000
-
replace: modifiersName
modifiersName: cn=Manager,dc=ibm,dc=com
-
replace: modifyTimestamp
modifyTimestamp: 20051023235446Z
-

Back to top

Configure TLS security

LDAP sends all information, including passwords, over the network in clear text. You employ the encryption provided by TLS, the successor to SSL, to resolve this problem. At the transport layer, the data is encrypted and wrapped in the TLS protocol, for transport across the network. The tools used to configure encryption are provided by the OpenSSL package.

Encryption is a complex topic, but a basic overview of how TLS works is needed to use the OpenSSL package. The bulk of the data is encrypted using a symmetric key algorithm that encrypts and decrypts data using a single secure key. You have a problem of how to avoid initially sending the single secure key from the LDAP server to the LDAP client in plain text. A public key algorithm, in which the client can encrypt the single key using a freely available public key and only the server can decrypt the single secure key, is used to resolve this problem.

The public key is created and distributed as part of a certificate, which contains supporting information such as an ID, an expiration date, and the Fully Qualified Domain Name (FQDN) of the LDAP server providing the certificate. Before the LDAP client uses a certificate for encryption, it verifies that the server it is talking with owns the certificate by encrypting a challenge and verifying that the server can decrypt it.

To verify that the server issuing the certificate is an approved LDAP server, the client is configured only to accept certificates that are signed by a local Certificate Authority (CA). It uses the public key in a certificate generated by the CA and stored on the client to verify that the certificate presented by the LDAP server is valid.

In this example, you will set up your LDAP server as a Certificate Authority and create a self-signed certificate to be used by LDAP clients and servers in encrypting information.

The Red Hat Enterprise Linux release 4 Update 1 package used to set up the TLS server is:

• openssl-0.9.7a-43.1: Includes a certificate management tool and shared libraries that provide various cryptographic algorithms and protocols

To set up the environment in which the Certificate Authority works and to generate your self-signed certificate, run the /usr/share/ssl/misc/CA shell script, which is a wrapper around the openssl command. Privacy Enhanced Mail (PEM) is a format for encrypting and text encoding data:

# cd /usr/share/ssl/misc
# ./CA -newca
CA certificate filename (or enter to create)

Making CA certificate ...
Generating a 1024 bit RSA private key
.........++++++
......++++++
writing new private key to './demoCA/private/./cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
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) [GB]:US
State or Province Name (full name) [Berkshire]:Oregon
Locality Name (eg, city) [Newbury]:Beaverton
Organization Name (eg, company) [My Company Ltd]:IBM
Organizational Unit Name (eg, section) []:its
Common Name (eg, your name or your server's hostname) []:dhcp64-233.ibm.com
Email Address []:root@dhcp64-233.ibm.com

Next, generate the server certificate that will be signed by the Certificate Authority. The remaining steps are done once for the master LDAP server, specifying CN=dhcp64-233.ibm.com, and then for the slave server, specifying CN=dhcp64-253.ibm.com. The nodes option is used so that the certificate will not need a pass phrase every time the OpenLDAP server daemon, slapd, is started. The signed public key is embedded in certificate request slapd-req.pem; the private key that matches it is in slapd-key.pem:

# openssl req -new -nodes -subj
   '/CN=dhcp64-233.ibm.com/O=IBM/C=US/ST=Oregon/L=Beaverton'
   -keyout slapd-key.pem -out slapd-req.pem -days 365
Generating a 1024 bit RSA private key
...............++++++
.....................................++++++
writing new private key to 'slapd-key.pem'
-----

Sign the certificate using the CA certificate you created in the first step:

# openssl ca -out slapd-cert.pem -infiles slapd-req.pem
Using configuration from /usr/share/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Oct 25 02:50:05 2005 GMT
            Not After : Oct 25 02:50:05 2006 GMT
        Subject:
            countryName               = US
            stateOrProvinceName       = Oregon
            organizationName          = IBM
            commonName                = dhcp64-233.ibm.com
        X509v3 extensions:
            X509v3 Basic Constraints:
            CA:FALSE
            Netscape Comment:
            OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
            11:A2:FB:59:42:A4:B3:26:73:1D:6D:F5:4D:2F:80:F0:FA:10:38:F5
            X509v3 Authority Key Identifier:
            keyid:F7:6A:25:F5:76:BE:20:E7:8D:0F:51:EF:D8:86:7B:AF:2C:74:2F:80
            DirName:/C=US/ST=Oregon/L=Beaverton/O=IBM/OU=its/CN=dhcp64-233.ibm.com
/emailAddress=root@dhcp64-233.ibm.com
            serial:00

Certificate is to be certified until Oct 25 02:50:05 2006 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

The next step copies over all the required certificates to where slapd can find them. In addition, the correct permissions are enforced on each file:

# cp -p slapd-key.pem /etc/openldap/slapdkey.pem
# cp -p slapd-cert.pem /etc/openldap/slapdcert.pem
# chown ldap:ldap /etc/openldap/slapdcert.pem
# chmod 644 /etc/openldap/slapdcert.pem
# chown ldap:ldap /etc/openldap/slapdkey.pem
# chmod 400 /etc/openldap/slapdkey.pem

# mkdir /etc/openldap/cacerts/
# cp /usr/share/ssl/misc/demoCA/cacert.pem /etc/openldap/cacerts/cacert.pem
# chown ldap:ldap /etc/openldap/cacerts/cacert.pem
# chmod 644 /etc/openldap/cacerts/cacert.pem

On the OpenLDAP server, add the lines below to the global section of the /etc/openldap/slapd.conf file. The TLSCertificateFile and TLSCertificateKeyFile specify the paths to the certificate file and private-key file. TLSCipherSuite specifies a list of OpenSSL ciphers from which slapd will choose when negotiating TLS connections, in decreasing order of preference. HIGH means "all ciphers using key lengths greater than 128 bits"; MEDIUM is short for "all ciphers using key lengths equal to 128 bits"; and +SSLv2 means "all ciphers specified in the SSL protocol, Version 2, regardless of key strength."

TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile /etc/openldap/cacerts/cacert.pem
TLSCertificateFile /etc/openldap/slapdcert.pem
TLSCertificateKeyFile /etc/openldap/slapdkey.pem

Add the following lines to the secondary configuration file for the LDAP server, /etc/openldap/ldap.conf:

TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT allow

To allow secure connections from the OpenLDAP client, add the following to the /etc/openldap/ldap.conf file:

ssl start_tls
tls_checkpeer yes
tls_cacertfile /etc/openldap/cacerts/cacert.pem

Back to top

Conclusion

By following these instructions, you have now built a centralized authentication system using the Lightweight Directory Access Protocol (LDAP). You started by configuring the LDAP server to respond to queries with base "dc=ibm,dc=com". You used a set of Perl scripts to migrate user account information into the LDAP directory. You modified the Linux user account services, PAM and NSS, to retrieve user information from the LDAP server. You set up a replica of the LDAP server to respond as a backup server. Then, you used the TLS protocol to securely encrypt communications between the LDAP client and server. Congratulations!

For reference, below are the complete listings of the configuration files used in this article.

#
# See slapd.conf (5) for details on configuration options.
#
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema

loglevel        256
pidfile         /var/run/slapd.pid
argsfile        /var/run/slapd.args

# The next three lines allow use of TLS for encrypting connections.
TLSCipherSuite  HIGH:MEDIUM:+SSLv2
TLSCACertificateFile    /etc/openldap/cacerts/cacert.pem
TLSCertificateFile      /etc/openldap/slapdcert.pem
TLSCertificateKeyFile   /etc/openldap/slapdkey.pem

# access control policy:
# Restrict password access to change by owner and authentication.
# Allow read access by everyone to all other attributes.

access to attrs=shadowLastChange,userPassword
   by self write
   by * auth

access to *
   by * read

#######################################################################
# database definition
#######################################################################

database        bdb
suffix          "dc=ibm,dc=com"

rootdn          "cn=Manager,dc=ibm,dc=com"
rootpw          {MD5}ijFYNcSNctBYg

directory       /var/lib/ldap

# Indices to maintain for this database
index objectClass                       eq,pres
index ou,cn,mail,surname,givenname      eq,pres,sub
index uidNumber,gidNumber,loginShell    eq,pres
index uid,memberUid                     eq,pres,sub
index nisMapName,nisMapEntry            eq,pres,sub

#Replicas of this database
replica host=dhcp64-253.ibm.com:389
        binddn="cn=Manager,dc=ibm,dc=com"
        credentials=secret
        bindmethod=simple
replogfile /var/lib/ldap/replog

#
# LDAP Defaults
#

# See ldap.conf(5) for details

HOST 127.0.0.1
BASE dc=ibm,dc=com

TLS_CACERTDIR /etc/openldap/cacerts
TLS_REQCERT allow

a
# @(#)$Id: ldap.conf,v 1.34 2004/09/16 23:32:02 lukeh Exp $
#
# This is the configuration file for the LDAP nameservice
# switch library and the LDAP PAM module.
#
# PADL Software
# http://www.padl.com
#

# Your LDAP server.
# Multiple hosts may be specified, each separated by a
# space.

host dhcp64-233.ibm.com dhcp64-233.ibm.com

# The distinguished name of the search base.

base dc=ibm,dc=com

# OpenLDAP SSL mechanism, start_tls mechanism uses the normal LDAP port 389
ssl start_tls

#Require and verify server certificate
tls_checkpeer yes

# CA certificates for server certificate verification
tls_cacertfile /etc/openldap/cacerts/cacert.pem

pam_password md5

Resources

Learn

• The OpenLDAP home page is the home of the OpenLDAP Project. It contains a wealth of information about configuring OpenLDAP as well as a future roadmap and versions. Be sure to read the OpenLDAP Software 2.3 Administrator's Guide.
  
  
• At the OpenSSL Project, find information regarding SSL and TLS.
  
  
• In the LDAP Linux HOWTO, get details on installing, configuring, running, and maintaining an LDAP (Lightweight Directory Access Protocol) Server on a Linux machine. Read the discussion of LDAP authentication using pam_ldap and nss_ldap in the LDAP Implementation HOWTO.
  
  
• The PADL home page offers the Perl migration scripts, nss_ldap and pam_ldap, among other useful LDAP tools.
  
  
• In the developerWorks Linux zone, find more resources for Linux developers.
  
  
• Stay current with developerWorks technical events and Webcasts.
  
  

Get products and technologies

• With IBM trial software, available for download directly from developerWorks, build your next development project on Linux.
  
  

Discuss

• The OpenLDAP mailing lists are the primary forums for OpenLDAP discussions.
  
  
• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Mike O'Reilly is a member of the Linux and VMware ESX product support teams within IBM and has been supporting the Linux product for the better part of five years. In addition, he has been supporting VMware for more than two years and UNIX for more than ten.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Configure the LDAP server
• Migrate the password and shadow information
• Configure the LDAP client
• Configure replication
• Configure TLS security
• Conclusion
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into Linux on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers