Middleware 201 Directories Configuration

1
Middleware 201DirectoriesConfiguration
Operations

• Michael R. Gettes
• Lead Application Systems Integrator
• Georgetown University
• Gettes_at_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), eduPersonPrincipalNa
  me (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, SubsRP
• PKI Labs (ATT) Neal McBurnett, Avaya
• Wisconsin-Madison Dartmouth
• Industry, Gov., Edu expert guidance
• http//www.educause.edu/hepki

9
Site Profiledcgeorgetown,dcedu

• 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 uidx,oupeople
• DC rap, Boom shacka lacka
• Does UUID in DN really work?
• NSDS pre-op plugin (by gettes_at_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 privd access and maintenance

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 LDAP
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
HoyasOnline Architecture
OS/390
LDAP Master
LDAP Replica
TMS
Other local hosts GU provided self-service
applications
NET ID
HRIS
PCI (Dallas) Vendor-provided services
SIS
Way Down In Texas
WWW hoyasonline Content
Alumni
Gratuitous Architectural Graphic (GAG)
Client Browser
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 doesnt 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).
• Configured for central IMAP/SSL and directory
  services.
• Handles versions of profiles. Poor mans 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 ldapmodify

21
Access ListsDesign Maintenance

• Access lists design maintenance
• Buckley(FERPA) protection services
• Privd users and services
• userPassword SSN
• Maintained by file using ldapmodify
• 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 dont 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
Replica Structure
MAILHOST
WHITEPAGES
Users
MASTER
POSTOFFICE
Users
NetID Registry
DUMPER
Web Servers
Normal Ops
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/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
• cnMichael R Gettes, ouServer Group, ouUIS,
  oGeorgetown University, cUS
• Vs. domainComponent (DC) naming
• uidgettes,ouPeople,dcgeorgetown,dcedu
• 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 dont 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
PKI is 1/3 Technical and 2/3 Policy?
Policy
Technical
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 Edgeucation
• Its 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
Bridge CA
Bridge CA
Verisign
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
AuthenticationOverall Plan _at_ 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 _at_ Georgetown)
• Centralized, automated Name Space
• VERY carefully controlled
• Users modify very little
• Privd 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
Were Building ABridge Over The River PKI
42
Middleware Marketing
43
Drivers of Vapor Convergence
eduPerson 1.0
OKI Authentication
JA-SIG uPortal Authen
44
Middleware Inputs Outputs
Licensed Resources
Embedded App Security
Grids
JA-SIG uPortal
OKI
Inter-realm calendaring
futures
Shibboleth, eduPerson, Affiliated Dirs, etc.
Enterprise authZ
Enterprise Directory
Enterprise Authentication
Legacy Systems
Campus Web SSO