1. Middleware 201 Directories Configuration & Operations Michael R. Gettes Lead Application Systems Integrator Georgetown University Gettes@Georgetown.EDU Internet2 Member Meeting Spring 2001

2. How Deep? Background Site Profile - configuration Applications General Operational Controls Schema Access Lists Replication Related Directories LDAP-Recipe PKI Issues

3. MACE Middleware Architecture Committee for Ed. IT Architects – meet often – no particular religious affiliations MACE-DIR – eduPerson, Recipe, DoDHE MACE-SHIBBOLETH – global AuthN/Z MACE-PKI  HEPKI (TAG/PAG/Labs) MACE-MED – HIPAA, mEduPerson

4. MACE-ochists RL “Bob” Morgan, Chair, Washington Steven Carmody, Brown Michael Gettes, Georgetown Keith Hazelton, Wisconsin Paul Hill, MIT Ken Klingenstein, Colorado Mark Poepping, CMU Jim Jokl, Virginia David Wasley, UCOP

5. MACE-DIR Keith Hazelton, Chair, Wisconsin eduPerson objectclass LDAP-Recipe Dir of Dir for Higher Education (DoDHE) Shibboleth project dir dependencies Meta Directories – Architech free to HE http://middleware.internet2.edu/directories

6. MACE-DIR: eduPerson 1.0 (1/22/01 release) MACE initiated (Internet2 + EDUCAUSE) Globally interesting useful attributes Get community buy-in, must use it also eduPersonAffiliation (DoDHE), eduPersonPrincipalName (Shibboleth) “Less is more”, how to use standard objectclasses http://www.educause.edu/eduperson

7. MACE-SHIBBOLETH Steven Carmody, Brown, Chair A Biblical pass phrase – “password” Get it right or “off with your head” Inter-institutional Authentication/Authorization Web Authentication of Remote Sites with Local Credentials Summer, 2001 – Prototype target http://middleware.internet2.edu/shibboleth

8. HEPKI TAG – Technical Activities Group Jim Jokl, Chair, Virginia Mobility, Cert Profiles, etc, etc, lots of techno PAG – Policy Activities Group Default Chair, Ken Klingenstein, Colorado Knee-deep in policy, HEBCA, Campus, Subs+RP PKI Labs (AT&T)– Neal McBurnett, Avaya Wisconsin-Madison & Dartmouth Industry, Gov., Edu expert guidance http://www.educause.edu/hepki

9. Site Profile dc=georgetown,dc=edu Netscape/iPlanet DS version 4.11 2 Sun E250 dual cpu, 512MB RAM 75,000 DNs (25K campus, others = alums + etc) Directory + apps implemented in 6 months Distinguished names: uid=x,ou=people DC rap, “Boom shacka lacka” Does UUID in DN really work? NSDS pre-op plugin (by gettes@Princeton.EDU) Authentication over SSL; Required Can do Kerberos – perf problems to resolve 1 supplier, 4 consumers

10. Applications Mail routing with Sendmail 8.11 (lists also) Netscape messaging server v 4.15 (IMAP) WebMail profile stored in LDAP Apache server for Netscape roaming (no SSL) Apache & Netscape enterprise web servers Blackboard CourseInfo Version 5 Level 3 Whitepages: Directory Server GateWay DSGW for priv’d access and maintenanceDSGW

11. Applications (Continued) Remote access with RADIUS (funk). No SSL (3/2000); proper LDAP binds (fix 8/2000) Authenticates and authorizes for dial-up, DSL and VPN services using RADIUS called-id. We want to use this for other access control such as Oracle

12. RADIUS server RADIUS + LDAP NAS (terminal server) Dialup Users User calls 202-555-1110 CalledId from NAS is mapped to guRadProf Directory Server Netid = gettes guRadProf = 2025550001 guRadProf = 2025551110 guRadProf = OracleFin LDAP Filter is: guRadProf = 2025551110 + NetID = gettes

13. Applications (Continued) Alumni services (HoyasOnline). External vendor in Dallas, TX (PCI). They authenticate back to home directories. Apache used to authenticate and proxy to backend IIS server. Email Forwarding for Life!

