Skip to end of metadata
Go to start of metadata

This information has been contributed to ITS for sharing.



Pass-Through authentication allows a department to set up an LDAP server to perform authorization only and relies on the UH central LDAP server to perform authentication. This ensure that the department doesn't have to manage passwords and helps reduce the number of passwords a person must to memorize.


The beauty of this deployment is that it allows your department local administrative privileges by managing the users in your own directory while at the same time using the authentication and possibly also the lifecycle management from central IT, in this case, UH ITS.

Any user that is supposed to have access to local services needs to be added to your local directory, in other words, this setup will not "slurp" the central LDAP. Any service needs to be configured to bind against the local OpenLDAP deployment, NOT against the UH central LDAP, with the sole exception of saslauthd.

The example given in this document is UNIX accounts, that is, how to login to the Linux system with the UH credentials. Changing your UH password will therefore also change your local login in this scenario.

To state the obvious, usernames in the local directory need to match-up with the UH Usernames in Note that on occasion a UH Username is changed due to marriage, divorce, etc, in which case the username will also need to be changed in the local directory.


  1. Setup tested on Ubuntu 10.04 LTS Server
  2. All software from standard packages

Required software packages

Other Linux/UNIX boxes

  • YMMV (suggestions for publication here welcomed; send to


OpenLDAP Server configuration

According to your local needs, no special requirement. It needs to incorporate the "userPassword" attribute, however. For Ubuntu 10.04 LTS specific configuration instructions (which are only partially usable), see Ubuntu 10.04 Serverguide.

OpenLDAP Client configuration

LDAP Client Authentication (UNIX Account Logins example)

See also LDAP Client Authentication (Ubuntu Wiki). You know it works when $ getent passwd | grep UH_USERNAME gives you a result (assuming that this user actually also exists in your local directory!).


You need to setup your system to be able to authenticate to the UH central LDAP. This can be done by requesting a "special DN". Once you get that special DN, note that you won't immediately be able to connect, you will have to configure your TLS certificate exchange with ITS first.

You need to setup the CA cert bundle on your system by downloading it from here. You can put this file wherever you like, one "standard" place seems to be /etc/ssl/certs/ for system-wide deployments.

NB: Under Debian/Ubuntu, the file that needs to be adjusted for system-wide client changes is /etc/ldap/ldap.conf. Do not believe blog posts that claim otherwise (see also man 5 ldap.conf).

For the specific changes, see next section.

Ubuntu 10.04 specific configuration requirements

First off, the openldap user needs to be a member in the sasl group, otherwise slapd can't access saslauthd.
Under Ubuntu, the necessary configuration files that need to be created or changed are:



Obviously, it's a good idea to change permissions on this file so that no other user can read it other than the root user (saslauthd runs as root):


More Information about Pass-Through Authentication

OpenLDAP 2.4 Admin Guide, chapter 14.5 "Pass-through authentication"

Questions and Answers

What does the user see if she tries to run 'passwd' on the local system? Does it print an error message of some kind? Or does it override the passthru authentication when she enters a new password?

The OpenLDAP ACLs prevent a change of passwords. Concretely, from the command line, it looks like this:

The relevant cn=config ACL:

If a person changes their UH Password, does the local directory immediately pick-up the change, or is the old password briefly cached if they had logged-in earlier that day?

Authentication details are never cached by nscd, so the change would be immediate. I haven't tested this, though (this would be a great use case for your ldap testing environment, though).

If we deprovision a UH Username (i.e. remove the uid from the LDAP entry), does this setup correctly deny access to the local system?

If you de-provision a username (i.e., move it to a different branch of your ldap or even delete it entirely), my saslauthd will give this message:

Based on this, I can't decide whether you de-provisioned the username, or whether he simply doesn't remember his password anymore, of course; but access is denied. The user will still be able to use the system if he had been logged in at the time you've de-provisioned him (i.e. an old login session would still work until he logged out).

About This Document

  • Author: COE Technical Support staff
  • Department: UH Manoa, College of Education
  • Last Updated: Fri Sep 16 16:27:28 HST 2011
  • No labels