Vous êtes sur la page 1sur 16




Technical topics

Evaluation software


Sign in (or register)


OpenLDAP on Red Hat provides secure, reliable account management

Mike O'Reilly (mikeor@us.ibm.com), Systems Support Engineer, IBM, Software Group
Summary: Building a centralized authentication system using Lightweight Directory Access Protocol (LDAP) promises to reduce
administration costs, increase security, avoid data replication, and increase data consistency. As Linux has matured, better tools have emerged
to ease the migration of user account information into an LDAP directory. Tools have also been developed to enable the configuration of
encrypted communication between a client and the directory server and to provide fault tolerance through replication. This article shows you
how to configure a server and client to use OpenLDAP on Red Hat Linux.
Date: 30 May 2006
Level: Intermediate
Activity: 36317 views
Comments: 3 (View | Add comment - Sign in)
Average rating (63 votes)
Rate this article
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).

Figure 1. Relationship between LDAP directory entry and Linux password file

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 ( NAME 'uidNumber'
DESC 'An integer uniquely identifying a user in an administrative domain'
EQUALITY integerMatch

After all attribute types are defined, they are collected into the posixAccount objectclass. For example:
objectclass ( 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,
for user account information and another container, Groups, for group account information. The resulting Directory Information Tree is
shown in Figure 2.

Figure 2. Directory Information Tree for user account information

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.

Table 1. System network information

OpenLDAP master server
OpenLDAP slave server
OpenLDAP client

Host name

IP address

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:
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
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:

Listing 1. Setting startup runlevels

# chkconfig --levels 235 ldap on

Start the service from the command line:

Listing 2. Starting the service

# service ldap start


Starting slapd:


The OpenLDAP daemon slapd should be running:

Listing 3. Checking that the service is running

# ps -ef | grep slap
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.
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:

Listing 4. Running migrate_base.pl

# migrate_base.pl > base.ldif

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

Listing 5. base.ldif entries

# 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:

Listing 6. Inserting entries using ldapadd

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


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

Listing 7. Migrating the ldapuser 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:

Listing 8. Migrating ldapuser information

# 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:

Listing 9. The populated OpenLDAP database in LDIF format

# ldapsearch -x

extended LDIF
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

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
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
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.

Figure 3. Page 1 from the authconfig command


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

Figure 4. Page 2 from the authconfig command

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":

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
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.
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:

Listing 10. Stopping the service

# 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

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:

Listing 11. Exporting data to an LDIF file

# ldapsearch -x > database.ldif

On the replication server:

Listing 12. Adding the data to the slave server database

# 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:

Listing 13. Applying the user_mod 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

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
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:

Listing 14. Running the CA shell script

# 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:

Listing 15. Generating the server certificate

# openssl req -new -nodes -subj
-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:

Listing 16. Signing the certificate

# 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)
Not Before: Oct 25 02:50:05 2005 GMT
Not After : Oct 25 02:50:05 2006 GMT
= US
= Oregon
= dhcp64-233.ibm.com
X509v3 extensions:
X509v3 Basic Constraints:
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
X509v3 Authority Key Identifier:
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

Listing 17. Copying certificates and enforcing permissions


cp -p
cp -p

slapd-key.pem /etc/openldap/slapdkey.pem
slapd-cert.pem /etc/openldap/slapdcert.pem
ldap:ldap /etc/openldap/slapdcert.pem
644 /etc/openldap/slapdcert.pem
ldap:ldap /etc/openldap/slapdkey.pem
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."
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

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

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.

Listing 18. The server /etc/openldap/slapd.conf file used in the examples

# See slapd.conf (5) for details on configuration options.


# The next three lines allow use of TLS for encrypting connections.
# 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







# Indices to maintain for this database

index objectClass
index ou,cn,mail,surname,givenname
index uidNumber,gidNumber,loginShell
index uid,memberUid
index nisMapName,nisMapEntry


#Replicas of this database

replica host=dhcp64-253.ibm.com:389
replogfile /var/lib/ldap/replog

Listing 19. The server /etc/openldap/ldap.conf file used in the examples

# LDAP Defaults
# See ldap.conf(5) for details
BASE dc=ibm,dc=com
TLS_CACERTDIR /etc/openldap/cacerts

Listing 20. The client /etc/ldap.conf file used in the examples


@(#)$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

# 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

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.

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.
Close [x]

Need an IBM ID?
Forgot your IBM ID?
Forgot your password?
Change your password
Keep me signed in.
By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your developerWorks profile is displayed to
the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will
accompany the content that you post.
All information submitted is secure.
Close [x]


The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name
accompanies the content you post on developerWorks.
Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not
be your email address for privacy reasons.
Display name:

(Must be between 3 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

Average rating (63 votes)
1 star

1 star

2 stars

2 stars

3 stars

3 stars

4 stars

4 stars

5 stars

5 stars

Add comment:
Sign in or register to leave a comment.
Note: HTML elements are not supported within comments.

Notify me when a comment is added1000 characters left

Total comments (3)

Hello, Thanks for your guide it was helpful. I found a few errors or the OS has changed after you wrote this page.
I used RHEL 5.5 and OpenLDAP 2.3.43-12.e15_7.9x86_64
Examples of errors:
1)To bring up the gui in the two screen shots you use the command /usr/bin/authconfig-tui not /usr/sbin/authconfig.
2)line below the 2nd pic says to go to /etc/sysconfig but you need to edit /etc/sysconfig/authconfig
3) there are no accounts called ldapuser on the system. I ended up typing the LDIF up by hand.
I had the same issue as sbjerry so I added changed this line in /etc/sysconfig/authconfig to:
I have not done the TLS or replication parts yet. The LDAP works great.
Does anyone know how to setup Solaris 10 up as a client on OpnLDAP. I'm having one hell of a time doing this.
Thank you Mr. O'Reilly
Posted by cyberninja on 06 October 2011


Report abuse
1. 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
After load the ldif files to LDAP, then make linux OS using LDAP as user authentication, but the user cannot logon with its original local
password, which is filled into LDAP with "{crypt$1$TeOlOcMc$cpQaa0WpLSFRC1HIHW5bt1"
Posted by sbjerry on 16 March 2011
Report abuse
Excellent article on openLDAP for beginners.
Posted by Meghanand on 26 May 2010
Report abuse
Print this page

Share this page

Follow developerWorks


Feeds and apps

Report abuse




Terms of use


Contact us

IBM privacy

Business Partners

Submit content

IBM accessibility