Difference between revisions of "TSLAuth"

From Department of Computer Science
Line 7: Line 7:
 
== The Problem ==
 
== The Problem ==
  
TSL currently uses an ugly configuration which consists of a combination of NIS/YP domain for Posix account information, and LDAP authentication for the UCT Novell NDS. Ideally we would like to just use the NDS but its users do not contain the unix posix account attributes and numerous requests over years to extend the schema to support these have got nowhere.  
+
TSL is a UCT computing facility available to all UCT staff and students. All staff and students are issued with a UCT username and password which they expect to be able to use to access all computing facilities on campus, including TSL. To reduce the administrative load involved in creating accounts and managing passwords it makes sense for TSL to make use of this username and password, rather than provisioning separate authentication credentials.
  
Additionally, NIS/YP is insecure and does not support useful stuff like account aging and expiration.  
+
The UCT credentials are provided through the Novell E-Directory infrastructure and available for use through an LDAP API. Unfortunately, these accounts do not have the unix posix account attributes and therefore cannot be used on their own in a unix environment. Various attempts have been made over the last few years to get ICTS to extend the schema to support the posix account attributes but to no avail.
 +
 
 +
As a result, TSL uses a hybrid client configuration which uses the UCT credentials for authentication and a YP/NIS domain for the rest of the account information.
 +
 
 +
While this works, it is less than ideal for the following reasons:
 +
- This complex client-side configuration needs to be implemented on every workstation
 +
- YP/NIS is ugly and insecure  
 +
- YP/NIS does not support password aging, account expiry, etc.
 +
- Account creation / management is cumbersome and contributes to the instability of the TSL server
 +
 
 +
The ideal solution is a pure LDAP one, where any complexity to managed on the authentication server and transparent to the TSL clients and file server.
  
 
== Solution ==  
 
== Solution ==  

Revision as of 16:02, 22 December 2009

This document is based on information at http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentication

Introduction

This document describes an alternative authentication configuration for the Shuttleworth Lab (TSL).

The Problem

TSL is a UCT computing facility available to all UCT staff and students. All staff and students are issued with a UCT username and password which they expect to be able to use to access all computing facilities on campus, including TSL. To reduce the administrative load involved in creating accounts and managing passwords it makes sense for TSL to make use of this username and password, rather than provisioning separate authentication credentials.

The UCT credentials are provided through the Novell E-Directory infrastructure and available for use through an LDAP API. Unfortunately, these accounts do not have the unix posix account attributes and therefore cannot be used on their own in a unix environment. Various attempts have been made over the last few years to get ICTS to extend the schema to support the posix account attributes but to no avail.

As a result, TSL uses a hybrid client configuration which uses the UCT credentials for authentication and a YP/NIS domain for the rest of the account information.

While this works, it is less than ideal for the following reasons: - This complex client-side configuration needs to be implemented on every workstation - YP/NIS is ugly and insecure - YP/NIS does not support password aging, account expiry, etc. - Account creation / management is cumbersome and contributes to the instability of the TSL server

The ideal solution is a pure LDAP one, where any complexity to managed on the authentication server and transparent to the TSL clients and file server.

Solution

The ideal solution is to move to a pure LDAP configuration. This is possible using OpenLDAP with pass-through authentication.

I like this solution because all of the work is done on the authentication server keeping the client configuration simpler.

Details

On saco1:

Install slapd, sasl2-bin (for saslauthd)

Slapd Configuration

/etc/ldap/slapd.conf (slapd configuration file): Nothing special required.

To run the maximum debugging:

slapd -g openldap -u openldap -f /etc/ldap/slapd.conf -d 65535

Create a user object and set the userPassword attribute to {SASL}username where username is the username on the remote LDAP system.

SASL2 and Saslauthd Configuration

/usr/lib/sasl2/slapd.conf (libsasl2 configuration file):

mech_list: plain pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux

Notes: - When userPassword attribute begins with {SASL} slapd passes authentication over the the libsasl2 libraries. - chmod a+rx /var/run/saslauthd and /etc/init.d/apparmor stop so that slapd can read the saslauthd socket - Before starting saslauthd export LDAPTLS_REQCERT=allow (needs to be added to /etc/init.d/saslauthd)

- Note

/etc/saslauthd.conf:

ldap_servers: ldap://callisto.cs.uct.ac.za/ ldap_version: 3 ldap_search_base: ou=people,dc=cs,dc=uct,dc=ac,dc=za ldap_scope: sub ldap_auth_method: bind ldap_filter: (uid=%u)

Testing

saslauthd

testsaslauthd -u 01247611 -p xxx

= slapd pass-through authentication

ldapsearch -x -h saco1.cs.uct.ac.za -b "ou=people,dc=nodomain" -D "cn=Craig Balfour,ou=people,dc=nodomain" -w xxx