Install OpenLDAP on Debian GNU, Ubuntu, and Devuan GNU+Linux

Davor Ocelic

<docelic@spinlocksolutions.com>

Last update: Apr 21, 2019. — Verify everything is up to date

This documentation is free; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

It is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

Abstract

The purpose of this article is to give you a straightforward, Debian/Ubuntu-friendly way of installing and configuring OpenLDAP.

By the end of this guide, you will have a functional LDAP server that will serve as a central authentication system for user logins onto all machines in the network, without the need to manually create users' accounts on individual machines.

However, for improved authentication security and a true networked solution, it is recommended to use LDAP in combination with Kerberos, with a matching Kerberos setup explained in MIT Kerberos 5 Guide.
(If you would be interested in that solution, follow the MIT Kerberos 5 Guide first.)

This article is part of Spinlock Solutions's practical 3-piece introductory series to infrastructure-based Unix networks, containing MIT Kerberos 5 Guide, OpenLDAP Guide and OpenAFS Guide.

Table of Contents

Introduction

The role of LDAP within a network
Glue layers: integrating LDAP with system software
Conventions

OpenLDAP

Server installation
Initial configuration
Initial test
Creating basic tree structure
Creating user accounts
NSS configuration
PAM configuration
Logging in into the system

Conclusion

Links

Introduction

LDAP is a service that has been traditionally captivating system administrators' and advanced users' interest, but its (seemingly or not) high entry barrier and infrastructure requirements have been preventing many from using it.

LDAP has already been the topic of numerous publications. Here, we will present only the necessary summary; enough information to establish the context and to achieve practical results.

You do not need to follow any external links; however, the links have been provided both throughout the article and listed all together at the end, to serve as pointers to more precise technical treatment of individual topics.

The role of LDAP within a network

OpenLDAP is an open source implementation of the Lightweight Directory Access Protocol. Directory itself is a tree-structured, read-optimized database. Yellow pages or a phonebook are good associations to have in mind, even though LDAP is much more powerful.

We will use OpenLDAP to provide a central authentication location for user logins anywhere on the network, with their home directories being automatically created on their first access to individual machines.

This guide can be followed standalone to make OpenLDAP both perform authentication and serve user meta data. However, using LDAP for authentication as shown here is not secure due to plain text connections made to the LDAP server and passwords traveling over the wire. It is therefore advised to use LDAP in combination with a superior and secure network authentication mechanism Kerberos, which is explained in another article from the series, the MIT Kerberos 5 Guide.

That said, let's move onto our LDAP setup.

From a technical perspective, LDAP directory consists of a set of hierarchically organized entries. Each entry belongs to certain Object Classes and contains various key=value pairs called attributes.

Each entry is uniquely identified by a Distinguished name ("DN"). DN is formed as a list of components, separated by commas, that provide "full path" to the entry, starting from the top of the tree. For example, company Example, Inc. would have the root of the tree in dc=example,dc=com. A person employed by Example, Inc. would then have a corresponding LDAP entry with DN cn=person,ou=People,dc=example,dc=com.

Which attributes may or must be present in an entry is governed by the entry's objectClasses.

You might notice that the individual components of the DN, such as cn=person above, are also formed as key=value pairs. Those "keys", cn, ou and dc, stand for Common Name, Organizational Unit and Domain Component. They are a part of every-day LDAP terminology that you will get used to.

Let's quickly identify LDAP-specific elements in our setup:

LDAP is not in any way related to traditional system usernames or other data. However, part of its functionality in our setup will consist in storing information traditionally found in Unix files /etc/passwd and /etc/group, thus making that data network-accessible at a centralized location.
People's login names will be used in pairing people with the corresponding information in the LDAP tree. For example, username person will map to an LDAP entry uid=person,ou=People,dc=example,dc=com.
LDAP can be configured to contain user passwords. Passwords can be used both for authenticating as specific users and gaining access to protected entries, and for verifying whether the user knows the correct password.
When a user opens an LDAP client and moves to browse the directory, their DN and password are used to establish the identity and access privileges. When LDAP is configured to perform user authentication, their DN and password are only used to perform a connection to the LDAP directory — successful connection ("bind") implies the user knew the correct password.

