How the Online Directory Works

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.


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.


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.


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.


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.

4 thoughts on “How the Online Directory Works

  1. Jason Mittell

    Question: how do joint appointments for faculty work? I’m contractually both in FMMC and AMST, but only show up in FMMC searches. John Elder does show up in both ENVS and ENAM, but most faculty with ENVS affiliation do not show up in that department. Is this a data entry problem or a parsing issue?

  2. Ian McBride

    Out-of-the-box Banner only has a text field for “department”, so the approach has been to enter in the “primary” department for Faculty and Staff, except in some cases where people such as Brad (mentioned in my post) were grandfathered in to multiple department from the time before we checked the department field against a validated list.

    I’ve argued in this past that this is a really lame approach to the issue. Banner is a relational database, meaning that we could have a table for “departments” and a person-to-department relation table that would allow each person record to be associated with one or more departments in the database. However, this would require altering the database structure of Banner in a place that is very central to the system, which would require additional testing and support for every new release and upgrade of Banner, as well as creating new forms for every place where the person record’s department field appears, which is likely to be a lot of places when you consider what affects a department might have in a system like Banner. I don’t know this for certain, but I bet it would have effects on things like payroll, benefits, etc.

    So then the option is: well, let’s manage this outside of Banner! Ok, great. Who’s going to do that?

    I wish there was a database that told me, “here are all the people associated with this department/office/program/area,” and that this database was managed and maintained by people knowledgable about this information and that the contents of the database didn’t change if someone went on sabbatical and did change if someone were fired for cause. AFAIK we do not have a system that reflects these realities, which makes it impossible for me to create a directory interface to those results.

  3. Jason Mittell

    Here’s an idea: every registered user will have a profile in our Drupal site, which pulls from Banner data as well as allows for additional information. So can we add a checkbox list of departmental affiliations that people can choose from? That way I could add AMST to my listing, but it’s up to the individual fac/staff to self-maintain their affiliation. Would that work for the directory?

  4. Ian McBride

    Be careful what you assume here! We haven’t decided whether each person will have access to their profile in the Drupal site and/or how much information will be contained in that profile. This gets particularly tricky w/r/t information from Banner, since that information is guarded and we need sign off from each department that deals with each constituent type in order to use it – and we don’t have that sign off yet.

    Ideally though, we’d like to build a “canonical” list of groups in the Active Directory that mirrors the organization chart for the institution and includes people in each of the groups that they belong. This would be done as a shadow copy of the current group list, which is used for mailing lists. These groups would not be used for mailing, so there would not be requests to remove people who don’t want to get mail. These groups would then be the basis, along with other group lists such as those for classes, for the permissions groups in Drupal. As I said, this is our ideal solution, but making it happen will require the coordinated effort of at least three workgroups within LIS, plus the assistance of some functional groups outside of LIS, so I don’t want to make any promises for how this will turn out at this time.


Leave a Reply

Your email address will not be published. Required fields are marked *