Early Harvest Survey

Scope

The intent of this survey is to gather current practice about specific infrastructure services supported at your institution: identity management, authentication, and directory services. We are interested in generally those services that have campus-wide or multi-campus scope (as opposed to intra-departmental).

The proposed results of the survey and the workshop include "roadmap" documents describing both the key policy issues regarding these services, and the solutions in place for them at major institutions. To this end, we're interested in both your detailed answers to the questions below, and your views on whether these are the right questions. If there are other hot issues in these areas at your site, please describe them.

Service Model

We describe a typical (we hope) service deployment model to define terms and provide a framework for discussion. In real deployments these services depend on one another in complex ways, but for design and policy-comparison purposes it is useful to consider them as discrete functions.

Authentication services:

A centrally-supported authentication service contains entries for the institutional population of users and services, and supports protocol operations allowing users and services to authenticate one another. An entry contains at least an identifier and authentication data (usually a password, could be a public key).

Services (eg central timesharing systems) that rely on the central authentication service generally use the authentication identifier as a local "account" name; other services that don't use the authentication service may also choose to re-use the central IDs. The authentication IDs are also often used for other purposes such as email addresses (eg id@univ.edu) and web URLs (eg www.univ.edu/people/id).

Identity management:

Various central systems manage information about people and other objects: student systems, HR, libraries, authentication systems, email services, etc. Generally each system produces an identifier for its own use: authentication ID, student/employee number, ID card barcode, UNIX numeric uid, Windows NT SID, social security numbers, directory Distinguished Name, etc.

Processes are created to link these systems, pair-wise or multiply, to reconcile information about individuals across systems. Such processes often involve much manual intervention. New systems, called "meta-directory" or "registry" or "identity management" systems, may be deployed to better manage these linkages. They may also support functions that span multiple systems, like basing application access on employment status, or tracking a person's multiple institutional relationships over time.

Directory services:

Directories have traditionally had two different functions. One is "white pages": end users looking up contact information (phone, email, department) about institutional people (eg Whois, CSO). The other is distributed system management: enabling shared access to operational databases of accounts, groups, devices, services, policies, etc, to processes on many systems (eg Sun's NIS). Newer directory deployments, usually LDAP-based, may support both of these functions.

Directories may be used to implement authentication services by holding password info (and allowing it to be checked), or complement them by holding additional attributes about authentication entries. Directories may be used to implement identity management services, as well as supporting other services like email routing, authorization, and PKI.

1.0 Identity management questions

A. Personal

1.1 What is your primary campus-wide personal authentication identifier? (If you have several, please explain how they are related.)

1.2 What are other true personal campus-wide identifiers (eg library numbers, administrative systems, email addresses, internal unique ids, etc.)? Which of these depend on (or are linked to) having the primary campus-wide personal authentication identifier?

1.3 Do you have a "meta-directory" or "person registry" system devoted to reconciling and coordinating person data across all systems?

1.4 For the significant campus-wide identifiers, please answer the following questions:

1.4.1 What populations are able to get the ID? (Students, faculty, staff, alumni, visitors, etc.)

1.4.1.1 Do you have special procedures for handling extended populations (eg visitors, friends, contractors, library patrons)?

1.4.2 What are the sets of resources that the identifier is used for? (network access, standard user account, library databases, administrative applications, etc.)

1.4.2.1 Do you have automated procedures that activate when an identifier is assigned (eg creation of email accounts, entries in the telephone system, creation of a web page, etc.)? Do you have similar procedures when an identifier is deassigned (eg a person being fired)?

1.4.3 Do you have a policy of "one person, one ID"? If so, how do you ensure this?

1.4.4 What is the duration of the binding of the identifier to the person? (Are personal IDs ever reassigned to other people?)

1.4.5 Can users change the ID? If so, under what circumstances?

1.4.6 What are the rules for the formation of the identifier (machine or human readable, autogenerated or chosen by users, generated from a central registry or able to be constructed locally, checkdigits, mnemonic, etc.)

B. Objects and Groups

1.5 Are organizations, projects, groups, etc. ever given identifiers? If so, how is ownership tracked? How is usage tracked?

1.6 How are services (print servers, data servers, etc.) assigned identifiers?

Authentication services questions

2. 0 What is the primary campus authentication system (Kerberos, LDAP, clear-text passwords, etc.)

2.1 What systems and services base their authentication on the central authentication service?

2.2 How is the first password provided to a user? (For example, in-person with positive id, by mail using a one-time password, over the phone, etc...) Are the policies the same for faculty, students, staff, alumni, etc.?

2.3.1 Do you check user's passwords for crackability when they change their passwords? (For example, by running COPS or another hacking engine).

2.3.2 Do users have to change their passwords regularly? If so, at what frequency?

2.4.1 If you observe compromised passwords (e.g. from a cracker's log) do you invalidate the user's account? If so, what procedure does a user follow to get the account reinstated? 

2.4.2 Do you ever remove authentication entries based on changes in a person's status (eg leaving the institution)? Are there situations where you remove authentication capabilities on a temporary basis?

2.5.1 Are there procedures to synchronize passwords among multiple campus-wide systems? If so, how frequently and how is this done?

2.5.2 Are there procedures for synchronizing passwords between campus-wide and departmental systems? If so, how frequently and how is this done? Are there a set of requirements for departments that want to do this?

2.6 Do you have special policies or approaches to users using secure passwords in non-secure environments? (For example, logging in across the Internet, or using the same password for non-secure accounts).

2.7 Do you use any approaches, such as challenge-response cards, to augment password-based authentication?

2.8 Are passwords ever kept in cleartext on the systems?

2.9.1 Are there any entries (such as groups,classes) which have authentication capability, and for which sharing passwords is acceptable?

2.9.2 How do services authenticate (password in startup file, supplied by operator at boot, etc.)?

Directory services questions

3.1 What technology is it based on (LDAP, CSO, Whois, etc)? What is the DNS name of the service? How is it located by applications?

3.2 Is it accessible from the Internet? via Web access? via other protocols?

3.3 Can people update their own directory entries? Via a directory-specific UI?

3.4 Can people turn off access to their entry? To specific parts of their entry?

3.5 Is access control on/off, or other levels like "intra-institutional"?

3.6 Can people enter multiple name forms, nicknames, etc?

3.7 How often are entries updated (eg from source systems such as HR)?

3.8 Do faculty/staff entries include residential info as well as office info?

3.9 Is student data combined with faculty/staff in one DS? Are there other populations?

3.10 Are there entries for things other than people, eg departments, programs, functions?

3.11 Are there written directory policies, eg who can/can't have an entry, appropriate use, etc?

3.12 Do you attempt to restrict directory "trolling" (gathering all directory data, eg for resale or republishing)?

3.13 Is your white pages DS integrated with your system management DS?

3.14 Do you support end-user DS clients (eg email applications, Netscape)?

4.0 What technology is it based on (LDAP, DCE, NIS, etc)?

4.1 What applications make use of directory data?

4.2 What kinds of entries are in the DS?

4.3 Is your system management DS integrated with your white pages DS?

4.4 Is the service replicated?

5.0 Describe your directory information tree.

5.1 How are Distinguished Names of person entries formed?