OpenLDAP client on Debian squeeze

Not only is OpenLDAP a useful tool in which to store information, such as the names, phone numbers and addresses of everyone in an organization, but it can also be used to store Unix account information. Not only that, but it can store passwords as well, which means that it can be used for authentication as well as authorization.

This article builds on a previous one in which an OpenLDAP provider server was set up, called ldaps1.example.com, containing a user account (ccolumbus) with a matching password (NewWorld). The goal is to set up a client machine that is capable of using this LDAP account for both authentication and authorization, as well as creating a new home directory for it on the first successful login attempt.

A word of warning, however. Although this is an interesting and educational exercise, as a solution it does not include any encryption whatsoever. In other words, login names, passwords and data are sent over the network as clear text, which means that it cannot in any way be considered secure.

In this example, client software for OpenLDAP is installed on a host running Debian 6.0 (squeeze). If followed properly, the step-by-step process should produce a new client machine.

Before the actual OpenLDAP installation process can begin, it will first be necessary to install Debian squeeze on a new host called ldapc1.example.com. A DNS server must also be available on the network with a zone file to which forward and reverse mappings can be added for this host. After the initial installation of the operating system, make sure these packages are installed on the system as well:

~# apt-get install ssh nmap

Now the installation process for the OpenLDAP client can begin:

On the new host, ldapc1.example.com, run the following command to test if the previously installed OpenLDAP server is actually available on the network:

~# nmap -p 389 ldaps1.example.com