14. NET ID TMS HRIS SIS Alumni LDAP Master Client Browser WWW hoyasonline Content PCI (Dallas) Vendor-provided services Other local hosts GU provided self- service applications LDAP Replica OS/390 HoyasOnline Architecture Gratuitous Architectural Graphic (GAG) Way Down In Texas

15. Applications (Continued) Access+ Georgetown developed Web interface to legacy systems using Unix front- end to custom made mainframe tasks. Many institutions have re-invented this wheel. LDAP authentication, mainframe doesn’t yet do SSL. Always exceptions to rules. Student, Faculty, Staff, Directory/Telephone Access+ Services. This technique keeps mainframe alive. (good or bad?)

16. Applications (Continued) Specialized support apps Self service mail routing Help Desk: mail routing, password resets, quota management via DSGW Change password web page Person registry populates LDAP people data, currently MVS (mainframe) based. PerLDAP used quite a bit – very powerful! (make sure version >= 1.4)

17. Applications (Continued) Georgetown Netscape Communicator Client Customization Kit (CCK).CCK Configured for central IMAP/SSL and directory services. Handles versions of profiles. Poor man’s MCD Future: more apps! Host DB, Kerberos integration, win2k/ad integration?, Oracle RADIUS integration, Automatic lists, Dynamic/static Groups, Top- Secret, Bb – further integration.

18. General Operational Controls Size limit trolling (300 or 20 entries?) Lookthru limit (set very low) Limit 3 processors for now, MP issues still! 100MB footprint, about 8000 DNs in cache Your mileage will vary – follow cache guidelines 24x7 operations What can users change?? (Very little) No write intensive applications

19. General Ops Controls (cont…) Anonymous access allowed Needed for email clients Anonymous access is good if you resolve FERPA and other data access issues.

20. Schema: Design & Maint Unified namespace: there can be only one! Schema design and maintenance Space/time tradeoffs on indexing Eduperson 1.0 vs. guPerson guRestrict, guEmailBox, guAffil, guPrimAfil guPWTimebomb, guRadProf, guType, guSSN Relationships (guref) Maintained by ldif file using ldapmodifyldif

21. Access Lists Design & Maintenance Access lists: design & maintenance Buckley(FERPA) protection & services Priv’d users and services userPassword & SSN Maintained by file using ldapmodifyfile Working on large group controls at GU Groups vs. Roles Likely easy to populate, hard to design & implement

22. Replication Application/user performance Failover, user and app service Impact of DC= naming (replica init) Fixed in 4.13 and iDS 5.0 Monitoring: web page and notification Dumper replica – periodic LDIF dumps Backups? We don’t need no stinkin’ backups! Vendor Specific No good solution for backups (iPlanet) IBM uses DB2 under the covers Novell?

23. Replication (Continued) Application/users config for mult servers Deterministic operations vs random Failover works for online repairs Config servers are replicated also 10 to 1 SRA/CRA ratio recommended Cannot cascade with DC= (netscape) Cascading is scary to me

24. Normal Ops Replica Structure MASTER DUMPER WHITEPAGES MAILHOST POSTOFFICE NetID Registry Web Servers Users Failure Ops

25. Netscape Console Java program (FAT client). Used to create, configure and monitor Netscape servers. Preferred the web page paradigm of the version 3 products. Has enough bugs that it is only used by server admins, not for mere mortals. Demo???

26. Other Directories Novell – GU abandoning GroupWise. Active directory??? Ugh!!! Static Groups Only Strict Tree Structure for Group Policy No plans for MS to change this… Integrate whitepages service with hospital. This led to the consideration of…

27. Directory of Directories Outgrowth of Georgetown WhitePages problem Expose common schema and use Eduperson 1.0. Performance issues for massively parallel searches. Interesting lessons learned about LDAP API. Sun Microsystems Grant. Will it be more than just an experiment? Now being worked on to make it real. (11/2000) See Directories Update Session on Thursday

28. LDAP-Recipe http://middleware.internet2.edu Or http://www.georgetown.edu/giia/internet2http://www.georgetown.edu/giia/internet2 DIT, Schema Design, Access Control, Replication, Name population, Good use of LDAP design and features, LDAP configuration, Password Management, eduPerson discussion, DoDHE expectations

