Enterprise Authentication

Enterprise Authentication

Jason Testart, IST

(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

WIFI PARANOIAFrustration #1


Why do we have information security controls?

Maintain the confidentiality of information. Maintain the integrity of information. Maintain the availability of information.


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?


BUT, we have problems…

Guest access WatIAM Service

Password theft (irony?) Off the wire Off of a stolen mobile device?


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.


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.


https://strobe.uwaterloo.ca/~twiki/bin/view/ISTITSec/NetIDConcept



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.


TOO MUCH TYPINGFrustration #2


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.


Simplified SSO Operation


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

SSO Enablers

Kerberos CAS SAML


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.


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


Taking advantage of Kerberos

SASL GSSAPI NEGOTIATE (web) /etc/ssh/sshd_config (Unix/Linux/OS X)


GSSAPIAuthentication yesGSSAPICleanupCredentials yesUsePAM yes

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


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


Limitations of Kerberos/CAS

Solve the authentication problem What about authorization?


SAML (2.0)

Security Assertion Markup Language Identity Providers Service Providers XML messages passed back and forth Messages contain authentication and authorization

data


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?


http://wiki.case.edu/Central_Authentication_Service

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!


At least use https!


AuthType Basic AuthName "UWdir Authentication" PerlSetVar AuthenURL_method HEAD PerlSetVar AuthenURL_url http://[CENSORED]PerlSetVar AuthenCache_cache_time 3600 PerlSetVar AuthenDBMCache_TTL 3600

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


This config needs to go…


AuthName UWDir AuthType Basic PerlAuthenHandler Apache::AuthenSmb PerlSetVar myDomain ads.uwaterloo.ca PerlSetVar myPDC douglasfir PerlSetVar myPDC oak SSLRequireSSL

TOO MANY PASSWORDS!Frustration #3


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.


History of ADS & NEXUS

Concept of high security vs. low security passwords One domain has more “sensitive” data than the

other? Things are fuzzy!


Policy 8 – Information Security

Classifies information based on risk Reflects legislation and regulation

FIPPA PHIPA Defense Production Act PCI DSS


Data Classification


Confidential

Restricted

Highly Restricted

Public

Data Classification Examples

Confidential

Restricted

Highly Restricted

• Steward decides

• Marks/Assignments• Health Information

• SIN• Health Card number


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


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?


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.



AD Thoughts

From a security perspective…

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


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


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?


Your Tasks

Move to CAS. Think about your authorization requirements. Think about your Active Directory requirements.


THANK YOU FOR YOUR TIME!

May you find value in all of the talks you attend (especially this one).


Documents

Enterprise Authentication