|Linux System Administration|
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:
1. OpenLDAP client install
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. ~# _
4. PAM configuration
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):
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
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
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
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.
6. See also
7. Further reading