Share this Page

Focus

Privacy Drives Directory Work at Northwestern

By Dian Schaffhauser
09/20/07

Even though FERPA, the Family Educational Rights and Privacy Act, was signed into law in 1974, campuses continue struggling with how to control the distribution of information on students in ways that comply with the federal regulations. At Northwestern University in Evanston, IL, with about 14,000 students, that challenge has included how to get its multiple directories coordinated in a way that would prevent a "mistaken" network administrator from inadvertently releasing student data that should have remained private. At the end of this month Northwestern's Director of IS Architecture, Tom Board, hopes to see the completion of a two-year project that will finally address that concern.

In the mid-'90s the campus developed an LDAP-based identity management program that takes information from two "authoritative" sources, the HR and student record systems, and uses that to create, maintain, and retire identities used by the e-mail, VPN, and most other administrative systems of the university.

Forests and the Trees
When Microsoft first introduced Active Directory in Windows 2000, said Board, individual schools within Northwestern, as well as divisions such as Student Affairs and the Office of Alumni Relations and Development, set up their own forests ... "for productivity purposes." Eventually, the count reached 18. But none of those forest owners wanted to tackle the job of deciding who should or shouldn't reside in the individual directories.

"I would have loved to have gotten away with having only a central AD forest and none of these other forest instances," said Board. "But the businesses of each portion of the university are sufficiently different and the problems and capabilities they're trying to solve or highlight different enough that separate forests end up being the best solution."

So Board's group developed a central AD forest that mirrored the information in the LDAP directory for those instances when somebody needed to know everyone in the institution. The team also wrote software that used a Windows NT API to manage the addition and removal of users into and out of the forests. "The identity system talked to LDAP, the central AD forest, and the 18 AD forests as separate targets," said Board.

Two problems surfaced. First, the NT 4.0 API was eventually deprecated by Microsoft, which meant its future was doubtful. Second, the home-grown code that used the API was limited in its capabilities. "It was never capable of transferring more than a name and password and some fairly fragile group information," Board said. That meant the individual schools and divisions (and even potential enterprise-wide applications like Exchange and SharePoint) couldn't access other vital information about the student.

Building a New Solution
To address the limitations, the school put out an RFI to find third-party solutions that could replace the NT API. On the shortlist were Microsoft Identity Integration Server, OctetString (acquired by Oracle in 2005), and Radiant Logic RadiantOne. The cost and scope of the Microsoft solution eliminated it from final consideration. And after a close examination of the two remaining choices, Board said, RadiantOne came out on top based on its internal business rule construction interface. "We felt that RadiantLogic's programming interface and fundamentally Java-based interfaces for code that we would have to write centrally was more amenable to our skill set, and we felt it could be better supported going forward than an OctetString."

Board said he estimates that the university has invested about $100,000 in the software's licensing and maintenance fees. Deploying it on the central forest, as a Windows 2003 instance, took about two months of committed staff time, stretched across 12 calendar months. Part of that, he said, "was making sure we had various rules in place debugged and special cases taken care of."

Then the challenge became bringing those other forests into the operation. "This is no small feat," Board said. "It took us the better part of a year to come to a consensus in the university about how AD was going to be managed--whether we were going to get rid of those 18 forests and everybody was going to be part of one central forest or whether there was going to be inter-forest trust relationships."

When the decision was made to retain the forests, the two-year project to move the 18 directories began. Here the tricky parts of the projects were twofold: getting that school or division to make the decision about whether to buy new hardware and get the software installed, said Board, and getting schema definitions synchronized between RadiantOne and each individual forest.

Also, the administrators at the individual forests needed training, if appropriate, in how to create manual identities in situations, for example, where a visitor to the campus community wanted access to the network. That also involved implementing software rules as part of the RadiantOne filter feature.

But once those issues are nailed down, said Board, "building the actual solution and scheduling time to flip the switch is less trying."

The new approach has the identity system talking to LDAP as its only target, and then RadiantOne takes the LDAP changes and processes them out to the appropriate AD forests.

Next up for Board's team regarding its work with RadiantOne: bringing up a second instance for disaster recovery purposes and virtualizing the servers rather than having "iron" dedicated to the software.

Board advises his peers in other schools to be moving to a system that maintains a single identity for each member of the community. "Based on complexity of the institution and its size, that may require multiple directory services of one sort or another," he said. "Keeping those services in step, one with another, is non-trivial. But software like RadiantOne makes it more digestible. It becomes a more manageable, sort of an isolatable function within the network, rather than having it combined with some parts of your identity management structure."

Read More: