Replacement of Setpw and Custom Login with Vendor software using Kerberos and LDAP

Project Overview

The goal of this project is to eliminate our dependence on a custom login program and the setpw package in favour of the "vendor" login and the use of common protocols that are well known and understood. The common protocols in this case are Kerberos 5 and LDAP. The end result would pave the way for unification of Unix and Active Directory authentication and authorization.

Motivation

Problems and limitations with our use of setpw and custom login include the following:

• Users often get the error "Password file is busy" when attempting to change their password. This is frequent at the beginning of term, when lots of students are resetting their passwords from the initial password.
• Users can only change their passwords on certain Unix hosts, even when not using the Unix environment
• It takes time for passwords to synchronize on all machines (syncronization is run via cron).
• Password synchronization is insecure (uses rsh) and does not occur if a computer happens to be down.
• Introduction of a new Operating System (version) requires development work.
• The custom login does not support PAM, making it inflexible.
• The xhier regional master is the single point of failure with respect to password management.

The Kerberos and LDAP protocols are supported by all of the of the operating systems that we support. Both Active Directory and OpenLDAP support replication for high availability and are much better at handling multiple updates.

Project Members

• Adrian Pepper [CSCF - Infrastructure Support]
• Clayton Tucker [CSCF - Infrastructure Support]
• Jason Testart [CSCF - User Support]
• Ray Butterworth [MFCF]

Other subject matter experts may be brought in as needed.

Project Stakeholders

While both CSCF and MFCF are the obvious stakeholders, we can specify sub-groups (reps) not directly involved in the project:

• CSCF Research Support - often need to provision accounts on non-standard platforms (Mike Patterson)
• CSCF Administrative Support (Jennifer Keir)
• MFCF Help Centre (Lori Suess)
• MFCF (Tom's group) - Looking at better integration in the creation of an Active Directory (Hong Zheng)

Assumptions and Risks

• Differences in architecture between CSCF's AD and MFCF's AD should not impact this project's deliverables.
• At this stage, care should be taken to minimize the number of changes to the accounts software.
• Results from project should allow CSCF and MFCF to easily leverage the capabilities of the campus Identity Management system.

Technical Notes

Proposed New Architecture (CS teaching environment)

Technologies Involved

• Network Appliance file server
• Solaris hosts (login, mail, web, etc...)
• Mac OS X clients (in public labs)
• Linux clients (in public labs)
• Windows Terminal Server
• Windows XP clients (in public labs)
• Printers

The Glue to hold things together

• PAM
  • pam_krb5 - for authentication
  • nss_ldap - for looking-up passwd/group/hosts info in an LDAP database, rather than local files.
• LDAP
  • OpenLDAP? Active Directory?
• NFSv3
• Kerberos/GSSAPI/SASL
  • CUPS
  • SSH
  • DB2
  • Sendmail

Authentication

The use of the pam_krb5 module is quite well documented. Work has already been done to integrate our Linux/Solaris hosts into Active Directory. Service Principals have been created in AD for many of the Solaris hosts in the teaching environment, providing SSH Single Sign-on to students using the Mac Labs.

Name Service

Name Services include things like user home directory and shell, as well as group membership information. Name service for Linux can be provided via the nss_ldap PAM module. The diagram above shows using OpenLDAP for name services, while using Active Directory for authentication. This architecture is flexible as it separates the authentication source from the source used for name services. The downside is that you would need to ensure that a user exists in both Active Directory and the OpenLDAP, which is more work. The alternative is to use Active Directory for name services, which implies extending the Active Directory schema to allow for passwd/shadow/group database information. Since these schema extensions are static and straight forward, using AD is likely not a big deal. However, if we intend to make use of LDAP for more, such as Unix printing, netgroup functionality, we may elect to consider OpenLDAP to provide name services. Further research and evaluation is required.

File Service

While NFS would be ideal to use because of its simplicity, it should only be used in public labs where Kerberos authentication is supported. NetApp, Linux, and Solaris 9+ all support Kerberized NFS. We currently use samba in our Mac Labs, because that's a supported mode for the AD plugin in OS X. We understand the Kerberized-NFS will be supported in a later release of OS X (Leopard?).

Resources

• LDAP Systems Administration - an O'Reilly book by Gerald Carter
• Kerberos The Definitive Guide - an O'Reilly book by Jason Garman
• http://www.netapp.com/library/tr/3457.pdf - Excellent resource by NetApp
• http://www.netapp.com/library/tr/3458.pdf - Excellent resource by NetApp
• http://www.openldap.org/doc/admin22/sasl.html - describes how to use OpenLDAP with AD (ie. Krb5) as the authentication source
• HOWTO fit Linux into Active Directory, while Gentoo specific, looks like a good document (focus on LDAP, not Winbind).
• http://enterprise.linux.com/enterprise/04/12/09/2318244.shtml?tid=102&tid=101&tid=100 - neat info, but comments on the bottom suggest AD as a main LDAP service is a bad idea

-- JasonTestart - 22 Mar 2007