Implement Passthrough Authentication from a Departmental LDAP Server to UH LDAP Servers

Owned by mhodges
Last updated: Jul 16, 2014 by Julio Polo
4 min read

This information has been contributed to ITS for sharing.

 

Overview

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.

Motivation

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 ldap.hawaii.edu. 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.

Prerequisites

  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 its-iam-help@lists.hawaii.edu)

Configuration

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)

$ sudo apt-get install ldap-auth-client nscd libpam-ldapd
$ sudo auth-client-config -t nss -p lac_ldap

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!).

For ITS LDAP

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 mozilla.org 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:

 o  /etc/ldap/ldap.conf
 o  /etc/saslauthd.conf
 o  /usr/lib/sasl2/slapd.conf

/etc/ldap/ldap.conf

TLS_REQCERT /etc/ssl/certs/cacert.pem

/etc/saslauthd.conf

# saslauthd.conf
# for pass through authentication with ITS LDAP

# connection information
ldap_servers: ldaps://ldap.hawaii.edu
ldap_version: 3

# we're using SSL
ldap_start_tls: no

# where are we looking
ldap_search_base: ou=people,dc=hawaii,dc=edu
ldap_filter: (uid=%u)

# bind to the ldap server
ldap_bind_dn: cn=YOUR_SPECIAL_DN_USERNAME,ou=Specials,dc=hawaii,dc=edu
ldap_bind_pw: YOUR_SPECIAL_DN_PASSWORD

# for testing purposes (watch syslog)
#ldap_verbose: on

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):

$ chown root: /etc/saslauthd.conf
$ chmod 600 /etc/saslauthd.conf

/usr/lib/sasl2/slapd.conf

pwcheck_method: saslauthd

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:

$ passwd
(current) LDAP Password: xxxxxxxx
New password: yyyyyyy
Retype new password: yyyyyyy
Server is unwilling to perform
passwd: Authentication token manipulation error
passwd: password unchanged

The relevant cn=config ACL:

olcAccess: {0}to attrs=userPassword
       by dn="cn=admin,dc=coe,dc=hawaii,dc=edu" write
       by anonymous auth
       by self none
       by * none

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:

$ sudo testsaslauthd -u blah -p xyz
0: NO "authentication failed"

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
$ sudo apt-get install slapd ldap-utils sasl2-bin