Middleware Implementation Case Studies

Robert Banz, UMBC

Tom Barton, University of Memphis

Dewitt Latimer, University of Tennessee

Louise Miller-Finn, Johns Hopkins University

Todd Piket, Michigan Tech University

Renee Woodten Frost, Internet2 & University of Michigan

A Seminar Sponsored by EDUCAUSE

EDUCAUSE 2001

October 27

Indianapolis

Middleware Implementation Case Studies

Agenda for the Seminar

1:00pm to 4:30pm

Introductions

Setting the Middleware Stage

Case Studies:

University of Memphis

Johns Hopkins University
BREAK 2:30pm

Mini Cases

Synchronizing iPlanet and AD- UMBC

Implementing eduPerson- Michigan Tech U

Multi-campus Directory-U of Tennessee

Network Access Services-U of Memphis

E-Provisioning-Johns Hopkins

BREAK 3:30pm

Round Table Discussions

Wrap up

Ongoing Middleware Initiatives

A Seminar Sponsored by EDUCAUSE

Synchronizing Active Directory with the Enterprise

Robert Banz, University of Maryland, Baltimore County

EDUCAUSE 2001 Seminar 5P - Middleware Implementation Case Studies

Background:

The University of Maryland, Baltimore County (UMBC) is a mid-sized university with approximately 735 full and part time faculty, and a current enrollment of just under 11,000 students.

For campus E-Mail, web services, course management tools, we are currently using MIT Kerberos 5 to manage authentication, and an LDAP directory (iPlanet Directory Server) to manage authorization. File services for our instructional, electronic mail, and web environments are provided via AFS. Our LAN environment, currently Novell 4 based, serves to provide print and file services to both campus administrative and academic environments, as well as providing print services and application file services to our instructional labs. (User file space for the instructional labs is provided through AFS).

Problem:

In late 2000, the decision was made to transition our Novell LAN environment to a Microsoft/Active Directory based environment. Our problem: To create a system to populate and maintain an Active Directory account database from data managed by our enterprise LDAP directory and account management system, leveraging our existing authentication system (MIT Kerberos 5).

Solution:

Part 1: Authentication

This was easy, Microsoft has a step-by-step guide to making this work, using cross-realm authentication.

Part 2:Active Directory

Our solution was to ‘manage’ the active directory namespace via LDAP – mirroring, for the most part, our accounts database located in our enterprise LDAP directory into Active Directory. This is a one-way operation; as changes are made to the accounts database (additions, deletions, deactivations, etc.), these are picked up by the synchronization daemon, and appropriate changes are made to the corresponding Active Directory object.

Implementing the eduPerson Object Class

Todd Piket (), Michigan Technological University

Analyst/Programmer, Distributed Computing Services

EDUCAUSE 2001 Seminar 5P - Middleware Implementation Case Studies

Problem Statement

The problem leading to the development of the eduPerson objectclass is this, as stated at

There are no established patterns for building general-purpose institutional directories. Each institution has to start from scratch, and no two higher education directories look alike.

The eduPerson objectclass is being designed to add “widely-used person attributes in higher education.” The existing inetOrgPerson objectclass was, very wisely, used as a jumping off point as it already contains many of the attributes higher education directories would wish to include.

The problem stemming from the development of eduPerson is this:

How does one go about implementing eduPerson effectively?

Pitfalls and Snares

  • Use the latest version
  • What attributes to populate?
  • What to populate attributes with?

Benefits

  • Standards Conformance
  • Reduce Data Redundancy
  • Application Integration (possibly across institutions)

Miscellaneous

For more information on the eduPerson objectclass please see the following URL:

Authorizing Network Access Services

Dr. Tom Barton, The University of Memphis

EDUCAUSE 2001 Seminar 5P - Middleware Implementation Case Studies

The Problem. Off the shelf RADIUS servers could provide LDAP-based authentication service to dialups and wireless access points, but support for a finer grained access control policy was needed.

Background. Phased out ancient custom Ph-based authentication and authorization system for UoM’s three virtual modem pools – All UoM People, Faculty/Staff Only, and Private – and needed to reproduce that functionality with RADIUS backed by LDAP. Furthermore, different session characteristics apply (especially time-dependent session length limits for All UoM People). New deployment of Avaya AS2000 Wireless Access Servers, which implement per-session user login and encryption keys, also needed an enterprise access control framework to meet client requirements.

Approach. We wanted a RADIUS server implementation supporting scripted LDAP queries so that contents of RADIUS response packets could be dependent on the results of a variant sequence of LDAP queries. That would allow us to create and maintain special objects in LDAP that express access control policies for different NASes.

Solution elements. Funk Software’s SteelBelted RADIUS server; UoM’s schema extensions (especially UofMNAS objectclass); LDAP config script for SteelBelted.

  1. UofMNAS required attributes:

cnName of this UofMNAS object.

