Transcript Middleware 201 Directories Configuration & Operations Internet2 Member Meeting

Middleware 201
Directories
Configuration & Operations
Michael R. Gettes
Lead Application Systems Integrator
Georgetown University
[email protected]
Internet2 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 – eduPerson, Recipe, DoDHE
•MACE-SHIBBOLETH – global AuthN/Z
•MACE-PKI  HEPKI (TAG/PAG/Labs)
•MACE-MED – HIPAA, mEduPerson
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
• 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
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
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
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
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 [email protected])
•
•
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)
•
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 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)
CalledId from
NAS is mapped
to guRadProf
RADIUS server
LDAP Filter is:
guRadProf =
2025551110
+ NetID = gettes
Dialup
Users
Directory
Server
Netid = gettes
guRadProf = 2025550001
guRadProf = 2025551110
guRadProf = OracleFin
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!
HoyasOnline Architecture
OS/390
LDAP Master
TMS
LDAP
Replica
Other local hosts
HRIS
NET ID
PCI (Dallas)
GU provided self-
service applications
SIS
WWW
Alumni
Gratuitous
Architectural
Graphic (GAG)
hoyasonline
Content
Client
Browser
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.
• PerLDAP 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, win2k/ad integration?,
Oracle RADIUS integration, Automatic
lists, Dynamic/static Groups, TopSecret, 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!
• 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
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. guPerson
guRestrict, guEmailBox, guAffil, guPrimAfil
guPWTimebomb, guRadProf, guType, guSSN
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
• 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
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?
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
NetID 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 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…
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
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
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
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!
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 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
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, Servers, Services (like path analysis
services)
• This solution is scalable
Bridge CA and Trust Paths
Bridge CA
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
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)
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 (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.
We’re Building A
“Bridge Over The River PKI”
Middleware Marketing
Drivers of Vapor
Convergence
Shibboleth Inter-Realm AuthZ We all get Web SSO for
Local Authentication and
OKI Authentication
an Enterprise Authorization
Framework with an
Integrated Portal that will
JA-SIG uPortal Authen
all work inter-institutionally!
Local Web SSO Pressures
Middleware Inputs & Outputs
Licensed
Resources
Grids
OKI
Embedded
App Security
JA-SIG &
uPortal
Inter-realm
calendaring
Shibboleth, eduPerson, Affiliated Dirs, etc.
Campus
Web SSO
Enterprise
Directory
Enterprise
Authentication
Legacy
Systems
futures
Enterprise
authZ