You can find the complete OpenLDAP documentation at the OpenLDAP website. For an authoritative OpenLDAP book, see Gerald Carter's LDAP System Administration by O'Reilly.

Glue layers: integrating LDAP with system software

NSS

On all GNU/Linux-based platforms, NSS is available for network data retrieval configuration. NSS is an implementation of the Name Service Switch mechanism.

NSS will allow for inclusion of LDAP into the "user data" path of all services, regardless of whether they natively support LDAP or not.

You can find the proper introduction (and complete documentation) on the NSS website. Also take a look at the nsswitch.conf(5) manual page.

PAM

Likewise, on all GNU/Linux-based platforms, another piece of the puzzle, Linux-PAM, is available for service-specific authentication configuration. Linux-PAM is an implementation of PAM ("Pluggable Authentication Modules") from Sun Microsystems.

Network services, instead of having hard-coded authentication interfaces and decision methods, invoke PAM through a standard, pre-defined interface. It is then up to PAM to perform any and all authentication-related work, and report the result back to the application.

Exactly how PAM reaches the decision is none of the service's business. In traditional set-ups, that is most often done by asking and verifying usernames and passwords. In advanced networks, that could be retina scans or — Kerberos tickets, as explained in another article from the series, MIT Kerberos 5 Guide.

You can find the proper introduction (and complete documentation) on the Linux-PAM website. Pay special attention to the PAM Configuration File Syntax page. Also take a look at the Linux-PAM(7) and pam(7) manual pages.

Conventions

Let's agree on a few conventions before going down to work:

Our platform of choice, where we will demonstrate a practical setup, will be Debian GNU. The setup will also work on Ubuntu, and if any notable differences exist they will be noted.
If using Debian GNU, install and configure sudo. On Ubuntu sudo will already be installed and configured to work for your regular user account.
Sudo is a program that will allow you to carry out system administrator tasks from your normal user account. All the examples in this article requiring root privileges use sudo, so you will be able to copy-paste them to your shell.
To install sudo on Debian GNU only, run:
```
su -c 'apt-get install sudo'
```
If asked for a password, type in the root user's password.
To configure sudo on Debian GNU only, run the the following, replacing USERNAME with your login name:
```
su -c 'echo "USERNAME ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers'
```
Packages that we will install during the complete procedure will ask us a series of questions through the so-called debconf interface. To configure debconf to a known state, run:
```
sudo dpkg-reconfigure debconf
```
When asked, answer interface=Dialog and priority=low.
Monitoring log files is crucial in detecting problems. The straightforward, catch-all routine to this is opening a terminal and running:
```
cd /var/log; sudo tail -F daemon.log sulog user.log auth.log debug kern.log syslog dmesg messages kerberos/{krb5kdc,kadmin,krb5lib}.log
```
The command will keep printing log messages to the screen as they arrive.
Our test system will be called monarch.example.com and have an IP address of 192.168.7.12. Both the server and the client will be installed on the same machine. However, to differentiate between client and server roles where relevant, the client will be referred to as monarch.example.com and the server as ldap1.example.com. The following addition will be made to /etc/hosts to completely support this scheme:
```
192.168.7.12	monarch.example.com monarch krb1.example.com krb1 ldap1.example.com ldap1
```
Caution
Note that in some installations the system's network hostname is assigned to the localhost address 127.0.0.1. This can and will cause problems for network operations, so make sure that your "localhost" entry in /etc/hosts looks exactly like the following (nothing more, nothing less):
```
127.0.0.1  localhost
```
Finally, test that the network setup is as expected. Pinging the hostnames should report proper FQDNs and IPs as shown:
```
ping -c1 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
....

ping -c1 monarch
PING monarch.example.com (192.168.7.12) 56(84) bytes of data.
....

ping -c1 ldap1
PING ldap1.example.com (192.168.7.12) 56(84) bytes of data.
....
```

