- 1 Introduction
- 2 Installation
- 3 README
- 4 Configuration
- 5 Host-based Authentication
- 6 Credits
This page is intended for anyone who wants to enable an Ubuntu client to authenticate on an existing OpenLDAP server. For more details on the server installation part see OpenLDAPServer. If you want Kerberos as well for single-sign-on (likely), see SingleSignOn. For authenticating on a Sun Java Enterprise System Directory Server should consult the SunLDAPClientAuthentication page. For authenticating using a Mac OS X Leopard Server consult the OSXLDAPClientAuthentication page. For version 7.10 and later, see bottom of page for another way of doing it (auth-client-config).
Install the following packages:
libpam-ldap libnss-ldap nss-updatedb libnss-db (see InstallingSoftware). Note that you have to enable the universe repositories for this.
libpam-ldap to allows for authentication via LDAP. libnss-ldap provides account information (username, uid, groups, etc) via LDAP. That's why /etc/libnss-ldap.conf /etc/pam_ldap.conf have such similar structures.
During installation, you will be asked the following questions:
- The address of the LDAP server used. You can also use a fully qualified domain name here. For example: ldap.example.com
- The distinguished name of the search base. For example dc=example,dc=com
- The LDAP version to use. You usually would choose 3 here.
- If your database requires logging in. You would usually choose no here.
- If you want to make configuration readable/writeable by owner only. A no should be the answer to this.
- A Dialog is displayed explaining it cannot manage nsswitch.conf automatically. Just select OK.
- If you want the local root to be the database admin. You would usually choose yes here.
- Again If your database requires logging in. You would usually choose no here.
- Your root login account. For example: cn=manager,dc=example,dc=com
- Your root password.
- After, a dialog explaining the different encryption methods to specify the encryption method to use before sending your password. exop is usually a good choice.
The above steps might vary a bit depending on the Ubuntu distribution used. When you want to restart the configuration you can use
dpkg-reconfigure for both libpam-ldap and libnss-ldap packages.
When finished configuring you will need to double check the data in /etc/libnss-ldap.conf. Especially the 'host' entry which doesn't accept URI. Better is to use the 'uri' entries and comment out the 'host'.
- Be very careful when you use "sufficient pam_ldap.so" in Debian's
/etc/pam.d/common-*files: Some services can place other "required" PAM-modules after the includes, which will be ignored if pam_ldap.so succeeds. As a workaround, use something like the following construct:
- Check local authentication first, so root can still login
- while LDAP is down.
auth [success=1 default=ignore] pam_unix.so auth required pam_ldap.so use_first_pass auth required pam_permit.soThe third line is needed, so "success=1" can skip over one module and still has a module to jump to. Without that, PAM segfaults!
- If you want to use the "pam_check_host_attr" feature, make sure "pam_unix.so" doesn't provide a valid "account" via the Name Service Switch (NSS), which overrides your LDAP configuration. Don't use "ldap" for "shadow" in
/etc/nsswitch.conf, just use "shadow: files". For PAM, use something like the following:
- Try local /etc/shadow first and skip LDAP on success
account [success=1 default=ignore] pam_unix.so account required pam_ldap.so account required pam_permit.soIf you discover that cron is suddenly not running root's crontab after getting LDAP running on your client machine, and are getting messages in
then you may need to make these changes to
Apr 7 10:17:01 localhost CRON: Authentication token is no longer valid; new one required.
/etc/pam.d/common-account. First though, check that root's password hasn't really expired. This can happen even though the root account is locked if for some reason in the past you unlocked and relocked the root account. Run the command
chage -l root, and check if everything is OK. If the root password has expired, you can make it so that it never expires by running
sudo chage -E-1 root. If that wasn't the problem, then make the above changes to your PAM configuration.
- Ubuntu uses
/etc/ldap.confas libpam-ldap's configuration file and
/etc/ldap.secretas the file to store the password of the rootbinddn. This file is shared with libnss-ldap, which should work for most configurations. If separate configuration files for libnss-ldap and libpam-ldap are required, you can specify an alternate configuration file in
/etc/pam.d/common-*by adding a config=</path> argument to the pam_ldap.so entry, such as:
auth sufficient pam_ldap.so config=/etc/pam_ldap.confThis would let you have two separate configurations: /etc/ldap.conf for NSS, and
/etc/pam_ldap.conffor PAM. Thanks to Etienne Goyer for pointing this out.
LDAP-Permissions.txtfor details about the required LDAP permissions.
After the installation of the necessary packages you will need to configure the Name Service and PAM.
In /etc/nsswitch.conf replace compat with files ldap for both the passwd and group entries so you get something like this:
passwd: files ldap group: files ldap
There is a full example provided in the documentation of libnss-ldap: /usr/share/doc/libnss-ldap/examples/nsswitch.ldap Because the nscd daemon caches the lookup results, you need to restart it:
$ /etc/init.d/nscd restart
Now you can test the configuration:
$ getent passwd or $ getent group
You should see lines that look like they've come straight out of /etc/passwd. These are the lines 'published' by your LDAP server. If you do, the Name Service (NSS) side of the job is done. If not, check /etc/libnss-ldap.conf for typos. If your setup requires a password to connect to the LDAP server, don't forget to put that password into /etc/libnss-ldap.secret. BUG ALERT: Make sure /etc/libnss-ldap.conf has "bind_policy soft". If it's not there, a nasty bug with udev can arise at boot-time. You should probably also make this change in /etc/pam_ldap.conf. It's also a good idea to shorten the timeouts there. Don't use sudo when editing this file or leave it open while testing. If you save with a typo, it could mean that you can't access your server anymore.
Four central files control PAM's use of LDAP: common-account, common-auth, common-password and common-session. They're in /etc/pam.d. For details, see the pam(7) manpage. Edit /etc/pam.d/common-account to look like this:
account sufficient pam_ldap.so account required pam_unix.so
Edit /etc/pam.d/common-auth to look like this:
auth required pam_group.so use_first_pass auth sufficient pam_ldap.so auth required pam_unix.so nullok_secure use_first_pass
Edit /etc/pam.d/common-password to look like this:
password sufficient pam_ldap.so password required pam_unix.so nullok obscure min=4 max=8 md5
You can test if it's working using ssh (assuming nickf is a ldap user):
ssh [email protected]
PAM: Stronger Passwords (Optional)
You might be interested in libpam-cracklib (see InstallingSoftware). To activate it you'll need to edit /etc/pam.d/common-password:
password required pam_cracklib.so retry=3 minlen=6 difok=3 password sufficient pam_ldap.so use_authtok password required pam_unix.so use_authtok use_first_pass
Edit /etc/pam.d/common-session and add pam_ldap.so, like this:
session optional pam_foreground.so session sufficient pam_ldap.so session required pam_unix.so
PAM: Home directory creation (optional)
Edit the common-session file again:
session required pam_unix.so session required pam_mkhomedir.so skel=/etc/skel/ session optional pam_ldap.so session optional pam_foreground.so
You can test local groups using ssh (assuming nickf is a ldap user):
ssh [email protected]
Option: Caching Name Service directories
In order to prevent network slowdown or outage from preventing user name lookup and thus login, you can use the nss-updatedb package to create a local database of the user names, and in conjunction, use libpam-ccreds to cache credentials locally. This can be particularly useful on laptops. Please refer to PamCcredsHowto for complete instructions. Below is a script for running nss_updatedb hourly. PamCcredsHowto shows a much simpler way to run this daily, but if you want to run it every hour, then please use the code below. Create a script called nssupdate.sh in /etc/cron.hourly/ and make it executable. It should contain the following:
#!/bin/bash LOCK=/var/run/auth-update.cron [ "$1" != "0" ] && [ -f $LOCK ] && [ -d /proc/"$(cat $LOCK)" ] && exit 0 echo $$ > $LOCK RANGE=3600 [ "$1" != "" ] && RANGE=$1 SLEEP=$RANDOM [ "$RANGE" != "0" ] && let "SLEEP %= $RANGE" || SLEEP=0 sleep $SLEEP go=true while $go; do /usr/sbin/nss_updatedb ldap [ $? -eq 0 ] && go=false [ "$go" == "true" ] && sleep 10 done rm $LOCK exit 0
Notes for 7.10 and later
- There is a new tool since 7.10 to modify the pam and nsswitch files at once: AuthClientConfig.
- There is now a meta-package ldap-auth-client which will install all the following required packages for an ldap client:<
auth-client-config ldap-auth-config libnss-ldap libpam-ldap
You can use that tool like so:
sudo auth-client-config -a -p lac_ldap to reflect the changes handled on this page.* Read
more about it in this thread: http://ubuntuforums.org/showthread.php?t=597056
- If the lac_ldap option fails (as it did on my 8.10 system) the following settings were successful. These settings will also cause domain (ldap) users to become members of local groups so that local devices needing fuse, plugdev, scanner etc... membership will work properly. For example: If you are having problems with automounting of usb drives the pam_group.so option is likely your problem.
and paste the following into it:
[open_ldap] nss_passwd=passwd: files ldap nss_group=group: files ldap nss_shadow=shadow: files ldap nss_netgroup=netgroup: files ldap pam_auth=auth required pam_env.so auth sufficient pam_unix.so likeauth nullok #the following line (containing pam_group.so) must be placed before pam_ldap.so #for ldap users to be placed in local groups such as fuse, plugdev, scanner, etc ... auth required pam_group.so use_first_pass auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so pam_account=account sufficient pam_unix.so account sufficient pam_ldap.so account required pam_deny.so pam_password=password sufficient pam_unix.so nullok md5 shadow password sufficient pam_ldap.so use_first_pass password required pam_deny.so pam_session=session required pam_limits.so session required pam_mkhomedir.so skel=/etc/skel/ session required pam_unix.so session optional pam_ldap.so
Now to activate that pam profile do the following:
auth-client-config -a -p open_ldap
To assign local groups to domain (ldap) users do the following:
and add the following to the end of the file (note you can determine which groups to add to this line by logging in as a local user and using the 'groups' command):
*; *; *; Al0000-2400;audio,cdrom,floppy,plugdev,video,fuse,scanner,dip
You should now have local groups showing up for users logging in via gdm and ssh ('su username' did not give these groups on my system). Note that I did not have to edit the gdm, sshd, or login files in /etc/pam.d/ as they include a call to @include common-auth giving them the pam_group.so line in the proper order (before pam_ldap.so).
You can test local groups using ssh (assuming nickf is a ldap user):
ssh [email protected]
once you are logged in as a ldap user you can see your groups with the 'id' or 'groups' command
[email protected]:~$ id uid=10178(nickf) gid=512(Domain Admins) groups=24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),104(scanner),107(fuse),512(Domain Admins),544(Administrators),10000(Teachers)
Host based authentication allows you to restrict who can log into a machine that uses LDAP for authentication. The basic gist is you add an attribute to each LDAP user's record that includes hostnames that they are allowed to log in to. Each client system then checks this field against its own hostname and either allows or denies login based upon the attribute field. There are two methods to enforce host-based authentication, the first is to use libpam-ldap, the second method is to use an LDAP pam_filter.
Using the pam_check_host_attr directive to enforce host authentication has the effect that users are explicitly informed they are not permitted to access the host with an error message:
Access denied for this host.
Libpam-ldap requires that you use the host attribute. The package documentation includes a schema which provides this attribute, located at
/usr/share/doc/libpam-ldap/ldapns.schema, which can be added to
slapd.conf if needed. To populate that attribute, you can use a web tool such as phpldapadmin, or you can create a modification LDIF such as:
dn: uid=user_to_change,ou=Users,dc=example,dc=com changetype: modify add: host host: thehostname
"thehostname" should match the output from the
hostname command. When in doubt, check the slapd logs on the server. Make the change using:
ldapmodify -H ldaps://ldapserver -D "cn=admin,dc=example,dc=com" -x -W -f your_file.ldif
On the client side, simply modify
/etc/ldap.conf (or other appropriate configuration file as defined in pam.d) to include the line:
/etc/nsswitch.conf should *not* contain "ldap" in the "shadow" entry, or host-based authentication will always succeed. See
/usr/share/doc/libpam-ldap/ for additional information.
Using the pam_filter directive in
/etc/ldap.conf it is possible to enforce PAM to only access accounts with attributes of our choosing. Users who are not permitted access to the host will receive no error, instead PAM responds as if they have entered an incorrect password.
An example using the libpam-ldap host attribute, we can create a filter which matches thehostname or * in
Another example using Gosa's accessTo and trustModel attributes would look like the following:
- Some of the information used in this document was found on this page.
- pam(7) manpage
An alternate directory server authentication HOWTO KRB5+LDAP|Authentication