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).
Emerge the following packages under Gentoo:
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/.
We will be using two additional schemas for openldap to allow for storing ssh public keys and postfix mail delivery information in the directory.
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>
The configuration for LDAP client machines is stored in subversion, under configs:/ldap/client/.
Put the password for the account specified by rootdn in
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/.
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.
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.
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:
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>
Check the following
/etc/ldap.secretexists with suitable permissions (0600), and contains the correct password for the the LDAP root account (
/etc/ldap.confis world readable.
If root can run
getent passwd ok, but a mortal user cannot, check the following:
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