OpenLDAP

Server installation

OpenLDAP's server component is called slapd, and is basically all that we will need.

sudo apt-get install slapd ldap-utils

Debconf answers for reference:

Omit OpenLDAP server configuration? No

DNS domain name: example.com

Organization name? example.com

Administrator password: PASSWORD

Confirm password: PASSWORD

Database backend to use: MDB

Do you want the database to be removed when slapd is purged? No

Allow LDAPv2 protocol? No

As soon as the installation is done, the OpenLDAP server (command slapd) will start.

Initial configuration

Introduction

For a general introduction, it is important to know that the server-side configuration, including the ObjectClasses, attributes, syntaxes, matching rules and other details of the LDAP data structure are, at startup, loaded from the configuration files found under the directory /etc/ldap/slapd.d/.

These configuration files are kept in the LDIF format. It is expected that the configuration would be modified using standard LDAP data modification utilities in runtime, and not via editing text config files. The slapd server would then save the new values as LDIF files to preserve configuration data across restarts.

However, when manual interventions to the files are required, the LDIF-formatted files still allow for reasonably convenient text-based editing.

This configuration style, modifiable in runtime, is known under a couple different names, notably olc (On-Line Configuration), cn=config, and/or slapd.d.

Previously, OpenLDAP used a standard, text-based configuration file found in /etc/ldap/slapd.conf. However, while still supported, that approach is no longer recommended as it requires server restarts to apply configuration changes, and cn=config is nowadays the default method.

Note

Since the /etc/ldap/slapd.conf configuration has traditionally been documented in this Guide, it will be kept listed in addition to slapd.d for reference, but it should be considered obsolete.

If you happen to have a /etc/ldap/slapd.conf file in your configuration and no /etc/ldap/slapd.d/ directory, convert to slapd.d by running:

sudo slaptest -f /etc/ldap/slapd.conf -F /etc/ldap/slapd.d

And then make sure that your slapd has been started with -F /etc/ldap/slapd.d instead of with -f /etc/ldap/slapd.conf by running the following two checks:

grep -e -F /etc/init.d/slapd
ps aux | grep slapd

(Both should list "-F" instead of "-f".)

cn=config configuration

The cn=config is a special LDAP database that stores the OpenLDAP server configuration, and is viewable and modifiable in runtime.

Changes made to it are instantly applied to the running server and are also saved under /etc/ldap/slapd.d/, to preserve the configuration across server restarts.

So here is what we want to do:

To make the necessary configuration changes, we want to take advantage of the existing, default configuration in cn=config which is allowing local root user to connect to the slapd socket in /var/run/slapd/ldapi and modify the cn=config database.

Using this approach, we first want verify that all the necessary LDAP schema definitions (core, cosine, nis and inetorgperson) have been loaded.
Any errors about duplicate entries in this step are fine, and the relevant part that is instructing our client to authenticate as local user and to connect to the slapd Unix socket is "-Y EXTERNAL -H ldapi:///":

sudo ldapadd -c -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/core.ldif
sudo ldapadd -c -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif
sudo ldapadd -c -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/nis.ldif
sudo ldapadd -c -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/inetorgperson.ldif

(Another way to verify whether these schemas are loaded is to run ls -al /etc/ldap/slapd.d/cn=config/cn=schema/.)

Then we want to increase log level by replacing the default "olcLogLevel: none" with "olcLogLevel: 256":

echo "dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: 256" > /var/tmp/loglevel.ldif

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /var/tmp/loglevel.ldif

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

Then we also want to verify/add an "eq" (equality) search index for the attribute "uid" (again errors about duplicate entries are OK):

echo "
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: uid eq
" > /var/tmp/uid_eq.ldif

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /var/tmp/uid_eq.ldif

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}mdb,cn=config"