Starting Nmap 5.00 ( http://nmap.org ) at 2010-11-15 16:33 CET
Interesting ports on ldaps1.example.com (192.168.2.49):
PORT    STATE SERVICE
389/tcp open  ldap
MAC Address: 08:00:27:8D:1F:25 (Cadmus Computer Systems)

Nmap done: 1 IP address (1 host up) scanned in 0.20 seconds
~# _

If it is available, that is what the result looks like. Note that the state of the port is open. If there is a problem, fix it first. If not, continue by installing these three packages:

~# apt-get install libnss-ldap libpam-ldap nscd

As a result, only these three packages are installed:

libnss-ldap             264-2.2                    NSS module for using LDAP as a naming service
libpam-ldap             184-8.5                    Pluggable Authentication Module for LDAP
nscd                    2.11.2-7                   Embedded GNU C Library: Name Service Cache Daemon

During the installation procedure, some questions will be asked about two of these packages, first, about libnss-ldap. Answer them as follows:

LDAP server URI: ldap://ldaps1.example.com/
Distinguished name of the search base: dc=example,dc=com
LDAP version to use: 3
LDAP account for root: cn=manager,dc=example,dc=net
LDAP root account password: 

To be sure, the third question is left at its default and no password is given for the fourth, because in this case an LDAP account for the root user is unncessary. These four questions are immediately followed by two more regarding libpam-ldap. Answer them as follows:

Allow LDAP admin account to behave like local root? No
Does the LDAP database require login?: No

Since the debconf configuration of libnss-ldap can be improved upon if performed a second time, use this command to reconfigure it:

~# dpkg-reconfigure libnss-ldap

The questions are a little different the second time around. Answer them as follows:

LDAP server Uniform Resource Identifier: ldap://ldaps1.example.com/
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/writeable by its owner only? No

NB: Regarding the question of which LDAP server to use, this field supports mutiple server URIs (URLs), which can be filled in here, just like in the next step.

These three packages − nscd, libnss-ldap and libpam-ldap − not only make it possible for users with accounts that exist only in LDAP to log into hosts that they have never before logged into, but also help all users − including those with Unix-only accounts − to resolve the UID and GID numbers of files owned by users with LDAP accounts.

In scenarios unlike this one, where the OpenLDAP server does not allow anonymous queries, libnss-ldap will require an LDAP account with which authenticate and search the DIT independently. And since nscd, for which libnss-ldap is a module, runs as root, that is why an LDAP account is requested for root; it does not mean that an account is required with administrative access to the DIT!

Edit /etc/ldap/ldap.conf and use these two lines:

BASE    dc=example,dc=com
URI     ldap://ldaps1.example.com/

This configuration file is used to set system-wide defaults for LDAP clients.

As is mentioned in the dialog during the install procedure for libnss-ldap, the /etc/nsswitch.conf configuration file needs to be edited before authentication and authorization via LDAP can work. These are the necessary changes that must be made to it:

passwd:		compat ldap
group:		compat ldap
shadow:		compat ldap

Then, restart the Name Service Cache Daemon:

~# /etc/init.d/nscd restart
Restarting Name Service Cache Daemon: nscd.
~# _

Only one of the five files below will be modified − the rest is informational. PAM plays an important role in the local authentication process and since its configuration is modified when libpam-ldap is installed, it is good to know what is going on. PAM is both a relatively complex subject and a recurring theme, so a dedicated page (PAM configuration guide for Debian) was created for it. Those unfamiliar with its workings are advised to read it. Otherwise, the default PAM configuration for Debian squeeze with libpam-ldap is as follows (the format has been simplified for the sake of clarity):

/etc/pam.d/common-auth:

auth	 [success=2 default=ignore]			  pam_unix.so nullok_secure try_first_pass
auth	 [success=1 default=ignore]			  pam_ldap.so use_first_pass
auth	 requisite					  pam_deny.so
auth	 required					  pam_permit.so

/etc/pam.d/common-account:

account	 [success=2 new_authtok_reqd=done default=ignore] pam_unix.so
account  [success=1 default=ignore]			  pam_ldap.so
account	 requisite					  pam_deny.so
account	 required					  pam_permit.so

/etc/pam.d/common-password:

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
password requisite					  pam_deny.so
password required					  pam_permit.so

Edit /etc/pam.d/common-session and add one line to the very end of the file:

session	 [default=1]					  pam_permit.so
session	 requisite					  pam_deny.so
session	 required					  pam_permit.so
session	 required					  pam_unix.so
session	 optional					  pam_ldap.so

session	 required					  pam_mkhomedir.so

/etc/pam.d/common-session-noninteractive:

session	 [default=1]					  pam_permit.so
session	 requisite					  pam_deny.so
session	 required					  pam_permit.so
session	 required					  pam_unix.so
session	 optional					  pam_ldap.so

In this modified PAM configuration, three new modules are introduced:

In /etc/pam.d/common-password, two new setting have been added to the pam_unix.so module: use_authtok, which forces it to set the new password to the one used for the previous module, and try_first_pass, which forces it to use the password that was used for the previous module so as to avoid prompting the user.

At this point it should be possible to authenticate to the new client using the LDAP account created previously on the server (ccolumbus, password: NewWorld). If all goes well, a matching home directory will be created automatically upon login and, despite a lack of any related Unix account information in /etc/passwd or /etc/group, the UID and GID of the new home directory will be resolved to the new account name anyway, thanks to LDAP. These LDAP-created UIDs and GIDs will be resolved for all users of this host, including the ones that only have local Unix accounts, provided the LDAP server remains available.

• OpenLDAP provider on Debian squeeze
• OpenLDAP consumer on Debian squeeze
• OpenLDAP client on Debian lenny
• PAM configuration guide for Debian
• DNS discovery for OpenLDAP

• Eastlake D, Panitz A. 1999. RFC2606 − Reserved Top Level DNS Names. The Internet Society. HTML at the Internet FAQ Archives.
• Hodges J, Morgan R. 2002. RFC3377 − Lightweight Directory Access Protocol (v3): Technical Specification. The Internet Society. HTML at the Internet FAQ Archives.
• Wahl M, Howes T, Kille S. 1997. RFC2251 − Lightweight Directory Access Protocol (v3). The Internet Society. HTML at the Internet FAQ Archives.
• Yeong W, Howes T, Kille S. 1993. RFC1487 − X.500 Lightweight Directory Access Protocol. The Internet Society. HTML at the Internet FAQ Archives.

• Carter G. 2003. LDAP System Administration. O'Reilly & Associates, Inc. ISBN 1-56592-491-6. 294 pp.
• Morgan AG. 2001. Pluggable Authentication Modules (PAM). Open-PAM working group. Text at The Kernel Archives.
• Morgan AG, Kukuk T. 2010. The Linux-PAM System Administrator's Guide. HTML at The Kernel Archives..
• Ocelic D. 2006-2010. Debian GNU: Setting up OpenLDAP. HTML at Spinlock Solutions.