In light of the decision to discontinue the paper directory and make the necessary improvements to the online directory so that it can supplant the paper version, I thought it would be helpful to outline from front to back how the current online directory works. This will be followed, later, with my recommendations based on your feedback and the strategic recommendations for our new website on how we can improve the directory.

Banner

The majority of the data displayed in the online directory originates in the Banner records of the students, faculty, and staff. These records are updated by the functional areas of the college responsible for maintaining contact information on these personnel: Human Resources, the Dean of Faculty, the Registrar, and their counterparts in Monterey. All these records are then periodically compiled into a set of tables that lists the people associated with Middlebury, the Language Schools, Monterey, etc.

Active Directory

Microsoft Active Directory is an application that maintains a record of all people and machines that connect to our network. When you log onto your computer in the morning, you are connecting to the Active Directory server to verify both your ser credentials and that the machine is part of the network. Many of our web applications also se Active Directory (AD) to authenticate your username and password. The AD record for each person has fields for their contact information, as well as metadata about the email and the groups to which they belong, such as All Staff, students, etc.

The AD is based on the Lightweight Directory Access Protocol (LDAP), an open framework sed by several directory platforms. Because of its ubiquity, many programming languages and applications allow access to the AD through LDAP for the purpose of authentication and directory lookups. This is the chief reason to do lookups in the AD rather than getting the information directly from Banner: the information is in a consistent form and can be accessed by nearly any application we design or purchase.

In order to get the information from Banner to the AD, a script runs periodically that syncronizes the AD with those tables mentioned in the previous section. Not all records in Banner are brought into the AD: only those of active faculty, staff and students. Many of our systems rely on this assumption for user authentication. For example, if you have an account in the AD, you can se EZProxy to access our library resources like journal subscriptions. Our license for these resources may not extend to all people for whom we have records in Banner. We may broaden the scope of records that we copy from Banner into the AD (or a parallel directory service) at some point, but doing so will require evaluating the authentication systems for all our web applications, a significant undertaking.

Each record in the AD has common fields for contact information (e.g. “mail” for your email address, “sAMAccountName” for your username) but there are some fields that we ave extended AD to introduce and some that we use in unconventional ways.

• company: Most people in the AD have their “company” listed as “Middlebury”, however this field may also include “MIIS”, “Middlebury STU”, “Middlebury LS” and some other values. It is possible for someone to have two values here. For instance, Sunder Ramaswamy’s record contains both Middlebury and MIIS, which allows him to appear in both directories.
• extensionAttribute7: Some records are not shown on the directory, either by personal choice or as determined by HR. If this field contains any value, no information about the person will be shown.
• extensionAttribute10: We currently allow all users to set the display permissions for their directory record through the Change Information Form. This attribute in the directory holds these settings as a comma separated string. For instance, my field might contain “mail=none”, which means that my email address is hidden from nobody. The logic for the values in this field dates back over a decade and isn’t entirely clear.
• extensionAttribute9: Almost every person in the directory has a photo associated with them, though many don’t show it. This attribute sets whether and how the person’s directory photo is displayed.
• extensionAttribute11: The same as extensionAttribute9, but specific to whether the person’s photo is displayed in the Faculty Class Roster, which allows faculty to see a list of students in their courses with a photo next to each name.
• MiddleburyCollege-alt-*: For each attribute in the directory, there may be a corresponding “MiddleburyCollege-alt-” attribute. These contain alternate values associated with the person’s directory record to display for other companies they might be associated with. For instance, a student who attends both the undergradate college and the Language Schools will have two different campus housing locations. The “alt” attribute for their housing location would hold the value for their LS housing, which is then shown on the directory during the summer. A similar scheme is used for people with records that show for Middlebury and MIIS.
• There are other, smaller, idiosyncracies with the AD. We store cell phone numbers in the “pager” field because the system didn’t always have a field for mobile devices. Because we maintain several addresses for people (work, home, student dorm, student mailbox), we had to extend the schema to hold the additional information.

Photos

