Notes from the Directory Services Summit at Big Ten Conference Center September 28, 1999

Kevin Coffman, September 28, 1999

Standard Disclaimer:

Some of this may be my interpretation or misunderstanding and may differ from reality. My editorial comments are bracketed with square brackets [like this ].

Special Note: The CIC has set up a web page to document the outcome of this Summit and to provide a location for sharing information. The information here should be deemed more accurate than the following notes I took during the meeting.

There is also a Majordomo mailing list (cic-dirsvcs@cic.net) to share information.

Partial list of Attendees. (See the CIC page referenced above for the complete list.)
Phil Tracy Northwestern University
Scott Cantor The Ohio State University
Mike Belinc Penn State University
Renee Shuey Penn State University
Bob O'Connor Penn State University
Bruce Alexander Michigan State University
Kevin Coffman University of Michigan
Mike LaHaye University of Michigan
Feather Lacy University of Iowa
Ed Kroll University of Illinois at Urbana/Champaign
Dorothy Raden University of Chicago
Kim Buzan University of Wisconsin
Bob Goldstein University of Illinois at Chicago
Frank Grewe University of Minnesota
Steve Kellogg Penn State University

September 28, 1999

Introduction and welcome from David Dobbins -- University of Iowa

Status summary from each school

George Yates -- NWU

Northwestern is currently using a legacy PH directory service. PH does not have broad client support, so they are looking at LDAP now. They have been looking at both Umich LDAP and OpenLDAP because of PH legacy things. George claims that he would have a big problem trying to use a pre-built product like Netscape's because of the way that PH does lookups. He claims that the nickname matching of PH is difficult to duplicate using LDAP. George has customized the search code on the server to return results similar to those returned by PH. George feels that directories should be approached like financial systems, where you cannot just use an off-the-shelf product, but must customize it for local preferences.

Ed Kroll -- University of Illinois at Urbana (Mike Grady)

They are looking at LDAP to be used more as an authentication service rather than a phone book. Issues with Netscape pricing were brought up. (Charging on the basis of the number of entries in the database.) Ed notes that OpenLDAP is behind the times. Another issue noted was that different lookup clients (netscape, outlook express) use different wildcarding. They are looking at LDAP as a tool to be used for PKI enablement.

Scott Cantor -- OSU

Ohio State uses whois, PH, etc. Historical reasons brought the need for a new service. They are looking at a tactical solution for E-mail, phonebook, etc. They were looking at Netscape, but cost caused them to move to OpenLDAP. The lack of attention and non-development of OpenLDAP was noted. However, the group that is actually bringing up the service is not expected to care because they are trying to solve a specific problem. [Sounds familiar.] Scott believes there will be several directories developed to solve various problems at OSU. XML was listed as a possible solution to movement of data between various LDAP-enabled databases.

Bob Goldstein -- University of Illinois - Chicago

The University of Illinois - Chicago uses PH in a read-only fashion. Eudora and Pine are the blessed e-mail clients. They currently don't really support or care about Netscape or Outlook Express. Their anticipated use for LDAP is to support PKI and authorization data.

Mike LaHaye -- University of Michigan

Mike explained our tactical replacement of current QUIPU X.500 directory with OpenLDAP for mail delivery.

Dorothy Raden -- University of Chicago

UIC is developing a Sybase-based database, which will be the data warehouse, with information on individuals. They have decided that Netscape should be their directory server, but are having trouble contacting them. [A somewhat common theme here.] They have had trouble getting all the information they need such as middle names, SSNs, etc. They have created a "link-id" which is a common unique identifier for each individual that is used to link information about that information through all their databases. [This sounds similar to our entityID.] They have 8-9 other databases that they'd like to get information from. Synchronization of all these databases was an issue.

?? -- Michigan State

MSU is looking at LDAP as a central store for authorization, PKI, and directory. They currently use CSO (?) and finger as phonebook and do updates nightly. They are not using LDAP in production yet. One problem was noted: Who selects the title that is displayed for a person?

Chris Pruess -- Iowa

Currently at Iowa, a DB2 database is the authoritative source for address and phone number. They do a nightly update of their PH database. Iowa is looking to create a standards-based, directory service. They have chosen a meta-directory solution from Isocor. Iowa is currently working on a pilot with Isocor. Each application has it's own rules for data lookup. They are currently trying to centralize or standardize on what the lookups from each application should look like.

Frank Grewe -- University of Minnesota

