Enterprise Authentication

558 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
558
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Enterprise Authentication

  1. 1. Enterprise Authentication Jason Testart, IST
  2. 2. (Some of) Jason Testart’s Frustrations 1. Wondering if the UW-WIRELESS network you’re connected to, typing-in your password, is the real thing. 2. Needing to type ADS credentials N times a day. 3. Students getting confused between NEXUS and ADS accounts. WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  3. 3. WIFI PARANOIA Frustration #1 WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  4. 4. Why do we have information security controls?  Maintain the confidentiality of information.  Maintain the integrity of information.  Maintain the availability of information. WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  5. 5. What does wifi access have anything do to with protecting information?  We want to know who’s on our network.  Where do we direct complaints of abuse? WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  6. 6. BUT, we have problems…  Guest access  WatIAM  Service  Password theft (irony?)  Off the wire  Off of a stolen mobile device? WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  7. 7. Solving the problem with NetID?  Exclusively for wireless.  Can be cached on the mobile device.  Staff, faculty, and students can sponsor NetIDs.  NetID userid/password are generated (no user choice).  NetIDs have expiry dates.  WatIAM account deletion triggers deletion of sponsored NetIDs. WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  8. 8. NetID benefits  It’s always cached, so no need to type in credentials for wifi access.  Compromised NetID credentials do not result in further information breach.  Sponsors get self-serve interface to manage NetIDs. WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication https://strobe.uwaterloo.ca/~twiki/bin/view/ISTITSec/NetIDConcept
  9. 9. NetID Risks & Constraints  Need to build infrastructure.  Need to maintain infrastructure.  Integration with WatIAM.  Success of uw-guest pilot.  Using ‘uw-guest’ for guests.  Using X.509 certificates for UW people. WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  10. 10. TOO MUCH TYPING Frustration #2 WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  11. 11. Single Sign-On (SSO)  A collection of services have a trust relationship with an authentication service.  User authenticates once in a session.  No need to authenticate to any other services for the remainder of the session.  Session has a fixed lifetime, usually set by the authentication service administrator. WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  12. 12. Simplified SSO Operation WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication Service User Agent Authentication Service User attempts to access a service. Service re-directs the user to authentication service. User authenticates. Authentication service issues a re-usable token to the user agent. User agent presents the token to the service. Service verifies the token. User is authenticated to the service. START HERE
  13. 13. SSO Enablers  Kerberos  CAS  SAML WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  14. 14. Kerberos  Uses a ticket-granting ticket (TGT).  TGT is used to get service tickets.  An Active Directory domain is a Kerberos realm.  Domain and Forest trusts enable SSO across domain boundaries. WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  15. 15. What you need for Kerberos  NTP  Need to “join” host to the AD domain  Configure host to authenticate to AD domain  Need to manage accounts  Local  Remote (LDAP)  Think about home directories  CIFS is usually the default  NFSv3 should work – mind your UIDs & GIDs on *nix WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  16. 16. Taking advantage of Kerberos  SASL  GSSAPI  NEGOTIATE (web)  /etc/ssh/sshd_config (Unix/Linux/OS X) WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication GSSAPIAuthentication yes GSSAPICleanupCredentials yes UsePAM yes
  17. 17. CAS  Central (Web) Authentication Service  Uses cookies as tokens  Service agents vary  Apache module  ISAPI filter for IIS  Modules in a variety of languages  IST has a CAS server. Used by:  MyPensionInfo  Marmoset (automated CS assignment marking)  Wireless blacklist management WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  18. 18. kiwi  A central web authentication service  Developed by CPA in Ruby on Rails  Limited ability to support  Similar functionality and operation as CAS  Used by student orgs, CPA apps  Hope to retire kiwi in 2010 WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  19. 19. Limitations of Kerberos/CAS  Solve the authentication problem  What about authorization? WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  20. 20. SAML (2.0)  Security Assertion Markup Language  Identity Providers  Service Providers  XML messages passed back and forth  Messages contain authentication and authorization data WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  21. 21. Moving forward  New Year’s resolution: Move to CAS!  Our server: cas.uwaterloo.ca  Good documentation at: http://wiki.case.edu/Central_Authentication_Service  Long term: Investigate OpenSSO from Sun  SAML 2.0  Supports multiple authentication domains  Supports multiple authentication protocols  Centralized authorization (policy based on URL)  Works with CAS; nice migration path? WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  22. 22. What you might not know about PHP & Apache…  .htaccess protected php page  Apache caches the credentials it collects  Clear-text password is available in the environment  Just print $_ENV["PHP_AUTH_PW"]  Mitigation techniques  Disable registration of $_SERVER – makes authorization in the application impossible  unset PHP_AUTH_PW in an auto_prepend_file – it’s ugly  Use an SSO-capable central authentication service!  USE CAS! WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  23. 23. At least use https! WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication AuthType Basic AuthName "UWdir Authentication" PerlSetVar AuthenURL_method HEAD PerlSetVar AuthenURL_url http://[CENSORED] PerlSetVar AuthenCache_cache_time 3600 PerlSetVar AuthenDBMCache_TTL 3600
  24. 24. LANMAN MUST DIE!  Maximum password length of 14 characters  Passwords limited to ANSI character set  Passwords are case in-sensitive  Many servers on campus still use it to authenticate to ADS (and other places?)  LANMAN hashes are still computed in ADS WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  25. 25. This config needs to go… WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication AuthName UWDir AuthType Basic PerlAuthenHandler Apache::AuthenSmb PerlSetVar myDomain ads.uwaterloo.ca PerlSetVar myPDC douglasfir PerlSetVar myPDC oak SSLRequireSSL
  26. 26. TOO MANY PASSWORDS! Frustration #3 WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  27. 27. Supporting UW’s mission  Teaching & research environments are more exposed to threats, by design.  Teaching & research environments demand more flexibility, rapid change.  Administrative environments demand stability. WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  28. 28. History of ADS & NEXUS  Concept of high security vs. low security passwords  One domain has more “sensitive” data than the other?  Things are fuzzy! WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  29. 29. Policy 8 – Information Security  Classifies information based on risk  Reflects legislation and regulation  FIPPA  PHIPA  Defense Production Act  PCI DSS WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  30. 30. Data Classification WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication Confidential Restricted Highly Restricted Public
  31. 31. Data Classification Examples Confidential Restricted Highly Restricted • Steward decides • Marks/Assignments • Health Information • SIN • Health Card number WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  32. 32. We want…  Strong access controls for information more ‘restricted’ than other information  Stronger passwords  Tighter network firewall policies  More monitoring (IDS/IPS)  Stronger remote access policies WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  33. 33. Observations  Students’ interface to institutional apps is a web browser  Faculty members revolve in and out of administrative posts  Most staff at UW handle ‘Restricted’ data, but very few handle ‘Highly Restricted’ data.  An Active Directory security boundary is a forest.  Virtualization is taking off, eh? WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  34. 34. The Future of Active Directory at UW  CTSC initiated consolidation & governance project.  Request for comments/functional requirements.  Due mid-January 2010 to bruce and erick. WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  35. 35. WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication AD Thoughts From a security perspective…
  36. 36. Thought #1  One campus AD domain for all labs and offices  Use OUs for enforcing different policies  Separate AD single-domain forest:  Contains servers with applications hosting ‘Highly Restricted’ data.  Departments that need desktop access to ‘Highly Restricted’ information use RDP or some kind of desktop virtualization  Applications use ‘main’ domain to authenticate students WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  37. 37. Thought #2  One AD forest for students  One AD forest for employees  ‘student forest’ trusts ‘employee forest’ (one-way)  Authentication of staff for enterprise web apps might be tricky  OpenSSO might help  Teach employees to login with email address? (UPN works across forest boundaries, right?) WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  38. 38. More thinking is needed  Security vs. Usability?  Is having multiple accounts for staff better than multiple accounts for students?  Security vs. Maintainability?  Two forests to manage: Is this a problem?  Security & Governance  Functional requirements clash with security requirements? WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  39. 39. Your Tasks  Move to CAS.  Think about your authorization requirements.  Think about your Active Directory requirements. WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication
  40. 40. THANK YOU FOR YOUR TIME! May you find value in all of the talks you attend (especially this one). WatITis | Strengthening Collaboration | December 8, 2009 | Enterprise Authentication

×