As I said, almost everyone in the directory has a photo associated with their record, but many don’t realize this. Public Safety maintains a server that stores all of the ID card photos taken for the college. Every night, a script looks at the contents of this server and imports into a separate database any new photos. We also get a disc of professional photos taken at the new faculty orientation at Breadloaf each fall and add these manually.

Departments

A little over a year ago, the Banner team introduced data validation to the department field for employee records. This was a huge relief as it meant that we could now rely on the department field in the AD for each person, rather than a static list or groups. Relying on group membership to determine department has always been problematic because the group lists are managed by the department and will often not include, for instance, faculty on sabbatical who do not wish to receive department emails.

Once a day, a script runs through all of the records in the AD and compiles a list of the departments associated with each record. This list is then used to populate the “department” drop down field on the Middlebury and MIIS directories. This still doesn’t fully solve the problems associated with departments, since some faculty and staff need to appear in multiple department lists. Brad Nadeau, the Communications Director for Athletics, has his department listed as “Athletics/Communications”. We don’t want this department to appear in the list, so we maintain a separate manual table of dual departments. Any departments on this list are excluded from the drop down. We then maintain another list of these departments to use as a reference, so that when you search for the “Athletics” department your search will include “Athletics/Communications” as well.

Stepping through a Directory Search

Let’s say that I want to search for people named “Ian” in “Library & Information Services”. I would enter my name in the Name field and choose “Library & Information Services” from the Department drop down list. When I submit the form, the following query is built to run against the Active Directory:

(&(CN=*Ian*)(department=Library & Information Services)(company=*Middlebury*))

There are a few other fields included so that the search results don’t include computers or network routers, but they aren’t really important for this example. The *’s around my name indicate that we’re doing a wildcard search. This will return results for anyone with “Ian” anywhere in their name. In contrast, the department search will only return exact matches for Library & Information Services. Even though I didn’t include it in my search, the system tacked on the company information because I did this search in the Middlebury directory, so it assumed that I wanted to see Middlebury people, rather than MIIS personnel. The & at the beginning of the request means that all of the search criteria must be fulfilled by the records included in the response.

The Active Directory then returns a list of the records matching those criteria. The online directory then loads a list of the default display attributes for each class of records (we have different default display options for students and staff). Each record is then checked first to see if extensionAttribute7 is set (hide the record entirely) and then iterates through all the other attributes to determine what the default display setting is and to check to see if the person’s record overrides the default setting. These values are also checked against the current state of the person requesting the information, since we have different display settings for on-campus and off-campus use of the directory.

When an attribute beginning with “MiddleburyCollege-alt-” is encountered, the script checks to see what the default company of the record is, what company context the requestor is browsing in, and whether the “alt” attribute has any information to display. For instance, if I worked for Middlebury and MIIS, my company attribute might be listed as “Middlebury,MIIS”. If I maintained offices on both campuses, my extensionAttribute4 (Campus Location) attribute might be “Library 132” – my Middlebury location – and my MiddleburyCollege-alt-extensionAttribute4 attribute might be 432 Pierce St – my MIIS location. When requesting my record on the Middlebury directory, the context company is “Middlebury” so the “alt” attribute is ignored in favor of the default attribute. The reverse is true for requesting this record on the MIIS directory.

Once each attribute in each record has been check, the directory compiles a new results list containing only the information that is permissable to display on the web. This interface is exposed through a web service to allow applications other than the online directory to make use of the information, if needed. The compiled results are sent back to the directory form, which iterates through each record and prints the results.

One more request is made for each directory record. The photos for each person are stored in a database as binary data. Each time a record is printed to the screen, we make a request to this database to see if the photo can be displayed. This request takes into account the current state of the requestor (logged in, on campus, off campus) and determines if it should show the image. If the image cannot be displayed, the seal of the institution is shown in its place.

Questions?

I hope this gives you a general understanding of what goes on when you make a request to the directory and helps you understand how the results you see are compiled. My hope is that our ongoing work helps to streamline and simplify this process.