nasAccessTypeOne of “open”, “closed”, “userFiltered”, “groupFiltered”. An open NAS service admits all authenticated users. One that’s closed admits nobody. User and group filtered types rely on LDAP search filters to express access control policy – either in terms of attributes in authenticated user’s object or in terms of group memberships.

nasNameList of strings identifying this NAS service, typically names

of NASes providing this NAS service. Used by RADIUS server to find the UofMNAS object that applies to a given session initiation request.

nasProfileName of RADIUS server-based profile to apply to authorized sessions.

  1. UofMNAS allowed attribute:

nasAdmitFilterArbitrary LDAP search filter to be inserted into LDAP URL by the RADIUS server to determine if authenticated user is permitted access to this NAS service. If nasAccessType is “userFiltered”, LDAP URL is scoped to the DN of the authenticated user. If it’s “groupFiltered”, search scope is entire LDAP directory, but restricted to groupOfUniqueNames objects.

  1. Attribute added to uMemphisPerson objectclass:

radiusDeny“all” or list of nasNames for which to deny access.

  1. Use of RADIUS request packet fields.

Each NAS server sends its name in each RADIUS request packet in the “NameOfNAS” field. It is bound to a UofMNAS object expressing its access control policy by having that name listed among the values of the nasName attribute. Dialup NASes are further identified by using the “theNumberCalled” field from the RADIUS request packet. It is appended to NameOfNAS, after a hyphen. So, a virtual modem pool is identified as “NameOfNAS-theNumberCalled”, i.e., that string appears in the nasName attribute of the UofMNAS object expressing.

  1. LDAP config script for SteelBelted entails variant sequence of six LDAP query steps, summarized as follows.

Step 1 – Basic authentication. Search for object with uid=UserName, but also require object to either be “active status” or a “guest” at UoM, and ensure that the object’s radiusDeny attribute doesn’t prohibit access to the NAS service being accessed.

Step 2 – Handle open NASes. If nasAccessType is open, finish authentication process.

Step 3 – Setup for userFiltered access type. Obtain nasAdmitFilter for NAS object if nasAccessType is userFiltered.

Step 4 - Apply user related access filter. Apply nasAdmitFilter to user object to see if user meets access control policy. Reject if not, finish authentication process if so.

Step 5 – Setup for groupFiltered access type. Obtain nasAdmitFilter for NAS object if nasAccessType is groupFiltered.

Step 6 – Apply group related access filter. Apply nasAdmitFilter, augmented with an “AND objectclass=groupOfUniqueNames” clause, to entire LDAP directory to see if user meets access control policy. Reject if not, finish authentication process if so.

Examples of Use.

  1. All UoM People modem pool. Open to all active UoM people and official guests.

nasName: {gelion-6783600, sirion-6783600}

nasAccessType: open

  1. Faculty/Staff modem pool. Open only to faculty and staff, which status is automatically maintained in people objects’ “ou” attribute.

nasName: {gelion-6784600, sirion-6784600}

nasAccessType: userFiltered

nasAdmitFilter: ou=Faculty/Staff

  1. Typical residence hall wireless access, for which the default policy is that only residents may access.

nasName: {WS109-A1;WSLBY-A1;WS127-A1;WS207-A1;WS221-A1;

WS231-A1;WS309-A1;WS323-A1;WS337-A1}

nasAccessType: groupFiltered

nasAdmitFilter: (|(cn=West Hall Residents)(cn=Network Services))

E-Provisioning

Louise Miller-Finn, Johns Hopkins University

EDUCAUSE 2001 Seminar 5P - Middleware Implementation Case Studies

The Problem: Each fall, over the Labor Day weekend, 1500 students and faculty converge on campus, all wanting their email accounts to be available immediately. For staff this was a nightmare because it was the last long weekend of the summer and this process meant long lines at the Business Office.

The Challenge:

  • Use the enterprise directory to facilitate this process electronically, so that no one would need to setup a single account manually or wait in line to get an account.
  • Reduce the number of staff involved in the process
  • Accommodate the new online Policy Test

The Solution:

  • All accepted students were loaded into the directory over the summer
  • In the student mailing sent in August, instructions were included directing incoming students to the Hopkins enterprise directory (JHED) to find their Hopkins login ID and setup their password, secret question/answer pair. Once this was completed, the student was directed to a JHED portal page that offered the Online Policy Test. Once the test was completed, the account request links became live on the portal.
  • Email account setup was completed by clicking on the Email hotlink, which in the background created the iMS object class for the person in the directory, creating the account just in time.
  • Unix accounts were setup via a Cold Fusion request form that cron’d the new login id/password addition to the appropriate Unix hosts.
  • Access to a new webmail system was restricted to student class code: freshman

In Retrospect:

  • Upper classmen were not familiar with the process and tried to sabotage its success.
  • When a freshman was advanced to a higher class code, their e-mail account access was restricted, causing a code enhancement.