User Tools

Site Tools




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, which includes one master LDAP server ( and one slave (




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/.


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.





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 /etc/ldap.secret




This section uses information taken from

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.


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 auth [[success=ignore|default=1]] auth [[success=done|new_authtok_reqd=done default=die]] likeauth nullok shadow auth [[authinfo_unavail=1|success=ignore default=2]] auth [[default=done]] action=store use_first_pass auth [[success=done|default=die]] action=validate use_first_pass auth [[default=ignore]] Delete cached password auth [[default=bad]] action=update auth required account [[authinfo_unavail=ignore|user_unknown=ignore default=done]] account sufficient account [[success=ignore|default=1]] uid > 10000 account [[authinfo_unavail=ignore|default=done]] account sufficient </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>


I have no name!

Check the following

  • Make sure that /etc/ldap.secret exists 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.conf is 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 slapd on with loglevel 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

ldap_openldap.txt · Last modified: 2014/11/24 02:20 by ben