Difference between revisions of "TSLAuth"

From Department of Computer Science
 
(17 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
This document is based on information at http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentication
 
This document is based on information at http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentication
  
On saco1:
+
== Introduction ==
  
Install slapd, sasl2-bin (for saslauthd)
+
This document describes an alternative authentication configuration for the Shuttleworth Lab (TSL).
  
== Slapd Configuration ==
+
== The Problem ==
/etc/ldap/slapd.conf (slapd configuration file): Nothing special required.
 
  
To run the maximum debugging:
+
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.
  
slapd -g openldap -u openldap -f /etc/ldap/slapd.conf -d 65535
+
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.  
  
Create a user object and set the userPassword attribute to {SASL}username where username is the username on the remote LDAP system.
+
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.  
  
== SASL2 and Saslauthd Configuration ==
+
While this works, it is less than ideal for the following reasons:
/usr/lib/sasl2/slapd.conf (libsasl2 configuration file):
+
* 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
  
mech_list: plain
+
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.
pwcheck_method: saslauthd
+
 
saslauthd_path: /var/run/saslauthd/mux
+
== Solution ==
 +
 
 +
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.
 +
 
 +
This is possible using OpenLDAP with pass-through authentication as described in the rest of this document.
 +
 
 +
This solution still requires the provisioning of separate posix accounts in a TSL LDAP server. This can perhaps be automated by a daemon process which monitors the Novell E-Directory and provisions TSL accounts for any new organizationalPerson objects which appear. This service will automatically allocate uids and gids to the accounts and
 +
setup the pass-through authentication mapping.
 +
 
 +
This TSL authentication server can (should!) be a separate logical server, ideally with redundancy at least for the LDAP service.
 +
 
 +
== Details ==
 +
 
 +
=== Authentication Server Configuration ===
 +
 
 +
This section describes the configuration of a basic TSL authentication server, auth1.tsl.uct.ac.za. This configuration can be implemented on a physical server or on a virtual machine.
 +
 
 +
Currently, no attempt is made to describe redundancy.
 +
 
 +
==== Software ====
 +
 
 +
The following software is required:
 +
 
 +
* slapd
 +
* sasl2-bin (for saslauthd)
 +
* ldap-utils
 +
 
 +
==== Slapd Configuration ====
 +
 
 +
No special slapd configuration is required. Slapd hands have authentication to the sasl2 libraries in it finds a password beginning with {SASL}. It uses the bit after the {SASL} as the username and realm. In our case we will not use realms so the username.
 +
 
 +
Setup a normal LDAP domain with a base of dc=tsl,dc=uct,dc=ac,dc=za. Use GQ or phpldapadmin for simplify management.
 +
 
 +
The LDAP userPassword attribute will look like this:
 +
 
 +
userPassword: {SASL}01247611
 +
 
 +
Here is a sample of a full user:
 +
 
 +
dn: cn=Craig Balfour,ou=people,dc=tsl,dc=uct,dc=ac,dc=za
 +
objectClass: inetOrgPerson
 +
objectClass: posixAccount
 +
objectClass: top
 +
givenName: Craig
 +
sn: Balfour
 +
cn: Craig Balfour
 +
uid: craig
 +
uidNumber: 1000
 +
gidNumber: 1000
 +
homeDirectory: /home/craig
 +
loginShell: /bin/bash
 +
structuralObjectClass: inetOrgPerson
 +
userPassword: {SASL}01247611
 +
 
 +
Use the following command for debugging:
 +
 
 +
slapd -g openldap -u openldap -f /etc/ldap/slapd.conf -d 65535
 +
 
 +
==== SASL Configuration ====
 +
 
 +
This configuration includes the configuration of saslauthd and the libsasl2.
 +
 
 +
Configure /usr/lib/sasl2/slapd.conf (libsasl2 configuration file) as follows:
 +
 
 +
mech_list: plain
 +
pwcheck_method: saslauthd
 +
saslauthd_path: /var/run/saslauthd/mux
  
 
Notes:  
 
Notes:  
- When userPassword attribute begins with {SASL} slapd passes authentication over the the libsasl2 libraries.
+
* When userPassword attribute begins with {SASL} slapd passes authentication over the the libsasl2 libraries. Local only accounts with have {MD5} passwords.
- chmod a+rx /var/run/saslauthd and /etc/init.d/apparmor stop so that slapd can read the saslauthd socket
+
* Add openldap user to sasl group (and chmod a+rx /var/run/saslauthd?) and /etc/init.d/apparmor stop so that slapd can read the /var/run/saslauthd/mux socket.
- Before starting saslauthd export LDAPTLS_REQCERT=allow (needs to be added to /etc/init.d/saslauthd)
+
* Before starting saslauthd export LDAPTLS_REQCERT=allow (needs to be added to /etc/init.d/saslauthd). Might be able to add this to the global LDAP client configuration on the authentication server.
 +
 
 +
 
 +
 
 +
Configure /etc/saslauthd.conf as follows:
 +
 
 +
ldap_servers: ldaps://srvslsidm001.uct.ac.za/ ldaps://srvslsidm002.uct.ac.za/
 +
ldap_version: 3
 +
ldap_search_base: ou=users,o=uct
 +
ldap_scope: sub
 +
ldap_auth_method: bind
 +
ldap_filter: (cn=%u)
 +
tls_cert_file: /etc/saslauthd/saco1.crt
 +
tls_key_file: /etc/saslauthd/saco1.key
 +
tls_ca_file: /etc/saslauthd/cs-ca.crt
 +
tls_reqcert: allow
 +
 
 +
==== Password Changing ====
 +
 
 +
By default users are / should be created in the directory with their password set to {SASL}NDSusername to ensure that authentication is by default off the UCT Novell NDS directory. Some users may want to separate themselves from this directory and store their password in the TSL directory. This can be achieved by allowing the user to change their TSL directory password, as described below:
 +
 
 +
Configure /etc/ldap.conf.
 +
 
 +
rootbinddn cn=admin,dc=tsl,dc=uct,dc=ac,dc=za
 +
 
 +
Create the file /etc/ldap.secret and put the rootbinddn users password in it. Make sure the file is mode 0600.
 +
 
 +
 
 +
Configure /etc/pam.d/common-password by adding the following line before the pam_unix.so line.
 +
password  sufficient  pam_ldap.so
 +
 
  
- Note
+
  
/etc/saslauthd.conf:
+
==== Testing ====
  
ldap_servers: ldap://callisto.cs.uct.ac.za/
+
Test against the Novell E-Directory:
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 ==
+
ldapsearch -x -H ldaps://srvslsidm001.uct.ac.za/ -b ou=users,o=uct -D "cn=01247611,ou=users,o=uct" -W
  
 +
Test the saslauthd configuration:
  
 +
testsaslauthd -u 01247611 -p xxx
  
=== saslauthd ===
+
These the slapd pass-through authentication:
testsaslauthd -u 01247611 -p xxx
 
  
=== slapd pass-through authentication ==
+
ldapsearch -x -h auth1.tsl.uct.ac.za -b "ou=people,dc=tsl,dc=uct,dc=ac,dc=za" -D "cn=Craig Balfour,ou=people,dc=tsl,dc=uct,dc=ac,dc=za" -w xxx
ldapsearch -x -h saco1.cs.uct.ac.za -b "ou=people,dc=nodomain" -D "cn=Craig Balfour,ou=people,dc=nodomain" -w xxx
 

Latest revision as of 12:33, 28 April 2010

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 a pure LDAP one, where any complexity to managed on the authentication server and transparent to the TSL clients and file server.

This is possible using OpenLDAP with pass-through authentication as described in the rest of this document.

This solution still requires the provisioning of separate posix accounts in a TSL LDAP server. This can perhaps be automated by a daemon process which monitors the Novell E-Directory and provisions TSL accounts for any new organizationalPerson objects which appear. This service will automatically allocate uids and gids to the accounts and setup the pass-through authentication mapping.

This TSL authentication server can (should!) be a separate logical server, ideally with redundancy at least for the LDAP service.

Details

Authentication Server Configuration

This section describes the configuration of a basic TSL authentication server, auth1.tsl.uct.ac.za. This configuration can be implemented on a physical server or on a virtual machine.

Currently, no attempt is made to describe redundancy.

Software

The following software is required:

  • slapd
  • sasl2-bin (for saslauthd)
  • ldap-utils

Slapd Configuration

No special slapd configuration is required. Slapd hands have authentication to the sasl2 libraries in it finds a password beginning with {SASL}. It uses the bit after the {SASL} as the username and realm. In our case we will not use realms so the username.

Setup a normal LDAP domain with a base of dc=tsl,dc=uct,dc=ac,dc=za. Use GQ or phpldapadmin for simplify management.

The LDAP userPassword attribute will look like this:

userPassword: {SASL}01247611

Here is a sample of a full user:

dn: cn=Craig Balfour,ou=people,dc=tsl,dc=uct,dc=ac,dc=za
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
givenName: Craig
sn: Balfour
cn: Craig Balfour
uid: craig
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/craig
loginShell: /bin/bash
structuralObjectClass: inetOrgPerson
userPassword: {SASL}01247611

Use the following command for debugging:

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

SASL Configuration

This configuration includes the configuration of saslauthd and the libsasl2.

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

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. Local only accounts with have {MD5} passwords.
  • Add openldap user to sasl group (and chmod a+rx /var/run/saslauthd?) and /etc/init.d/apparmor stop so that slapd can read the /var/run/saslauthd/mux socket.
  • Before starting saslauthd export LDAPTLS_REQCERT=allow (needs to be added to /etc/init.d/saslauthd). Might be able to add this to the global LDAP client configuration on the authentication server.


Configure /etc/saslauthd.conf as follows:

ldap_servers: ldaps://srvslsidm001.uct.ac.za/ ldaps://srvslsidm002.uct.ac.za/
ldap_version: 3
ldap_search_base: ou=users,o=uct
ldap_scope: sub
ldap_auth_method: bind
ldap_filter: (cn=%u)
tls_cert_file: /etc/saslauthd/saco1.crt
tls_key_file: /etc/saslauthd/saco1.key
tls_ca_file: /etc/saslauthd/cs-ca.crt
tls_reqcert: allow

Password Changing

By default users are / should be created in the directory with their password set to {SASL}NDSusername to ensure that authentication is by default off the UCT Novell NDS directory. Some users may want to separate themselves from this directory and store their password in the TSL directory. This can be achieved by allowing the user to change their TSL directory password, as described below:

Configure /etc/ldap.conf.

rootbinddn cn=admin,dc=tsl,dc=uct,dc=ac,dc=za

Create the file /etc/ldap.secret and put the rootbinddn users password in it. Make sure the file is mode 0600.


Configure /etc/pam.d/common-password by adding the following line before the pam_unix.so line.

password   sufficient  pam_ldap.so



Testing

Test against the Novell E-Directory:

ldapsearch -x -H ldaps://srvslsidm001.uct.ac.za/ -b ou=users,o=uct -D "cn=01247611,ou=users,o=uct" -W 

Test the saslauthd configuration:

testsaslauthd -u 01247611 -p xxx

These the slapd pass-through authentication:

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