And finally, we want to allow the LDAP administrator account to see and modify the cn=config configuration database in the same way that write access would be granted on the actual data tree dc=example, dc=com.
This will effectively allow accessing and modifying slapd configuration from any location as long as the user knows the correct administrator DN and password. It will come very handy in the learning phase, for viewing and modifying the configuration using a graphical LDAP client:

echo "dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcAccess
olcAccess: to * by dn="cn=admin,dc=example,dc=com" write" > /var/tmp/access.ldif

sudo ldapmodify -c -Y EXTERNAL -H ldapi:/// -f /var/tmp/access.ldif

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={0}config,cn=config"

slapd.conf configuration (obsolete)

For reference, here is the equivalent configuration as the above, in the old slapd.conf style:

Note

This whole section should be ignored unless you are purposely using /etc/ldap/slapd.conf or are attempting to compare it to slapd.d.

Make sure all the schema files are enabled:

include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema

Change the verbosity level from 0 or "none" to 256:

loglevel 256

Search for line "index objectClass eq" and add another search index. In particular combinations, it may be possible to receive no results when the searched entries are not indexed, so this step is important:

index           objectClass eq
index           uid         eq

To make the new index option apply, run the following commands:

sudo invoke-rc.d slapd stop
sudo slapindex
sudo chown -R openldap:openldap /var/lib/ldap
sudo invoke-rc.d slapd start

Client-side configuration

Our OpenLDAP server is already running, so let's configure /etc/ldap/ldap.conf, a common configuration file for all LDAP clients. This will allow us to run ldapsearch and other commands without having to specify all the basic parameters by hand each time.

Enable the following two lines in /etc/ldap/ldap.conf, creating the file if necessary:

BASE  dc=example, dc=com
URI ldap://192.168.7.12/

Initial test

It's already the time to test the installation. Our OpenLDAP server does not contain much information, but a basic read operation can be performed normally.

In LDAP terms, read operation is called a "search". To perform a search using generic command-line utilities, we have ldapsearch and slapcat available.

Ldapsearch (and other LDAP utilities prefixed "ldap") perform operations "online", using the LDAP protocol.

Slapcat (and other OpenLDAP utilities prefixed "slap") perform operations "offline", directly by opening files on the local filesystem. For this reason, they can only be ran locally on the OpenLDAP server and they require administrator privileges. When they involve writing to the database, the OpenLDAP server usually needs to be stopped first.

In the output of the two search commands, you will notice two LDAP entries, one representing the top level element in the tree, and another representing the LDAP administrator's entry. In the slapcat output, notice the extra attributes not printed with ldapsearch. One of those is userPassword, which is not shown to us when we are anonymously accessing the directory using ldapsearch, due to the default access restrictions in place.

ldapsearch -x

# extended LDIF
#
# LDAPv3
# base <dc=example, dc=com> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: example.com
dc: example

# admin, example.com
dn: cn=admin,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

sudo slapcat

dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: example.com
dc: example
structuralObjectClass: organization
entryUUID: 350a2db6-87d3-102c-8c1c-1ffeac40db98
creatorsName:
modifiersName:
createTimestamp: 20080316183324Z
modifyTimestamp: 20080316183324Z
entryCSN: 20080316183324.797498Z#000000#000#000000

dn: cn=admin,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e2NyeXB0fVdSZDJjRFdRODluNHM=
structuralObjectClass: organizationalRole
entryUUID: 350b330a-87d3-102c-8c1d-1ffeac40db98
creatorsName:
modifiersName:
createTimestamp: 20080316183324Z
modifyTimestamp: 20080316183324Z
entryCSN: 20080316183324.804398Z#000000#000#000000

Creating basic tree structure

As explained, the LDAP database is structured as a tree. The top level element in the tree for your organization is often its domain name. In case of a domain example.com, the toplevel tree element would be dc=example,dc=com.

On the next level below, an organization is often divided into "organizational units", such as people, groups, hosts, services, networks, protocols, etc.

