Directory Services

A Waterloo Polaris Technical Description Draft

Introduction

Every significant computing installation eventually requires some way to store and retrieve common information ranging from phone numbers to mundane operational values like printer driver settings. Usually, ad hoc approaches are employed (simple lists), but eventually they are replaced with general-purpose directory services built upon proper databases and with distributed and fault-tolerant technologies.

This paper discusses how Waterloo Polaris will migrate to new open protocol directory services as part of our Phase II strategy.

Several points discussed here may change or are open for discussion. We will likely proceed with an initial implementation and refine it based on experience and product availability as we migrate more information to this directory service.

The Present

To date, Waterloo Polaris has relied on Watstar’s primitive directory services to answer all sorts of questions such as:

who may log onto a given station (is the station locked to only certain people)
the workstation’s room number (the station includes this for error logging and the hardware database)

which printers will be used for this user on this station (depends on building location, physically attached hardware and user preferences)
which drivers will those printers use (list of printers, brands, drivers, room locations, comments)
where can the user’s applications come from (usually the closest server)
where does the data really come from (redirection if the data had to be moved elsewhere, even redirect users as part of a disaster-recovery restore)
which applications may each user run (may be decided by user’s administrator)
how and when will a workstation do the daily maintenance, and from where will it get its updates (station’s administrator must decide)
which news server should be used (based on user’s home, not physical location)
which Email server should be used (also based on user’s home)

Each of these is answered by a database lookup of (a) a specified parameter (e.g. login restrictions) and (b) one of the following pieces of information:

Key	Description	Examples
local station	information peculiar to workstation	who may log in how ‘locked down’ disks are which software should be local what software to add to users (e.g. scanner reading software) update mechanism local hardware settings to make available to client (e.g. printers)
station groupings	stations are often grouped into similar collections. eg. a classroom of nearly-identical machines, or common characteristics in a group of offices	login banner preferred nearby printers room booking timetable
user account	characteristics special to this user	privileges list of accounts/servers to use (Email, web, etc.) list of courses
user server	characteristics shared among all users of a particular home server	policies of all sorts pointers to servers (news, licensing, etc.)
global information	information of the network some centralized master lists some information about objects like printers which exist around the network	master list of user servers and station groupings lists of public printers printer driver information

Much of the information is naturally decentralized. Faculties and departments have authority to effect all sorts of changes, so obviously they need the ability to update the information in the directory.

The following graph demonstrates decentralized directory services in place today. The example given is a Math user named erick@cygnus1 who logs into the Engineering Helix computer lab located in EL-108.

The Helix manager has listed laser@development and colour@office as the closest laser printers. Unless there are reasons to avoid using them, Waterloo Polaris automatically uses the directory services to fully configure the current session for these printers.

Other values are chosen by the user’s home faculty/server. For example, the Homeserver hooke is listed. Waterloo Polaris automatically connects this user to the appropriate home directory of this Network Applicance. The device could just as easily have been an NT server or a Unix server.

Some choices are perhaps less obvious. IST has organized a news server hierarchy based on faculty, and so all Math students are expected to read their news from news.math.uwaterloo.ca whether the user’s computer is in Math or not. Waterloo Polaris directory services honour and actually implement that strategy.

What is notable is that our directory services are system-wide yet have distributed control. A Math student using an Engineering computer gets a reasonable set of values based on decisions appropriately made by either Math and Engineering. If the user wishes to redirect to a printer in Arts, then Arts-specific information also enters the picture. Even non-polarized servers (such as Graphic Services, Watserv1, etc.) are easily accessible by our users as soon as we include appropriate entries in our directory.

The current system is easily extensible, and so it has become pervasive in almost every aspect of Waterloo Polaris. Its successor will need to be fast, reliable and offer additional benefits.

The major problems are:

current Watstar server dependence – need to move to open protocols
mostly uses flat ASCII lists - awkward to update
private information is stored/retrieved separately and is less extensible

And so we plan to evolve to the next logical step.

The Future

The world is increasingly turning to open standards to fulfil such directory service requirements.

The classic directory services example in open protocols is X.500, a component from OSI world. X.500 encompasses both the overall namespace (ie. how you describe data) and the protocol for querying and updating it (known as DAP or Directory Access Protocol). DAP would be great, except that it is overly complex, with several components that are best described as esoteric. This complexity results in a large memory footprint and so X.500 would be unacceptable for workstation parameter settings.

As usual, the Internet community preferred a smaller and simpler directory service strategy. The best parts of X.500 are retained, but the protocol and schema were adapted for the TCP/IP world. The resulting system is LDAP, or "Lightweight Directory Access Protocol".

LDAP is quite a hot topic. It’s quite useful, and client implementations are small enough that we can leave it resident in the computer to answer questions as they arise.

In the enterprise, LDAP is often integrated into PH, Whois and other services. On the desktop, Netscape Navigator, Internet Explorer, Microsoft Mail and many other programs are including LDAP query features. Novell Netware now supports LDAP access to its NDS (Netware Directory Services), Microsoft Exchange has LDAP serving capabilities.

Finally, Microsoft NT 5 promises to offer LDAP as one way to host its Active Directory services (that component is also available for NT 4 today).

