Table of Contents
LDAP/Openldap
Overview
OpenLDAP provides a place to store central user accounts and other configuration information which multiple machines can read. The advantages are that all machines on the network have a consistent view of user accounts, UIDs, passwords etc, and they are very easy to maintain.
LDAP can also store configuration for sudo, as well as Samba configuration and postfix mail routing.
This guide walks through setting up the LDAP services used at sihnon.net, which includes one master LDAP server (ldap.sihnon.net) and one slave (ldap-slave.sihnon.net).
Installation
Emerge the following packages under Gentoo:
Configuration
Server
The Server will also most likely act as a client as well, so follow the steps below as well.
The configuration for the LDAP master is stored in subversion, under configs:/ldap/master/.
Slapd
Additional Schemas
We will be using two additional schemas for openldap to allow for storing ssh public keys and postfix mail delivery information in the directory.
/etc/openldap/schema/postfix.schema|<code>0@@</code>
Base LDIF
Once the directory is set up, we need to create our basic hierarchy: base.ldif|<code>3@@</code>
Import the base hierarchy, check the permissions of the database directory, fixing if necessary, and finally start the directory server up. <source lang="bash"> cat base.ldif | slapadd ls -l /var/lib/openldap-data/ chown -R ldap:ldap /var/lib/openldap-data/ /etc/init.d/slapd start rc-update add slapd default </source>
Clients
The configuration for LDAP client machines is stored in subversion, under configs:/ldap/client/.
NSS LDAP
PAM LDAP
/etc/ldap.conf|<code>6@@</code>
Put the password for the account specified by rootdn in /etc/ldap.secret
Replication
This section uses information taken from http://times.usefulinc.com/2008/06/20-secure-ldap.
The configuration for the LDAP slave is stored in subversion, under configs:/ldap/slave/.
Master
To enable replication, you will need a user for the slave to bind as which has full access to read the entire directory. Create this user, then add the following to the end of the slapd configuration utility.
Slave
The slapd configuration file should be set exactly the same as for the server, and then just add the following to the end of the file to enable replication. The end result is that the slave runs a read-only copy of the directory; if a user attempts to modify it, he is given a referral to the master. The master server pushes updates to all the slaves ensuring they are always up to date. The slaves are able to recover a full copy of the directory from any starting state.
Cached Credentials
The setup described above requires a permanent connection to an LDAP server, else noone will be able to log in. On a local network, you can get around this with redundant LDAP servers, but for a laptop which leaves the network the problem is critical. Fortunately, pam_ccreds is designed to solve the problem. The required packages are only available in the Swegener overlay at the moment, so add it with:
<source lang="bash"> layman -a swegener </source>
Then install the following packages:
Add the following to configuration to make nss revert to the cached credentials if there's no connection to the directory service. /etc/nsswitch.conf|<code conf> passwd: compat ldap [[NOTFOUND=return]] db shadow: compat ldap [[NOTFOUND=return]] db </code>
Configure pam to update the cache on successful logins, and accept cached credentials when no server is available. /etc/pam.d/system-auth|<code pamconf> auth required pam_env.so auth [[success=ignore|default=1]] pam_localuser.so auth [[success=done|new_authtok_reqd=done default=die]] pam_unix.so likeauth nullok shadow auth [[authinfo_unavail=1|success=ignore default=2]] pam_ldap.so auth [[default=done]] pam_ccreds.so action=store use_first_pass auth [[success=done|default=die]] pam_ccreds.so action=validate use_first_pass auth [[default=ignore]] pam_echo.so Delete cached password auth [[default=bad]] pam_ccreds.so action=update auth required pam_deny.so account [[authinfo_unavail=ignore|user_unknown=ignore default=done]] pam_unix.so account sufficient pam_localuser.so account [[success=ignore|default=1]] pam_succeed_if.so uid > 10000 account [[authinfo_unavail=ignore|default=done]] pam_ldap.so account sufficient pam_permit.so </code>
Log in once, and your credentials should be cached. You can check with the following command <source lang="bash"> cc_dump </source>
If all is well, drop the network connection, and try logging in again. You should see a message along the lines of “Logged in using cached credentials”, and be presented with a login shell.
Finally, add a cronjob to keep the cached credentials up to date. /etc/cron.daily/nss_updatedb|<source lang="bash"> #!/bin/sh /usr/sbin/nss_updatedb ldap </source>
Troubleshooting
I have no name!
Check the following
- Make sure that
/etc/ldap.secretexists with suitable permissions (0600), and contains the correct password for the the LDAP root account (cn=root,dc=sihnon,dc=net). - Make sure that
/etc/ldap.confis world readable. - Make sure that the CA certificate file is world readable.
Getent passwd returns no LDAP accounts
If root can run getent passwd ok, but a mortal user cannot, check the following:
- Check that the SSL CA certificates are world-readable
- Try raising the debug level for
slapdonldap.sihnon.netwithloglevel stats
Sudo refuses to search LDAP
Sudo 1.7.0 now uses nsswitch.conf to tell it where to look for configuration, which is a change over 1.6.9 and earlier. Be sure to configure nsswitch as documented above to tell sudo to read the LDAP configuration
See also