Accordingly, to support people's Unix "meta data" in our LDAP directory, we will be interested in creating two of the mentioned organizational units, People and Group. The two will roughly correspond to the Unix /etc/passwd and /etc/group files.

Ldap data is interchanged in a textual format called LDIF. Command-line LDAP utilities receive and produce data in this format. Note that the LDIF stream can also contain commands, such as for adding, modifying or removing LDAP entries.

Knowing this, we'll put together a simple LDIF file, /var/tmp/ou.ldif, that will instruct the server to add the two organizational units. Pay attention to the empty line separating the entries:

dn: ou=People,dc=example,dc=com
ou: People
objectClass: organizationalUnit

dn: ou=Group,dc=example,dc=com
ou: Group
objectClass: organizationalUnit

To load the LDIF file into the server, let's show an example using the offline tool, slapadd:

sudo invoke-rc.d slapd stop
sudo slapadd -c -v -l /var/tmp/ou.ldif

added: "ou=People,dc=example,dc=com" (00000003)
added: "ou=Group,dc=example,dc=com" (00000004)
_#################### 100.00% eta   none elapsed            none fast!         
Closing DB...

sudo invoke-rc.d slapd start

Let's use ldapsearch to verify the entries have been created.

ldapsearch -x ou=people

# extended LDIF
#
# LDAPv3
# base <dc=example, dc=com> (default) with scope subtree
# filter: ou=people
# requesting: ALL
#

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

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Creating user accounts

In the same manner we've created the two organizational units, let's create our first group and a person belonging to it. Again, we approach the problem by constructing and loading an LDIF file, /var/tmp/user1.ldif, paying attention to the empty line separating the entries:

dn: cn=jirky,ou=group,dc=example,dc=com
cn: jirky
gidNumber: 20000
objectClass: top
objectClass: posixGroup

dn: uid=jirky,ou=people,dc=example,dc=com
uid: jirky
uidNumber: 20000
gidNumber: 20000
cn: Mirko
sn: Mirko
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
loginShell: /bin/bash
homeDirectory: /home/jirky

To load the LDIF file into the server, let's show an example using the online tool, ldapadd. Since, as said previously, ldapadd uses the LDAP protocol, we'll have to bind to the server as system administrator and type in the correct admin password (defined during slapd installation):

ldapadd -c -x -D cn=admin,dc=example,dc=com -W -f /var/tmp/user1.ldif

Enter LDAP Password: PASSWORD

adding new entry "cn=jirky,ou=group,dc=example,dc=com"

adding new entry "uid=jirky,ou=people,dc=example,dc=com"

Now to define the new user's password, let's run an online tool ldappasswd. (This step is not needed if you plan to use LDAP in combination with Kerberos as explained in MIT Kerberos 5 Guide.)

ldappasswd -x -D cn=admin,dc=example,dc=com -W -S uid=jirky,ou=people,dc=example,dc=com

New password: NEW USER PASSWORD

Re-enter new password: NEW USER PASSWORD

Enter LDAP Password:  ADMIN PASSWORD

Result: Success (0)

Note

You might notice that all entries always have to be "fully qualified" and that you cannot omit the suffix (dc=example,dc=com) or other components of the DN. This often leads to command line examples that are long and cryptic, and look just like boring, unnecessary work. If you perceive that as a problem, you'll solve it by either getting accustomed to it to the point of not noticing it any more, or you will later switch to using graphical LDAP clients that fill in most of that information for you.

Now let's use ldapsearch to verify the user entry has been created. Note that the password field, userPassword, will not be shown even if we created it, due to the configured access restrictions that apply to anonymous users.

ldapsearch -x uid=jirky

# extended LDIF
#
# LDAPv3
# base <dc=example, dc=com> (default) with scope subtree
# filter: uid=jirky
# requesting: ALL
#

# jirky, people, example.com
dn: uid=jirky,ou=people,dc=example,dc=com
uid: jirky
uidNumber: 20000
gidNumber: 20000
cn: Mirko
sn: Mirko
objectClass: top
objectClass: person
objectClass: posixAccount
loginShell: /bin/bash
homeDirectory: /home/jirky

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Congratulations! You now have a working LDAP setup.