29. domainComponent (DC=) RAP The “DC” Rap, origins belong to RL “Bob” Morgan, University of Washington Traditional X.500 naming: cn=Michael R Gettes, ou=Server Group, ou=UIS, o=Georgetown University, c=US Vs. domainComponent (DC) naming: uid=gettes,ou=People,dc=georgetown,dc=edu HEPKI is issuing guidance and advice on DC= naming

30. Buyer Beware LDAP is LDAP is LDAP – yeah, right! “Sure! We support LDAP!” What does that mean? Contract for functionality and performance Include your Directory/Security Champion!!! Verify with other schools – so easy, rarely done. Beware of products that specify Dir Servers Get vendor to document product requirements and behavior. You paid for it!

31. Local Policy We don’t need no stinkin’ policy! Covert warfare can be a valid tactic for IT deployments Yes, this is a juicy rationalization with a self-serving purpose Still need to apply FERPA and HIPAA officially. Applied best practice thus far – ok for now. Verified no District (DC) Laws limiting PKI

32. Technical Policy PKI is 1/3 Technical and 2/3 Policy?

33. Attributes for PKI Store them in a Certificate? Attributes persist for life of Certificate No need for Directory or other lookup –The Certificate itself becomes the AuthZ control point Store them in a Directory? Very light-weight Certificates Requires Directory Access Long-term Certificate, Directory is AuthZ control point. How many Certificates will we have? Pseudonymous Certificates

34. Approaches to PKI U.S. Federal Government Purist approach, not considering the directory until end of project Assumes X.500 naming, DC= Rap/Rant Bridge Certification Authority – Feds lead the way! Higher “Edge”ucation It’s all about the applications! This is not just your identity anymore

35. Bridge CAs What we know and love today Vertical or Hierarchical CA paths –Verisign and friends – in the browsers today –Requires there to be a deity in charge (not good) Bridge CA concept is just networking Each CA is like a border router – peering vs. deity Chain of trust path analysis more complex All software in the world needs to change –Browsers, Servers, Services (like path analysis services) This solution is scalable

36. Bridge CA and Trust Paths Verisign CA-ACA-B Bridge CA CA-CCA-D Fed Bridge CA HE

37. Bridge CAs Higher Education Bridge CA – FBCA peering How many HEBCAs? Competing BCA complexity issues? Do we really understand PKI implementations with respect to policy needs? (proxy certificates, relying party agreements, name constraints, FERPA, HIPAA, who eats who?) BCA seems to be the most promising perspective. Will each person be a BCA? All Software (Client/Server) needs to be changed.

38. Authentication: Overall Plan @ Georgetown Currently, Server-Side PKI self-signed Best of all 3 worlds LDAP + Kerberos + PKI –LDAP Authentication performs Kerberos Authentication out the backend. Jan. 2001 to finish iPlanet plug-in. Credential Caching handled by Directory. Cooperative effort – Georgetown, GATech, Michigan –All directory authentications SSL protected. Enforced with necessary exceptions Use Kerberos for Win2K Services and to derive X.509 Client Certificates One Userid/Password (single-signon vs. FSO)

39. Directories are part of the I in PKI Directory (October, 1999 @ Georgetown) Centralized, automated Name Space VERY carefully controlled –Users modify very little –Priv’d access highly restricted Control considered necessary step for PKI to trust the directory Eventually, client, server and other certs/CRLs will be published in the directory.

40. Are Directories part of the I in PKI? Michigan (Kx509), Columbia Short-lived Certificates Avoids CRL and Directory Publications MIT 1 year certs, but people can get all they need using Kerberos Authentication But… A namespace infrastructure is still assumed and they all have it.

41. We’re Building A “Bridge Over The River PKI”

42. Middleware Marketing

43. Drivers of Vapor Convergence JA-SIG uPortal Authen OKI Authentication Shibboleth Inter-Realm AuthZ Local Web SSO Pressures We all get Web SSO for Local Authentication and an Enterprise Authorization Framework with an Integrated Portal that will all work inter-institutionally!

44. Middleware Inputs & Outputs Grids JA-SIG & uPortalOKIInter-realmcalendaring Shibboleth, eduPerson, Affiliated Dirs, etc. EnterpriseDirectoryEnterpriseAuthenticationLegacySystemsCampus Web SSO futures EnterpriseauthZ LicensedResourcesEmbedded App Security