The following are suggested steps and considerations for establishing an enterprise directory for your institution:

• Identity analysis - Before any directory is completely effective, it is necessary to resolve a number of issues related to how individuals at your institution are identified. While it is not necessary to establish a single identity value (i.e. user ID or ID) for each member of the community, it is necessary to know and understand which ID is primary, and how it is assigned and managed. The directory can help correlate disparate IDs used by various systems and services. To this end, the following practices and issues need to be addressed.
• Determine what identities you have for everyone and how they relate
• Administrative - these might include the PeopleSoft empl ID, the SSN or any other internal value associated with an individual.
• Account IDs - these might include the user ID used to log into systems or services including central computing systems such as e-mail, or a LAN.
• Other values like the Library Patron Number.
• Determine the criteria for membership in the institutional population (faculty, staff, students, alumni, donors, parents, others?). There are policy implications that control this membership. Note that depending on the identity in question, the population may be different from other such IDs. For example, the population may include prospective students, alumni, visitors, friends, and so on.
• Determine how ID's are assigned / changed.
• Does an ID get assigned, or does the user have a choice of ID (assuming it is not already in use).
• What alternatives are there for a user to request an ID change. If a change is granted, is the new ID assigned or does the user get to choose the ID.
• Is there a maximum frequency for ID changes? Note that different ID's will have different controlling issues regarding changes. For example, consider the SSN, which is controlled by a government agency, and a login user ID, which may be established by a system administrator and changed much more flexibly.
• How long should a previously used ID be held in reserve before it is reallocated?
• Determine the primary authority for each identity.
• When an ID is established, a primary authority, which may be an application system or office, is responsible for managing the ID. This may include associating the ID with the primary student record, or HR record, coordinating and managing ID changes, responding to inquiries regarding a particular ID and being involved in resolving identity conflicts.
• Establish an identity reconciliation process.
• It may be appropriate to establish a unit or task force or committee with the responsibility for reconciling cases of confused or conflicting identity.
• As an individual enters the university population, it is important to be certain that a new set of identities are not established for the individual. Note that the SSN is the most often used mechanism to automate this reconciliation process.
• Establish sources of information for the populating directory. Possible sources include:
• Human Resources System (HRS)
• Student Information System (SIS)
• Alumni/Development system (donors, etc.)
• Other Affiliates
• Determine technical requirements and resources
• Determine the data that will be required in the directory. Consider applications that will use the directory as the source for information.
• Develop the Schema. The LDAP-based directory is based on objects, each of which contains a collection of attributes. A schema is used to define the objects, attributes, and characteristics of the attributes. Please refer to the basic schema defined elsewhere in this document.
• Establish the staffing requirements and source of staff. At the minimum, it will be necessary to include staff to manage the directory, do the technical implementation, and coordinate information collection and management. The actual needs for a particular institution might be as little as part of an FTE to as much as two to three dedicated staff.
• Software/hardware - Several LDAP directory servers are available at little to no cost. These include OpenLDAP, Sun One Directory Server, and IBM SecureWay. Many Universities use SunOne Directory Server. The hardware should be selected based on the chosen software.
• Consider the overall architecture of the directory. As the directory becomes a critical resource, it must be available 24x7. As such, a highly redundant and resilient infrastructure is needed. Typically, this means including one or more replica directory servers. It may occur that the directory becomes the primary source for certain data elements (in support of a particular application), in which case, a mechanism will be required to can periodically capture and archive this information.
• Policies
• Membership - The policies related to membership define who is considered to be a member of the institutional population. If an individual is a member of the population, it is reasonable to include him or her in the institutional directory. There may be exceptions to this, where an individual may be excluded from the directory for some reason.
• Publish or not (for particular data elements). Note that presence in the directory does not necessarily imply that an entry is available to general searches. In fact, there are numerous examples of information that may be present in the directory that is not appropriate or desired to be available to be searched. For each data element, it is important to consider whether that data element is public information or not. If a data element is not public information, consideration must be given to what criteria must be met to grant access to that information.
• FERPA Implications. Federal Law allows a student to request that all of his or her records pertaining to attendance at an institution are blocked from public release. This restriction must apply to the directory as well. Note, however, that if an application expects to use the directory for user authentication or to determine other characteristics about individuals, these attributes must be present in the directory, but not searchable via normal means.
• Establish Processes for ongoing support.
• Systems such as this require regular monitoring and management. As much as possible should be automated so as to minimize the day-to-day support requirements.
• All processes and systems should be incorporated to the greatest degree possible into the regular system and support infrastructure.
• Items that will need to be monitored include:
• Data feeds from each source (if any)
• Correct operation of any scripts or programs used to update the directory, capture status changes, do backups, and so on.
• OS and hardware performance and release levels.
• Insure there is Problem resolution support (1^st & 2^nd level help desk).
• Establish a set of directory enabled applications. Creation of a directory is useless unless there are applications that use the directory information. Some initial applications that can use (and justify) the directory include:
• Directory search. The directory may be searched for e-mail addresses, physical addresses, phone numbers, and more.
• Centralized forwarding service. The directory can be used to establish a central address space. For example, at College Park, there are several distinct e-mail systems operated by various units. Even though individuals may receive their mail at one of these disparate systems, they may still advertise the address defined by the forwarding service.
• Email. Most modern e-mail clients (including Netscape Messenger, Outlook, and Eudora) contain the ability to define LDAP based directories as a type of address book. In these cases, finding an e-mail address for an individual is no more difficult than typing their name into the compose window.
• Information resources. The directory may be used to store and retrieve information by an application.
• Commercial Applications. A number of commercially available applications are directory-enabled or aware.
• CorporateTime Calendaring.
• Business systems such as PeopleSoft.
• Learning Management Systems (LMS) (e.g. WebCT, Blackboard, etc.)
• Web Portals

The EDUCAUSE/Internet2 eduPerson task force has defined an LDAP object class that includes widely-used person attributes in higher education. The eduPerson object class (http://www.educause.edu/eduperson/) provides a common list of attributes and definitions.

The data attributes to include in a directory should be based on the needs of the applications that will use the directory.

• Must Have
• Name
• Phone number
• Unique ID
• Mailing Address
• E-mail address
• Password

• Desirable
• Home Address/phone
• Personal URL
• Relationship to the Institution (e.g. student, faculty, staff)
• Faculty and Staff
• Title
• Department/College/Unit
• Students
• Class standing (Junior, Senior, Grad, etc.)
• Major
• Current registration information