NSS configuration

Now that we have a new user created in LDAP, we should allow the system to see it. For example, let's test for existence of users root and jirky. The administrator will be present, while jirky will not:

id root
uid=0(root) gid=0(root) groups=0(root)

id jirky
id: jirky: No such user

To enable the system see and use LDAP accounts, we need to install libnss-ldap, libpam-ldap and nscd.

sudo apt-get install libnss-ldap libpam-ldap nscd

All debconf answers for reference:

LDAP server URI: ldap://192.168.7.12/ (Note the "ldap://", not "ldapi://")

Distinguished name of the search base: dc=example,dc=com

LDAP version to use: 3

Does the LDAP database require login? No

Special LDAP privileges for root? No

Make the configuration file readable/writable by its owner only? No

Allow LDAP admin account to behave like local root? Yes

Make local root Database admin. No

Does the LDAP database require login? No

LDAP administrative account: cn=admin,dc=example,dc=com

LDAP administrative password: PASSWORD

Local crypt to use when changing passwords. md5

PAM profiles to enable: --->
  If not using Kerberos, select 'Unix authentication' and 'LDAP Authentication'
  If using Kerberos, select 'Unix authentication' and 'Kerberos authentication'

Debconf answers will be saved and reflected in the configuration file /etc/libnss-ldap.conf. To confirm the configuration, locate and verify the following two lines in /etc/libnss-ldap.conf:

base dc=example,dc=com
uri ldap://192.168.7.12/

Finally, to activate the LDAP NSS module, edit /etc/nsswitch.conf by replacing the two lines mentioning passwd and group with the following:

passwd:         files ldap
group:          files ldap

Nscd (the Name Service Caching Daemon) is used to cache metadata locally, instead of querying the LDAP server each time. It is a very efficient service in the long run, but we will stop it for for the moment, during testing, to always retrieve the data directly from the LDAP server:

sudo invoke-rc.d nscd stop

Now we can verify that LDAP users have become visible:

id jirky

uid=20000(jirky) gid=20000(jirky) groups=20000(jirky)

PAM configuration

The final step in this article pertains to integrating LDAP into the system authentication procedure.

We will need to verify the configuration of the package libpam-ldap that has been installed in the previous step.

The default PAM configuration will require the user to be present either in the local password file or in LDAP, and to know the correct password, for the authentication process to continue.

First, the debconf answers related to libpam-ldap have already been saved and reflected in the configuration file /etc/pam_ldap.conf.
To confirm the configuration, locate and verify the following two lines in /etc/pam_ldap.conf:

base dc=example,dc=com
uri ldap://192.168.7.12/

Second, the answer to the debconf question "PAM profiles to enable" has aso been reflected in the four PAM-related configuration files: /etc/pam.d/common-account, /etc/pam.d/common-auth, /etc/pam.d/common-password and /etc/pam.d/common-session.

Here's how the active parts of these config files should look like, for reference:

/etc/pam.d/common-account

# Disable if using Kerberos:
account [success=2 new_authtok_reqd=done default=ignore]        pam_unix.so
account [success=1 default=ignore]      pam_ldap.so

# Enable if using Kerberos:
#account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so

account requisite                       pam_deny.so

account required                        pam_permit.so

# Enable if using Kerberos:
#account required                        pam_krb5.so minimum_uid=1000

/etc/pam.d/common-auth

# Disable if using Kerberos:
auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_ldap.so use_first_pass

# Enable if using Kerberos:
#auth    [success=2 default=ignore]      pam_krb5.so minimum_uid=1000
#auth    [success=1 default=ignore]      pam_unix.so nullok_secure try_first_pass

auth    requisite                       pam_deny.so

auth    required                        pam_permit.so

/etc/pam.d/common-password

