Enterprise Directory Service at College Park

1. Enterprise Directory Serviceat College Park David Henry Office of Information Technology University of Maryland College Park david_henry@umail.umd.edu

2. History • Umail directory – 1990 faculty/staff only • Gopher/CSO directory – 1993 f/s only • Added web page access – short time later • University wide effort to build combined directory • X.500 considered, but wasn’t ready • Decided on gopher with single search page (umbc) • First LDAP – 1995 f/s only • Current LDAP – 1999 f/s/students/affiliates

3. Content • People • Prospective students • Students • Faculty (current and Emeritus) • Staff • Affiliates ( Visiting faculty, Golden ID, etc.) • Alumni • Other things too

4. Where we are now • Running IBM Secureway LDAP server • Contains faculty, staff, students, affiliates • Does not contain alumni • Access to student data is limited (for now) • LDAP is not the primary source of most data • Data feeds required • HR, SIS, ARS, affiliates, etc. • Data warehouse simplifies • Weekly updates

5. Current work • On-the-fly updates of certain data elements • Privacy flags (Buckley) • Email address • Ultimately want to update each data element as appropriate • Instant (e.g., email, privacy flags) • Daily (e.g. registration/course info) • Weekly (e.g. address, phone, etc.)

6. Who is involved? • LDAP Steering committee • OIT staff only • Involving Administrative and Academic IT support units • Team effort • Data Warehouse/DBA’s • Programming staff • Construct data feeds • Process/consolidate data • Web based tools

7. Why do all this? • Single sign-on • Common and consistent (standards-based) mechanism for authentication and authorization • 24X7 services • Can use freely available access tools • Don’t need special client tools (e.g. Oracle) • Many COTS packages contain hooks for LDAP already

8. Some specifics • Distinguished name uses employee number • Everyone in the people databases gets one • It is unique • It never changes once assigned • 8 digits plus a check digit • Selected attributes • Name, uid, email address, phone number, ssn* • Students*: college, major, courses*, class standing* • F/S: title, department, home address*, home phone* * Restricted access

9. A Critical Resource • As the directory becomes a critical part of the enterprise infrastructure, it becomes critical to have stable, always available services. • Systems should have redundant components • Should run replicated servers • Located on different parts of the network • With battery backup • 3 replicas • Any two should be able to handle load

10. Directory Enabling Applications • Permissions required for each application • Buckley entries won’t appear otherwise • Certain attributes are protected • Ssn, registration info • Optionally home address, phone, etc. • Each app should have its own authn id/pwd • Authorization to each attribute controlled by the data steward for that attribute

11. Some Directory Enabled Apps • Email • Directory search (email addresses) • http://www.oit.umd.edu/staff/ • https://cgi.umd.edu/ldap_search • Central forwarding agent (name@umd.edu) • CorporateTime scheduling software • Authorization/authentication • Bunch of attributes • http://calendar.umd.edu/ • Web sites • Authorization/authentication • http://www.agnr.umd.edu/AGNRWebAdmin/index.cfm

12. Some Potential Directory Enabled Apps • Unique ID • Portal authorization/authentication • Dial-up/DHCP access • Card key access • Roles based authorization • Single sign-on • Dynamic email lists (e.g., class, department membership) • More…

13. Examples • Directory Search • Netscape Addressbook • Staff listing – www.oit.umd.edu/staff • Authn/Authz • Corporatetime • Webpage access www.agnr.umd.edu/internal • Affiliates DB updates

14. Issues • Establishing primary source for each data element • Password changes need to be centralized • Establishing policies • Who is in • Who isn’t • What types of information to include

15. Security Services • PKI requires a directory for publication of the public key • See www.inform.umd.edu/About/Staff/dave/PKI • Encryption • Signed documents • Secured access to web server • Note secure server does not mean the data is secure on the server, just getting between client and server

16. Conclusion • A directory provides the basis for a common set of services needed to support the network/web based applications becoming so commonplace at each of our institutions • Significant planning is needed to do it right • Resources are available to help • Use the available resources

17. That’s IT David Henry OIT University of Maryland