Setting up an LDAP client
From BNL Physics Computing
This topic describes how to setup a client that will store user info and authenticate against the Physics Dept. S.C. LDAP server.
Contents |
Overview
LDAP authentication is done through the PAM stack so the OS must obviously support the PAM LDAP module. Most modern Linux based distributions do. SGI IRIX needs to be relatively new (6.5.22m). Other unix-like OS have not been tried.
The rest of this document is geared towards a Debian GNU/Linux client.
Preliminary
Make sure the hostname is correct in /etc/hosts. If it isn't it will cause total mystifying failures. It should be like:
[the.ip.number] [client.fqdn.bnl.gov] [client]
Installation
apt-get install libpam-ldap libnss-ldap apt-get install ldap-utils openssl nscd
Note, the second set is not strictly required. The ldap-utilsprovides ldapadd/ldapmodify and are needed for populating and testing. Openssl is only needed if you are using SSL (you should unless localhost is server). Nscd is a client side cache. It's actually best to turn this off while setting up.
To make use of the (non-standard) home directory information then also
apt-get install am-utils
And place copies of the
amd.conf amd.home.sh
files in /etc/am-utils. Note that the am-utils in Debian "sarge" does not support the required "executable map". Need "etch" at least.
Configuration
/etc/ldap/ldap.conf
This contains generic LDAP client defaults and should look like;
BASE dc=phy,dc=bnl,dc=gov URI ldaps://home.phy.bnl.gov TLS_CACERT /etc/ssl/certs/ldap.cert TLS_REQCERT allow
The SSL cert files need to be provided by the server admin and copied into the specified location by the client admin.
/etc/nsswitch.conf
This tells the system where to go for various user and system information. Currently all that is supported is user account info so "ldap" only needs to be added to:
passwd: files ldap
In particular do not add "ldap" to the "shadow:" line.
/etc/libnss-ldap.conf
This tells the name service switch how to talk to the ldap server. It should contain these lines:
base dc=phy,dc=bnl,dc=gov uri ldaps://home.phy.bnl.gov ldap_version 3 pam_check_host_attr yes pam_password exop
/etc/pam_ldap.conf
This tells PAM how to talk to LDAP and essentially has identical contents as libnss-ldap:
base dc=phy,dc=bnl,dc=gov uri ldaps://home.phy.bnl.gov ldap_version 3 pam_check_host_attr yes pam_password exop
The PAM stack
PAM has to be told how to interpret information from LDAP. This is done by modifying the contents of /etc/pam.d files. This section is very Debian specific interms of the file names.
/etc/pam.d/common-auth:
auth [success=1 default=ignore] pam_unix.so auth required pam_ldap.so use_first_pass auth required pam_permit.so
/etc/pam.d/common-account:
account [success=1 default=ignore] pam_unix.so account [success=ok new_authtok_reqd=ok ignore=ignore default=bad perm_denied=bad] pam_ldap.so account required pam_permit.so
/etc/pam.d/common-passwd:
password sufficient pam_ldap.so password required pam_unix.so nullok obscure min=4 max=8 md5
/etc/pam.d/common-session:
session required pam_unix.so session optional pam_ldap.so
Optional Configuration
More Secure Passwords with Cracklib
Install:
apt-get install libpam-cracklib
And make /etc/pam.d/common-passwd look like:
password required pam_cracklib.so retry=3 minlen=12 lcredit=2 ucredit=2 ocredit=2 dcredit=2 password sufficient pam_unix_passwd.so use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so
Ignore Shadow Password Aging Info
On some clients you may want to ignore password aging. For example if you have set up SSH to disallow password-interactive (and only rely on, say, SSH keys) then it is silly to bother the user to change a password that is never used on that particular system.
Unfortunately, there is no way to tell pam_ldap to ignore the shadow password information that is traditionally interpreted to implement password aging. However, there is a simple patch available in Debian bug report 434947 that adds a no_shadow option. If this patch is applied and the resulting pam_ldap.so is used, the configuration would look like this example, taken from Debian's setup:
# Standard Un*x authorization. #@include common-account account [success=1 default=ignore] pam_unix.so account [success=ok new_authtok_reqd=ok ignore=ignore default=bad perm_denied=bad] pam_ldap.so no_shadow account required pam_permit.so
Testing the setup
A simple test of connectivity with the server. The following should return non-privileged information about the server admin:
client:~# ldapsearch -x employeeNumber=22351 ... # bviren, People, phy.bnl.gov dn: uid=bviren,ou=people,dc=phy,dc=bnl,dc=gov ...
Basics of handling user info
Existing users already in LDAP can now gain access to the new client if an attribute is added to their record like:
host: newclient.phy.bnl.gov
To add new users the easiest thing to do is write a small file in LDIF format (same format as comes from ldapsearch) and run:
ldapmodify -x -v -D cn=manager,dc=phy,dc=bnl,dc=gov -W < newuser.ldif
This will prompt for the LDAP server's manager password.
There are also numerous GUI tools to browse and edit an LDAP server. One in particular which is Java based and found to be the most useful can be found at http://www.iit.edu/~gawojar/ldap .
However, the home grown script described in LDAP management tools have been developed to work efficiently with this LDAP server as well as ITD's central LDAP and XML-RPC account services systems.