Minnesota has been running an X.500 server for about 7 years. They are using finger, PH, and LDAP protocols. Frank has coined the term "Registry" to refer to the collection of authoritative data that is used to populate the directory. Any changes in the directory are immediately reflected in the "Registry". Frank feels that directories are not databases, and they shouldn't be the authoritative source of the data. Politics become a problem: who owns the data? Different units on campus (PeopleSoft, alumni association, etc.) feel that they have a complete list of people, things, etc. that should be in the database, but none really has the complete list. The "Registry" is a superset of all these things. Things are put into the "Registry" and pushed back down to the local directories. Minnesota has a policy of yearly expiration and renewal of entries. Anyone that has at least one "entitlement" with the university gets an entry in the directory. The "Registry" has many more people in it than the directory. Worst-case propagation from "Registry" to the directory is 10 minutes. Their basic schema is based on inetOrgPerson, with local additions added to each entry as appropriate.

Mark Bruhn - Indiana

Indiana currently uses PH, whois, and web-based access for phone directory, etc. They have 20-25 different data sources and perform nightly updates. They maintain a distributed accounts management system, which keeps track of which machines a user has accounts on. They are in the process of creating flat unique university namespace across all campuses. They currently populate an exchange address book, but that is all the LDAP they currently do.

Steve Kellogg -- Penn State University

DCE infrastructure is a key component at Penn State. LDAP is a gateway for service advertisement. Group authorization is maintained via DCE groups. They also do straight Kerberos5 authentication against their SECD. They investigated several different LDAP options (OpenLDAP, Isocor, Netscape, etc.), but have settled on IBM's directory service, which is free with the purchase of an instance of an IBM operating system. DB2, which is used at the back-end database for their LDAP server is also free as long as it is used only for the directory service. If you decide to use DB2 as a "real" database, you must license DB2 separately. Steve views group authorization as a really big thing. They are currently still using PH as a directory service, since their LDAP service is not yet in production.

Tom Jordan - University of Wisconsin

Wisconsin currently uses PH for directory. They are getting pressures and inquiries about LDAP. Data sources include person data, person data for students, special authorization. They anticipate an Oracle view pulled from many data sources to be presented to the directory server as a single view of the data.

Some common issues brought up by the schools in their summaries:

Synchronization (people, Ids)

X.500 Communication (inter-campus)

Data Sources / Feeds

Selecting Open Source vs. Commercial / Vendors

Policy / Budget / Ownership of data

LDAP vs. PH Differences

Schema Design

Scalability

Special Presentation from Ellen Stokes of IBM

Ellen explained the Directory Interoperability Forum (DIF). Ellen noted that Microsoft and Netscape are aware of the need, but are not current participants. She said to "Stay tuned". The intent of the forum is to promote portability and consistent behavior of SDK functionality. The forum will consist of various workgroups, which will write a Directory Interoperability Proposal (DIP). The various vendors will implement these things in their products and feed back changes to the various standards bodies for formal standardization. Ellen noted that most workgroups should not be in existence for more than a year. Put the group together, come to a consensus, and complete it. Some groups such as the Standards, SDK, and Marketing workgroups may be more permanent and ongoing.

Ellen is currently participating in the IETF group discussing LDAP replication. She noted several times that "directory services are a commodity".

Some DIF references:

http://www.idg.net/crd_open_77874.html

http://www.zdnet.co.uk/itweek/columns/1999/28/veitch.html

http://www.idg.net/crd_directory_77904.html

http://www.idg.net/crd_directory_78626.html

http://www.zdnet.co.uk/news/1999/27/ns-8841.html

 

Issues discussion

The afternoon was spent discussing some of the common issues that were raised during the morning summaries.

Schema development -- How do you deal with people that have multiple hats or roles? Inheritance and multiple inheritance are problems when you go and try to add new attributes and object classes.

A reference was given to "Deploying LDAP Directory Services" (http://www.amazon.com/exec/obidos/ASIN/1578700701/o/qid=939162576/sr=8-1/002-9735722-8640448) as a Directory Services 101 course.

Most everyone agreed that the directory namespace should be flat, and that the schema should be flat. This was a lesson hard learned by some schools, who are now unable to simply change it

"This is not rocket science." George Yates.

Open vs. Commercial

Would you buy Netscape even if they lowered the price? If IBM is giving it away, why consider the others? Some schools are leery of the new Netscape/AOL/Sun alliance and do not want to depend on the Netscape server.

Synchronization issues - Frank Grewe's answer is the "Registry". Different services are the authoritative source for different attributes for users. Email address, personal URL are sent to PeopleSoft.

Some applications, like Netscape Calendar, expect to update the directory itself.