An enterprise directory service has the potential for transforming the way in which students, faculty and staff at the University of Georgia utilize information technology (IT) resources. Through the establishment of an enterprise directory service, new opportunities for effectively leveraging these resources can be realized. This article will answer the following four questions:
An enterprise directory service (EDS) consists of a specialized database where information is maintained regarding campus IT resources and one or more servers to deliver the information contained in that database. An EDS (which will also be referred to as a directory) offers a way of naming, describing, and locating institutional resources such as people or groups, or services such as document and data repositories or printers. Directories are set up through a hierarchical naming model which organizes resource information into what is called a directory tree. There are several ways to organize resource information in a directory tree. For example, it can be organized based upon the administrative structure of the University or it can be organized based upon the geographic location of resources. The figure below provides a sample directory tree.
Object is the term used to refer to either a specific resource (a leaf object) or a collection of resources (a container object). The types of objects that are typical in a directory are organization (e.g., UGA), organizational units (e.g., the Management Department or College of Education), users (e.g., faculty member James Smith or students Ching Xu or Loretta King), groups (e.g., MGMT 2010 class), servers (e.g., document, Web, mail, etc.), and network-accessible printers.
Every object in a directory must have properties or attributes. For example, a user object will typically contain attributes such as full name (James Smith), e-mail address (jsmith@uga.edu), or Homepage (http://www.arches.uga.edu/~jsmith). It will also contain authentication attributes such as login ID (jsmith) and encrypted password (******). Another example of an object with multiple attributes is a workstation. Every workstation on the network must have networking parameters such as Internet address, name server addresses, etc. to properly function. These parameters can be stored in the directory. Policies, such as allowing support personnel to access a workstation over the network and take over or monitor what someone is doing, can also be stored as attributes of the workstation object.
An important part of an enterprise directory service is the ability to store access control information (ACI). ACI’s are needed to control who can update directory information and what objects and attributes they can change. Typically, ACI’s are associated with group objects which give everyone in that group the same access controls, but they can be assigned to individual user objects as well.
The directory must define the kinds of objects that can be named and what their properties are. The word schema is a term that refers to the set of all object types in an directory and their properties. If UGA had a campus-wide tree, the schema would consist of all of the organizational unit or group objects as well as user, server, printer and other objects. In order for an EDS to be viable, the schema must be able to be extended (new object types and properties added) so the new information can be referenced. It is also highly desirable for the schema to be extensible on the fly so the directory doesn’t have to be taken offline when new types of information need to be added.
Two other important EDS features are distributable and replicable directory services. Most people have had the experience of being at the checkout counter of a large department or grocery store and being unable to purchase goods because “the system went down.” This situation usually arises because there is one central database where information is stored and when that database goes down or a computer loses connectivity to it, that computer cannot perform its functions. If pieces of a directory database are distributed and put it onto servers close to where users are located (rather than in one central database), then the chance of not getting access is minimized. This is referred to as a distributable directory service.
If there is only one copy of directory information (such as passwords or the locations of file and print resources) stored on a local server that one wants to access and the server goes down, access to that information is again not possible. One needs to be able to replicate (or make copies) of object information and place the replicas on multiple directory servers so the information can be more readily available. It is also critical to be able to update the property of an object on any of the replicas and allow all of the replicas to reconcile any differences among them. This is called multi-master, directory replication.
There are two ways to access directory information — proprietary or vendor-specific methods and standards-based methods. Proprietary methods are typically used within the enterprise, and standards-based methods are used both inside and outside the EDS. An example of a proprietary method is the Novell Directory Services Application Program Interface (NDS API), which is used by many desktop applications and management tools developed by Novell. The Lightweight Directory Access Protocol Version 3 (LDAP V3) is the only standards-based method. With LDAP V3, directory information is made available to LDAP-enabled applications and permits individuals using those applications to read and update directory information (with appropriate authorization) through this standard interface. LDAP can also be used to build meta-directories of information.
Meta-directory services (MDS) provide a way of naming, describing, and finding internal and external IT resources across information system and institutional boundaries. A well-developed MDS can be used to support communities of interest and inter-institutional initiatives. In order to build meta-directories, however, every participating institution must have a viable enterprise directory service in place. Unfortunately, there are no mature MDS offerings available today and there are numerous, complex methods of implementing those services.
An enterprise directory service provides four general functions.
With an EDS there is the possibility of integrating user authentication to all IT resources so that a student, faculty, or staff member only needs one login ID and password to gain access to all appropriate resources, rather than requiring separate authentication information for each resource. Examples of the resources that might potentially be accessed by one login ID and password include the ARCHES, WebCT, administrative information systems (such as OASIS, student records, accounting, and procurement), and departmental NetWare, NT, and Unix servers.
An EDS can be used to facilitate security services based on a technology known as public key infrastructure (PKI). PKI uses two types of security keys — a private key and a corresponding public key (typically stored in the directory within a digital certificate) — to enable secure applications. For example, an individual’s private key can used to sign documents electronically and the corresponding public key (obtained from the directory) would be used to verify the digital signature. Data, on the other hand, would be encrypted with a user’s (or application’s) public key and decrypted with the appropriate private key. Encryption of data and other sensitive information such as passwords before they are transmitted over a network should be an essential IT security goal for the University. Although PKI technology will need at least a couple years of maturation before it can be effectively utilized at UGA, it will require a robust directory service in place before it can be deployed.
Through a technology called directory-enabled networking (DEN), directories can be used to manage network devices such as hubs, switches, and routers and to restrict access to physical network connections. For example, when a portable device such as a laptop is plugged into a live network connection, the individual may be asked for directory credentials before access is granted. DEN can also be used to manage intensive networked applications such as video services so that an appropriate quality of service (e.g., adequate network capacity) can be provided on an as needed basis. Desktop management functions (such as centralized software deployment, remote control support, and hardware and software inventories) can also be facilitated though directory services and will help ease the burden of support staff.
Another area which directories can support is access to instructional resources. Student and faculty access to course information and resources can be stored in an EDS, typically through access control information (ACI) associated with directory groups. By automating the creation and maintenance of course groups and ACI’s through the processing of Registrar data, access administration via the directory can be streamlined and manageable. Although it will take considerable time to implement, meta-directories (which tie together institutional directories) have the potential for facilitating inter-institutional e-learning such as the eCore and GLOBE initiatives supported by the Regents.
Novell Directory Services (NDS) has a number of advantages over other potential EDS offerings such as Microsoft Active Directory (MAD) and iPLANET (previously called Netscape Directory Services). These advantages include:
NDS is highly distributable, which allows you to take very small chunks of directory information and put it wherever needed. Microsoft Active Directory is only moderately distributable because it only allows you to divide it down to the campus unit’s Internet domain name. iPLANET directory information cannot be distributed. It consists of a master database server and a backup and can be stored in only one location.
Both Novell and Microsoft have multi-master replication. For example, if you were to update your password on one copy of the directory database, it will eventually get to all other copies. iPLANET has master/slave replication, which means information can only be updated on the master and if the master goes down, directory information cannot be changed. All three vendors support LDAP V3 access.
In terms of scalability of directory information, Novell claims that they can support billions of NDS directory objects; Microsoft and iPlanet can support millions of directory objects. As mentioned earlier, one must be able to add, delete, or change directory object types and their attributes (or properties), which is called schema extension. All three vendors will allow the schema to be extended, but only Novell will allow schema modification on the fly.
Desktop management functions (such as centralized software deployment, remote control help desk support, and hardware and software inventories) can be facilitated though directory services and will help ease the burden of support staff. Novell, through Z.E.N.Works and NDS, supports desktop management for all of the Windows (95, 98, NT, and 2000) platforms. Microsoft has full integration of desktop management via MAD only for Windows 2000 desktops. In order to do desktop management with iPLANET, you must write your own based upon LDAP V3.
With regard to the storage of directory information, Novell currently will allow you to store pieces of the NDS directory on at least six different platforms, such as NetWare, Linux, Solaris, AIX, Windows NT, and OS/390. The only platform where MAD information can be stored is in Windows 2000. At this time, iPLANET only supports two platforms, Solaris and Windows NT.
Novell will natively support NDS authentication (logging into IT resources) through all Windows desktops, Macintoshes, most versions of Unix, and RACF on MVS systems. Microsoft will only support Windows platforms in terms of MAD authentication. iPLANET is supported by LDAP V3 only, and you must write your own authentication to the directory services through an iPLANET server.
Finally, in terms of proven technology, Novell has been developing NDS for seven years and has stabilized it over that time period. Microsoft Active Directory just came out in February, 2000, and it has a long way to go before it is a viable EDS. iPLANET has been around for approximately the same time as NDS.
The UGA EDS implementation road map consists of three phases.
Phase I is to create and populate the UGA NDS tree with login IDs for all students, faculty, and staff. Four subgroups of the EDS Working Group have been created to deal will implementation issues:
Login ID Maintenance - This subgroup will focus on the design and maintenance of the directory tree and the information contained therein.
Student Computing Facilities - The focus of this subgroup is to develop specifications for accessing EDS information from student computing facilities.
Network Services - Specifications for hardware and software to implement EDS will be developed by this subgroup.
EDS Promotion - This subgroup has been and will be developing EDS presentations, articles, and position papers.
A preliminary NDS tree design has been completed by the Login ID Maintenance subgroup. There will be a student container, which is where all student objects will reside. There will also be containers for each department, school, and college and under them faculty and staff objects. Members of the Login ID Maintenance subgroup are working on populating the directory with ARCHES account information and creating secure Web pages for ARCHES/NDS password synchronization. It is anticipated that this will be accomplished by the end of Summer Semester 2000. The Student Computing Facilities subgroup has met once and is in the early stages of developing SCF access specifications. A testbed is in the process of being set up to investigate NDS implementation issues, including the specification of hardware and software by the Network Services subgroup. The EDS Promotion subgroup has given presentations to the UGA Network Managers Group and the Campus Information Technology Forum regarding enterprise directory services at UGA and has written this companion article.
In order for enterprise directory services to be viable in the long term, NDS login IDs will need to be created for new individuals arriving at the University within the first week of their association with the University — students through the Registrar’s Office and faculty and staff through Human Resources. These IDs should stay with them throughout their UGA affiliation, and when they leave the IDs need to be removed so they no longer have access to resources. Members of the EDS Working Group will dialogue with appropriate UGA offices and include them in the process of developing EDS services. Hopefully, an ongoing ID maintenance process can be put in place by early in Spring Semester 2001.
Phase II of the UGA EDS implementation will consist of migrating white pages services (currently on a Netscape directory service) and calendar authentication services to NDS. This phase will also include providing single login ID/password authentication for all systems, including the IBM MVS mainframe. Single login ID/password NDS authentication is available for all Windows platforms, Macintoshes, NT servers (through NDS for NT), Solaris servers (through NDS for Solaris), Linux servers (via NDS for Linux), other Unix Platforms, and MVS/RACF (through Clemson’s Authserv Product). Most of the products that provide authentication services, with the exception of Macintoshes and Authserv, are available through UGA’s Novell Academic Licensing Agreement (ALA) program.
Phase III will involve the creation of new enterprise directory services applications, such as incorporating student courses into the directory so the appropriate resources can be accessed based upon what classes they are taking. This phase will also include integrating WebCT and ARCHES authentication via NDS (or through an LDAP V3 interface). Secure applications utilizing PKI technology and meta-directory services that provide students with access to IT resources across institutions will likely take at least a couple years to develop.
An enterprise directory service is a rendezvous point for IT resources and the people who are authorized to use those resources. An EDS will add value to UGA by reducing desktop maintenance through products such as Z.E.N.Works, by streamlining business and student IT processes and access to resources, and by enabling virtual learning committees such as the eCore and GLOBE initiatives in cooperation with other University System of Georgia institutions. Institutional support is encouraged to make enterprise directory services a reality at the University of Georgia.