(as of December 1992) X.500 Directory Service at the University of Michigan The University of Michigan is a large and diverse organization, employing approximately 25,000 faculty and staff and enrolling almost 50,000 graduate and undergraduate students in 27 schools and colleges, spread across three main campuses. U-M's diversity is reflected in its computing environment which includes mainframes, PCs, Macintoshes, Unix workstations, and many other platforms. Computing usage ranges from word processing to numerically intensive scientific computing to program development to electronic mail, and everything in between. Providing directory service to this eclectic collection of users and machines is a challenging an interesting problem at which we have been working for over two years. We have been offering production-level directory service for over a year, and our DSA is currently answering about 15,000 queries a day on average, with usage growing steadily. We continue to work to better integrate X.500 into our existing campus e-mail, information services, and general computing environments, in addition to providing our users with access to new more exciting technologies enabled by X.500. The basis of our service is a single QUIPU DSA running on a Sun 4/470 with 192 Megabytes of memory, and two 1 Gigabyte IPI disks. The DSA holds over 81,000 entries corresponding to all U-M faculty, staff, and students. Data is updated in bulk from the U-M administrative Personnel and Registrar databases approximately once a month. From these sources we take the user's name, title, postal address, telephone number, school or college, and leave information (for faculty and staff) or class standing (for students). The update process is performed off line by a large C program called munge written especially for the job. We also take smaller bulk updates from system administrators on campus, for example containing email addresses for their users, which are accomplished through DAP using a tool we have written called merge. We maintain a campus-wide database of login names (called uniqname). This database is maintained separately from the X.500 database, but the uniqname server has been modified to update the corresponding X.500 userid attribute every time it makes a change in its own database. This kind of automatic real-time shadowing of information mastered in other databases has worked quite well for us, and we intend to apply this technique to other databases. In addition, users are able to update their own entries and to choose whether they want their entry to be updated from the administrative data source. The first time a user updates a field in their entry that is affected by the bulk update process, the DUAs we provide will explain the bulk update process to them and ask whether the user wants their entry updated in bulk or not. The user's response is recorded as an attribute in their entry. The directory is well-integrated into our existing computing environment. Not having the resources or authority to make changes to the many thousands of client machines on campus, whenever possible our approach has been to make only server side modifications. This approach has worked well in the following areas: - E-mail: Our campus e-mail environment is diverse, spanning LANs to mainframes, with interoperability based primarily on SMTP gateways. We have modified sendmail to do X.500 lookups so that mail sent to name@umich.edu will be routed to the address specified in the user's rfc822Mailbox attribute. - Finger: We have written an X.500 finger daemon that searches our portion of the X.500 tree, so fingering name@umich.edu actually accesses the U-M X.500 database. - Gopher: We have several growing gopher-based information services on campus. Through the use of gopher to X.500 gateway software we have written, gopher users are able to access the X.500 database. Access is provided not only to our local portion of the DIT (which appears as a U-M phone directory), but also to remote portions of the DIT through a more general gateway that allows gopher users to browse the X.500 DIT. - E-mail queries: Users without access to a real DUA or any of the gateways described above, can send mail to x500-query@umich.edu and have a query such as "whois Tim Howes" automatically responded to. We also offer a number of user agents to the campus, providing both read and update capabilities. These range from ud, a simple command-line interface modelled after a mainframe directory program widely used on our campus, to maX.500, a friendly GUI DUA for the Apple Macintosh. Ud is used primarily as the lowest-common-denominator interface and is available at the campus-wide network prompt. Despite its rather crude interface, it is widely used. maX.500 is available at all of the public computing clusters around campus, and is the interface of choice for Mac users. Unix users have a variety of interface choices, from the simple ud to the X-Windows-based Xlu. We have yet to find or develop a good interface for MS-Windows, though we have ported ud to DOS, under the name of bud. Given the large number of relatively small machines on the U-M campus, and the general lack of X.500 expertise among our users, it has been important for us to provide X.500 access that performs well with limited computing resources and for which the cost of entry for a user is very low. Both of these requirements are met by the Lightweight Directory Access Protocol (LDAP), on which most of our services are based. The U-M implementation of LDAP does not require ISODE to compile, run, or develop LDAP clients, and provides a simple API that greatly simplifies X.500 DUA program development. LDAP has made it possible, for example, to develop a gateway that allows Apple's OCE directory service direct access to X.500. We plan to do similar projects with other vendors. Security on the U-M campus is of prime concern to us and our users. We make extensive use of QUIPU's access control (both per entry and search and list ACLs) to prevent unauthorized bulk downloads of data and unauthorized access to or modification of certain attributes. For authentication, we have modified QUIPU to support Kerberos version 4 so that we may leverage the existing campus Kerberos databases, which contain over 20,000 Kerberos principals. We are in the process of changing our various DUAs to know about Kerberos. With the white pages portion of our directory service well in hand, we are investigating several non-white pages applications. These include using the directory to store mailing lists, special interest groups on campus, information about documentation, and a directory of scientific images. This latter application is part of a joint project with the U-M College of Engineering, in which JPEG "thumbnail sketches" of the images are being stored in the directory, along with general information about the image and pointers to where the full image can be retrieved.