Anyone planning client/server directory services for TCP/IP based networks should be considering LDAP as soon as possible.

While LDAP and X.500 define the transmission and representation of data, they do not specify the backend store of data. Often, LDAP is a lightweight front-end to a sophisticated X.500 service, or to other LDAP servers, or to a local database technology (dbm, Oracle, NDS, etc.).

LDAP can also provide secure access to private data using secure communications such as Kerberos or SSL (secure socket layer), but the latest LDAP specifications lack the details necessary to ensure security interoperability between vendors.

There are several shortcomings, such as the absense of an open standard data replication protocol between servers.

While LDAP is a standard, it is a weak standard because key components are either missing or incomplete. LDAP clients will usually be able to perform most primitive operations on most LDAP servers, but different implementations will have difficulty as soon as we try anything slightly more complex. LDAP is not as perfect as SMTP Email (and Email’s not perfect yet), so interoperability is a bit strained. In implementation terms, this really means we can theoretically work with anything, but must conduct tests with any particular product before assuming it is compatible with our other products.

The Plan

Waterloo Polaris needs to move directory services off of Watstar, and LDAP appears to be the best solution. The total solution, of course, is more than just the name of a protocol.

The basic plan is:

use LDAP between client stations and a few reliable and consistent primary LDAP servers
client stations will know these primary servers by name
when these primary LDAP servers receive requests, they will either reply with the results, or chain the request to a secondary LDAP server (such as a departmental server)
within faculties, departments will have the option of

running their own secondary LDAP server and being responsible for keeping it up
read/write access to their LDAP data on the main faculty LDAP server system (this is preferable for reliability and performance reasons)

Basic Protocols and Products
Clients

All Waterloo Polaris client stations now have client drivers, and can talk LDAP v2 and v3 today as well as using the traditional directory services – a unified directory service to allow a comfortable migration.

In the coming months, some of our utilities will adapted to use the unified directory service. In time, the Watstar server component will become less relevant and eventually eliminated.

Also, SSL and other appropriate mechanisms will be added to supplement missing or limited components of LDAP.

Servers

Several LDAP server products exist for both NT and Unix environments. Examples of both have already appeared on campus, though each have some different aspects, particularly in regards to security, and some are easily tied to extensible databases while others are more simplistic.

Both NT and Unix LDAP servers can support userid/password authentication and authorization, and some can forward the authentication data to other authentication standard devices, including PDCs (Primary Domain Controllers) compatible with the campus ID-Auth project.

The LDAP strategy may reduce direct client interaction with the authentication server, but the authentication request will simply come from the LDAP server.

Administration Tools

Some workstation-level tools will use the Waterloo Polaris LDAP drivers which are simply Win32 level drivers (95, NT, etc). However, many campus operations have Unix or other needs.

For Unix and NT, several LDAP tools already exist.

Furthermore, it will often be reasonable for some programs to interact directly with the backend database using Perl, Oracle tools, or whatever is necessary or appropriate.

Big Issues
Performance

There will be a lot of client requests. Performance monitoring will be necessary on LDAP servers, just as on any other important servers.

Reliability

The directory services are an essential component of the system. Even logins become extremely difficult if directory services are down for any period of time. Furthermore, the system should be resilient enough to survive networking faults which temporarily isolate particular faculties, with the consequences being felt only by users who try to use resources on the other side of the networking fault.

In many cases, we will probably look at some faculty-located LDAP server, and a healthy bit of replication to improve fault tolerance. Also, the server should be backed up regularly, and the database stored on a disk which will not fill.

Consistency

Directory services are only useful if consistency is maintained. For example, the object names and uses must be consistent, mandatory fields must be set, and there must be adherence to certain protocols (like SSL) for compatibility.

It would also be appropriate that some cross-campus people have read/write access to the LDAP server databases to assist with the operations of each faculty constituency.

Ideally, we would use a campus LDAP configuration on faculty servers that would package these commonalties. However, secondary LDAP servers of any type could conceivably be integrated.

Distributed Management

There are several goals to our centralized/distributed plans:

centralize data stores (by faculty) for:
speed - less redirection
reliability - fewer possible points of failure than many little stores
actual ownership and management of departmental data must stay with the departmental staff, so centralization should not be seen as a loss of control or responsibility by departmental staff, the data just happens to be located centrally in each faculty
tools must allow staff easy access to change their data

Clearly the database management mechanisms need to be designed to deal with the hierarchical nature of some data. While much of the data may be housed on a faculty server, a small set of individuals will need read/write access to update parts of it.

For example, a printer in the Systems Design DASL lab would be controlled by Systems Design staff. If the printer was broken and routing moved to laser@gaff, the Systems Design staff would want to change the entry:

Likewise, the same staff will likely need the ability to add or purge large numbers of entries whenever convenient, often using ASCII lists.

There are several ways of accomplishing this, we just need to plan a consistent way right from the start, and hopefully use intelligent mechanisms which avoid many little LDAP servers across campus.

The LDAP directory services described for Waterloo Polaris could be integrated with other campus plans, or could simply co-exist with little integration. Such implementation issues will be resolved through interaction between the faculties, departments, IST, etc. as the implementation moves forward.

Draft Oct 8, 1998, Erick Engelke