# Disable if using Kerberos:
password        [success=2 default=ignore]      pam_unix.so obscure sha512
password        [success=1 user_unknown=ignore default=die]     pam_ldap.so use_authtok try_first_pass

# Enable if using Kerberos:
#password        [success=2 default=ignore]      pam_krb5.so minimum_uid=1000
#password        [success=1 default=ignore]      pam_unix.so obscure use_authtok try_first_pass sha512

password        requisite                       pam_deny.so

password        required                        pam_permit.so

/etc/pam.d/common-session

session [default=1]                     pam_permit.so

session requisite                       pam_deny.so

session required                        pam_permit.so

# Enable if using Kerberos:
#session  optional  pam_krb5.so minimum_uid=1000

session required        pam_unix.so 

# Disable if using Kerberos:
session optional                        pam_ldap.so

It is advisable not to be making basic changes in these files manually, as modifications require detailed knowledge of the PAM config file syntax.
Changes can be made by running the following line that will reconfigure the package and re-generate the configuration files:

sudo dpkg-reconfigure libpam-ldap

For manual modifications, you will want to look at PAM Configuration File Syntax and pay special attention to seemingly insignificant variations — with PAM, they often make a whole world of difference.

Finally, you will want to start nscd that was stopped during one of the previous steps:

sudo invoke-rc.d nscd start

Note that authentication through LDAP, as shown here, is not secure, due to connections to the LDAP server being made in plain text and passwords traveling over the wire.
Instead of encrypting the connection to the LDAP server, one could install Kerberos as explained in MIT Kerberos 5 Guide. If Kerberos is set up after LDAP, run dpkg-reconfigure libpam-ldap afterwards to choose "Unix authentication" and "Kerberos authentication" instead of "LDAP Authentication", and verify the resulting PAM configuration files as per the actual /etc/pam.d/ configs provided above.

Logging in into the system

When users authenticate successfully, and they log in, they will be placed in their home directory. In a central network authentication scheme, where the user accounts are created centrally instead of on the individual machines, their home directories may not exist on particular systems. This problem can be solved by using the pam_mkhomedir PAM module, which can create the users' home directories on the fly, if they are found missing during login.

Add the following line to the bottom of /etc/pam.d/common-session:

session required        pam_mkhomedir.so skel=/etc/skel/ umask=0022

Implicitly, this means that the users' home directories will be created separately on all of the individual machines they log in to. This may present a problem as people will have different files on different machines. It won't be completely unacceptable in itself if Kerberos is used as the Kerberized network will allow secure and passwordless copying of files between the machines, but it will still be far from a perfect solution. To solve that problem with an advanced, secure, heavy-duty distributed network filesystem, you could read the next article in the series, the OpenAFS Guide.

In any case, having everything adjusted as shown using pam_mkhomedir, login to the system should succeed as user jirky:

Login: jirky
Password: PASSWORD

Debian GNU/Linux tty5

Creating directory '/home/jirky'.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
jirky@host:~$

Conclusion

At this point, you have a functional LDAP installation.

You can rely on LDAP for central network authentication and sharing of user metadata (user IDs, group IDs, real names, group memberships, etc.).

With a good foundation we've built, for further information on LDAP, please refer to other available resources:

Official documentation: http://www.openldap.org/doc/admin24/
Mailing lists: http://www.openldap.org/lists/
IRC: channel #ldap at the Libera.Chat network (irc.libera.chat)
For commercial consultation and infrastructure-based networks containing LDAP, contact Spinlock Solutions or organizations listed on the OpenLDAP support page.

Finally, as said above, the described authentication through LDAP is not done in a network-secure manner, due to plain text connections and passwords traveling over the wire. To solve that problem, using Kerberos for network authentication instead of LDAP is recommended, as explained in the previous article in the series, the MIT Kerberos 5 Guide.

Also, as said above, the users' home directories will be created separately on all of the hosts the users would log in to. To solve that problem and have a shared home directory on all of the systems, using a distributed filesystem AFS is recommended, as explained in the next article in the series, the OpenAFS Guide.