Middleware 201 Directories Configuration Operations Michael R

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

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

MACE • Middleware Architecture Committee for Ed. • IT Architects – meet often – no particular religious affiliations • MACE-DIR – edu. Person, Recipe, Do. DHE • MACE-SHIBBOLETH – global Auth. N/Z • MACE-PKI HEPKI (TAG/PAG/Labs) • MACE-MED – HIPAA, m. Edu. Person

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

MACE-DIR • Keith Hazelton, Chair, Wisconsin • edu. Person objectclass • LDAP-Recipe • Dir of Dir for Higher Education (Do. DHE) • Shibboleth project dir dependencies • Meta Directories – Architech free to HE • http: //middleware. internet 2. edu/directories

MACE-DIR: edu. Person 1. 0 (1/22/01 release) • MACE initiated (Internet 2 + EDUCAUSE) • Globally interesting useful attributes • Get community buy-in, must use it also • edu. Person. Affiliation (Do. DHE), edu. Person. Principal. Name (Shibboleth) • “Less is more”, how to use standard objectclasses • http: //www. educause. edu/eduperson

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. internet 2. edu/shibboleth

HEPKI • TAG – Technical Activities Group • Jim Jokl, Chair, Virginia • Mobility, Cert Profiles, 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 Mc. Burnett, Avaya • Wisconsin-Madison & Dartmouth • Industry, Gov. , Edu expert guidance • http: //www. educause. edu/hepki

Site Profile dc=georgetown, dc=edu • Netscape/i. Planet DS version 4. 11 • 2 Sun E 250 dual cpu, 512 MB RAM • 75, 000 DNs (25 K 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

Applications • Mail routing with Sendmail 8. 11 (lists also) • Netscape messaging server v 4. 15 (IMAP) • Web. Mail profile stored in LDAP • Apache server for Netscape roaming (no SSL) • Apache & Netscape enterprise web servers • Blackboard Course. Info Version 5 Level 3 • Whitepages: Directory Server Gate. Way • DSGW for priv’d access and maintenance

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

RADIUS + LDAP User calls 202 -555 -1110 NAS (terminal server) Called. Id from NAS is mapped to gu. Rad. Prof RADIUS server LDAP Filter is: gu. Rad. Prof = 2025551110 + Net. ID = gettes Dialup Users Directory Server Netid = gettes gu. Rad. Prof = 2025550001 gu. Rad. Prof = 2025551110 gu. Rad. Prof = Oracle. Fin

Applications (Continued) • Alumni services (Hoyas. Online). • 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!

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

Applications (Continued) • Access+ • Georgetown developed • Web interface to legacy systems using Unix frontend 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? )

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. • Per. LDAP used quite a bit – very powerful! (make sure version >= 1. 4)

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

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

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

Schema: Design & Maint • Unified namespace: there can be only one! • Schema design and maintenance • • • Space/time tradeoffs on indexing Eduperson 1. 0 vs. gu. Person gu. Restrict, gu. Email. Box, gu. Affil, gu. Prim. Afil gu. PWTimebomb, gu. Rad. Prof, gu. Type, gu. SSN Relationships (guref) • Maintained by ldif file using ldapmodify

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

Replication • Application/user performance • Failover, user and app service • Impact of DC= naming (replica init) • Fixed in 4. 13 and i. DS 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 (i. Planet) IBM uses DB 2 under the covers Novell?

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

Replica Structure WHITEPAGES Users MASTER MAILHOST POSTOFFICE Users Web Servers Normal Ops DUMPER Net. ID Registry Failure Ops

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? ? ?

Other Directories • Novell – GU abandoning Group. Wise. • 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…

Directory of Directories • Outgrowth of Georgetown White. Pages 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

LDAP-Recipe • http: //middleware. internet 2. edu Or http: //www. georgetown. edu/giia/internet 2 • DIT, Schema Design, Access Control, Replication, Name population, Good use of LDAP design and features, LDAP configuration, Password Management, edu. Person discussion, Do. DHE expectations

domain. Component (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. domain. Component (DC) naming: uid=gettes, ou=People, dc=georgetown, dc=edu • HEPKI is issuing guidance and advice on DC= naming

Buyer Beware • 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!

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

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

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 Auth. Z control point • Store them in a Directory? • Very light-weight Certificates • Requires Directory Access • Long-term Certificate, Directory is Auth. Z control point. • How many Certificates will we have? • Pseudonymous Certificates

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

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, Services (like path analysis services) • This solution is scalable

Bridge CA and Trust Paths Bridge CA Verisign HE CA-A CA-B Fed CA-C CA-D

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.

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 i. Planet plug-in. • Credential Caching handled by Directory. • Cooperative effort – Georgetown, GATech, Michigan – All directory authentications SSL protected. Enforced with necessary exceptions • Use Kerberos for Win 2 K Services and to derive X. 509 Client Certificates • One Userid/Password (single-signon vs. FSO)

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.

Are Directories part of the I in PKI? • Michigan (Kx 509), 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.

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

Middleware Marketing

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

Middleware Inputs & Outputs Licensed Resources Grids OKI Embedded App Security JA-SIG & u. Portal Inter-realm calendaring Shibboleth, edu. Person, Affiliated Dirs, etc. Campus Web SSO Enterprise Directory Enterprise Authentication Legacy Systems futures Enterprise auth. Z