authentication workshop

BlueCoat’s Guide to Authentication V1.0

Blue Coat ® and the Blue Coat logo are trademarks of Blue Coat Systems, Inc., and may be registered in certain jurisdictions. All other product or service names are the property of their respective owners.

© Blue Coat Systems, Inc. 2007. All Rights Reserved.

Agenda

• Authentication, Authorization

• Authentication Modes

– Explicit mode authentication

– Transparent mode authentication

• Authentication Realms

– IWA

– Window SSO

2

– Window SSO

– LDAP

– Novell

– Radius

– Local

– Certificate

– Substitution

Authentication, Authorization, Accounting

3

Accounting

Authentication

• Used on Proxy SG for :

– Authenticate device administrators

• Can be used to setup authorization rules

• Configuration modifications logs

– Authenticate users surfing to Internet

4

• Used for logging

• Used to build a policy based on users

– Authentication is a two levels architecture :

• Proxy mechanism to challenge the user

• Authentication Realm used to validate credentials

Authorization

• Device’s administrators

– Two profiles available today :

• Read only

• Read/write

• Users surfing to Internet

5

– Can build a policy based on :

• Usernames

• Groups

• Attributes

– Reporting

– Exceptions tuning

6

Authentication Modes

HTTP RFC

• Two HTTP challenges (challenges mode) are available :

– 401 : www-authenticate : authenticate on a resource

– 407 : Proxy-authenticate : proxy asks for auth.

• Credential are replayed by the browser in the same session :

– For the same destination with 401

– For every requests with 407

7

– For every requests with 407

• Type of challenges can be :

– Basic

– NTLM

– Negotiate (Kerberos)

Blue Coat Terminology

• Need to understand differences between proxy’s deployment mode regarding the authentication mode

• Proxy can be setup as :

– Explicit proxy

– Transparent proxy

• Authentication mode can be :

8

• Authentication mode can be :

– Explicit mode : proxy, proxy IP

– Transparent mode : origin (ip/cookie), origine-redirect (ip/cookie), form (origin/cookie), form-redirect (origin/cookie)

• An explicit proxy architecture can use transparent mode authentication (but not really recommended)

Blue Coat Terminology

• Authentication mode syntax :

– Mode-surrogate[-redirect]

• Mode can be :

– Proxy

– Origin

Form

9

– Form

• Surrogate can be :

– IP

– Cookie (session or time based)

• Redirect means the user will be challenged and redirected on the virtual url

Proxy Authentication

• 407 Proxy Authentication Required

– Indicates that the client must first authenticate itself with the proxy

– The proxy MUST return a Proxy-Authenticate header field

– The client MAY repeat the request with a suitable Proxy-

10

– The client MAY repeat the request with a suitable Proxy-Authorization header field

• Cannot be used in transparent deployments

Server Authentication

• 401 Unauthorized

– The request requires user authentication. The response MUST include a WWW-Authenticate header field

– Used for Web Server Authentication

– Authentication cached separately per each resource

Proxy cannot challenge the user agent

11

• Proxy cannot challenge the user agent

– HTTP 407 are ignored

• Cache Authentication Information : Surrogate

– Avoid challenging the user agent multiple times

Surrogate

• It’s the proxy’s way to memorize an already authenticated user.

• Can be used to limit the impact on Authentication architecture in high volume deployment

• TCP session is the default surrogate

• In proxy mode authentication :

Only IP can be used : proxy-IP

12

– Only IP can be used : proxy-IP

• In transparent mode authentication :

– IP

– Cookie

• Session

• Time based

Authentication modes best practice

Proxy Challenge

Origin

Challenge

Form Challenge

Origin Challenge with redirection

Form Challenge with redirection

TCP connection Surrogate

proxyproxy origin - - -

13

Cookie Surrogate

- originorigin--cookiecookie

form-cookie originorigin--cookiecookie--redirectredirect

form-cookie-redirect

IP Surrogate proxy-ip origin-ip form-ip origin-ip-redirect form-ip-redirect

Reverse Proxy Transparent ProxyExplicit Proxy

When to use ?

• Proxy mode : explicit proxy architecture

• Proxy-ip : explicit proxy when SG sees client ip

• Origin/form[ip/cookie] : reverse proxy when you don’t need single auth for different servers

• [Origin/form]-redirect :

14

– transparent proxy auth

– Reverse proxy when single auth needed

– Secure basic credential in proxy mode (AT RISK)

How to setup ?

• Using VPM in authentication layer

– Authenticate

– Force_authenticate

15

Specific modes

• Auto means : proxy chooses the mode depending of the connection type

– Proxy : in explicit mode

– Origin[cookie/ip] : in transparent mode

• SG2 : legacy auto on SG2

16

– Use ip surrogate for IWA proxy mode

Downgrade rules

• Streaming requests are switched to origin challenges ?

• If the challenge type is “origin-redirect”, but the client doesn’t understand redirects, switch to “origin” including:

– Non-HTTP requests

– Streaming clients (even over HTTP)

– POST or PUT from browsers that don’t support 307 redirects

17

– POST or PUT from browsers that don’t support 307 redirects

– POST or PUT with mime-type multipart/form

• If the surrogate credential is set to “cookie”, but the client doesn’t support cookies, downgrade to “ip”

– Non-HTTP requests

– Streaming clients (over HTTP)

The Tricky part : Origin cookie Redirect

• Why : In transparent proxy architecture

• you cannot just use 401 : will challenge every domain

• You cannot just set a cookie : cookie are per resource (host, domain, path)

• You need to globally authenticate your user for all Internet.

18

Internet.

• How :

– redirect a user on a Virtual Url (VU)

– Authenticate the user on the VU

– Redirect the user from the VU

– Use a surrogate to limit performance impacts

How to setup ?

• Global VU setting in Authentication/Transparent

• In Authentication/ Realm/General

Virtual Url

19

Virtual Url

Origin Cookie Redirect : phase 1

20


on a different domain

21


on the same domain

22

Origin Redirect for explicit proxy

• Why ?

– Certificate Realm

– Siteminder

– Secure credential (HTTPS VU)

• Why not ?

23

– Not working with Connect Method (explicit https requests)

– Not working with applets, bots, apps …

– Not working with POST method (limited)

– Need to exclude the VU from browser configuration

Authentication cache

24

Authentication Cache

• Used to limit authentication impact on the architecture

• 3 levels cache (in 5.X, just one cache with 4.X) :

– Credential

– Surrogate

– Authorization

25

• Cache is define per Realm (5.X, global with 4.X)

• Cache time is customizable

• Cache can be flush (in statistics tab with 5.X)

• 4.X has a 80000 entries limit, starting flushing at 20000

Authentication Cache

• Configuration Screenshot

Cache :• credential

26

• credential• surrogate• authorization

Credential cache

• Amount of time basic credentials are memorized

• Basic credentials are login and password asked for basic type of challenges (not NTLM, Kerberos …)

• Default time is 900 secs (15 mins)

• During this period user’s credentials are compared to cached credentials

27

cached credentials

• If password mismatches, proxy will re validate to the server (may be a password change)

• Cached credentials can be forwarded to server (cli command in forwarding sub menue)

Surrogate Cache

• Surrogate is an information identifying an authenticated user

• During the surrogate life time, user’s sessions are never challenged

• If you clear surrogate cache users will be re challenged

Two main surrogates :

28

• Two main surrogates :

– Ip address : source ip seen in the tcp session

– Cookie : cookie set by the proxy

• Cookie mode only available with http (https)

Authorization Cache

• Concerns groups and attributes

• Only available for realms having such notions (ldap for ex)

• Proxy will remember

– Groups information

29

– attributes

Form specific information

• SG can challenge a user with a form instead of 401/407/30x

• Form is an exception

• Form content can be customized

• If user is challenged during a POST request, SG can memorize Post’s content to replay it after authentication :

30

memorize Post’s content to replay it after authentication : request storage

31

IWA

Authentication Realms

IWA

• Stands for Integrated Windows Authenticate

• Leverage on existing Microsoft SSO features

• 3 challenges types available : Basic, NTLM, Negotiate (Kerberos)

• Basic is a fallback method if non windows client

• ProsySG is not part of Windows Architecture !

• We use an agent to relay authentication challenges :

32

– BCAAA : Blue Coat Authentication and Authorization Agent

– Can be installed on Windows machine or Solaris (4.X)

– Using an Agent is a Microsoft’s advise :

Microsoft SSPI:“The Microsoft® Security Support Provider Interface (SSPI) is the well-defined common API for obtaining integrated security services for authentication, message integrity, message privacy, and security quality of service for any distributed application protocol. Application protocol designers can take advantage of this interface to obtain different security services without modification to the protocol itself.”“Microsoft encourages all Win32 application developers to use the integrated security features of SSPI for secure distributed application development.”Microsoft White Paper, The Security Support Provider Interface.

IWA : NTLM

• No specific needs for user’s right running the agent process

• NTLM is a per session authentication mechanism

• No credential cache available (challenges)

• NTLM is a three way challenge (try to use surrogate)

• General Architecture :

Browser Proxy Domain ControllerBCAAA

33

Request – No Auth

Browser Proxy Domain ControllerBCAAA

Auth Challenge

NTLM Negotiate NTLM Negotiate Data Windows API

Call w/NTLM Data Negotiation

NTLM Challenge NTLM Challenge Data NTLM Challenge Data

NTLM Response NTLM Response Data Windows API

Call w/NTLM Response Data

Requested Data Auth Confirmation Auth Confirmation

IWA : Kerberos

• Kerberos is future Microsoft’s SSO norm

• More secure than NTLM ?

• Uses key exchange/ Tickets based on clock

• Use the same BCAAA architecture

• Needs special right to install agent : “act as operating

34

• Needs special right to install agent : “act as operating system”

• Kerberos only works with Transparent mode authentication (redirect)

• Need to register the VU on the DC with setspn command

IWA troubleshooting

• Good luck …

• Try browsing via VPM

• User’s rights for BCAA service (check documentation)

• When using transparent auth modes (for NTLM or by default with kerberos)

– By default web web browser's security only respond to SSO challenges on intranet urls

– Intranet urls are :

35

– Intranet urls are :

• non FQDN urls (ex : intranet)

• IP addresses

• Urls in the intranet security list of IE options

– This behavior can be changed for ie in options tabs

– Can be changed in Firefox in about:config

• Advanced logs for BCAAA :

– [Debug] DebugLevel=0xffffffff

IWA : NTLM & Kerberos caveats

• Verbose protocol , try using surrogate

• Not supported on most non IE apps (except Firefox ?)

• Proxy will log last group matched in policy :

– Group of interest list can be ordered in VPM

– VPM : configuration / set group log order

36

– VPM : configuration / set group log order

• Try avoiding kerberos in explicit mode.

• Multiple Windows domains need bi-directional trust relationships or multiple realms.

37

Windows SSO


Windows SSO

• Windows SSO is not IWA

• Windows Active Directory networks (Novell eDirectory is Novell SSO)

• Available on 4.2.2

• IP address based

38

• Uses BCAAA to acquire mapping of IP address to User name

• User logs into the workstation and then is never challenged

• Works with all protocols

Windows SSO : version’s specific

• Authorization is done with an LDAP query of the FQDN on the AD server

• In 4.2.2, Windows SSO only provided the NetBIOS username and domain

– In most cases customers cannot properly map the NetBIOS name to an AD FQDN

39

name to an AD FQDN

• 4.2.3 provides the FQDN

– Select “Use FQDN” for Authorization

Windows SSO: How it Works

• Two methods are used to determine the user logged onto a workstation

– Domain Controller Querying

– Client Querying

• The methods can be used separately or together

40

Domain Controller Querying

• Domain Controller Querying discovers the domain controllers in the forest

• Each domain controller is then frequently queried for the current set of authenticated connections

• This is used to build up a table of IP addresses to authenticated users

41

authenticated users

Domain Controller Querying II

• Only captures logons, not logouts

• Only captures logons authenticated against a domain controller

• BCAAA must run as a domain user to be able to query Windows 2003 domain controllers

• Data is transient, if BCAAA goes down then new logons are missed

42

missed

• All logons are written to a file which restores the state after a restart

• In 4.2.3, two BCAAA’s can synchronize each other

• Configuration requires editing “sso.ini” file in the BCAAA install directory

– DCQEnabled=1

Client Querying

• Client Querying works by remotely reading the Workstation registry to see who is logged on

• Can solve several of the weaknesses of Domain Controller Querying

• Does not need persistent state or synchronization

43

Client Querying II

• Reading the registry requires BCAAA to run as a domain user

• Windows XP (and greater) firewall blocks registry read requests

• Need to set up a group domain policy to open up the firewall (if it is being used)

44

• Does not work with non-Windows or Win 95/98/ME

• Configuration requires editing “sso.ini” file in the BCAAA install directory

Authorization

• Windows SSO just provide identification

• Mechanism doesn't provide groups information

• Need to use Realm’s Authorization tab :

– Create a LDAP Realm

– Use LDAP for authorization

45

– Use LDAP for authorization

– Need to map username to LDAP FQDN

– Group based policy use Windows SSO Realm

• When defining a group based policy just create a group object from the windows sso realm.

Gotcha’s

• Need to run BCAAA as a domain user

• BCAAA’s domain user should be listed as a service user

• Existing SSL certificate problem

• Windows 2003 SSL privilege problem

• Need to carefully limit which domain controllers are

46

• Need to carefully limit which domain controllers are queried

47

LDAP


LDAP

• We have a nice LDAP client (never been a blocking LDAP scheme)

• LDAP can only use Basic type challenge

• No SSO

• LDAP is not secure between client and proxy unless using origin redirect on https vu (AT RISK)

48

using origin redirect on https vu (AT RISK)

• LDAP config propose 3 default schemes (AD, sun, novell)

• Nested groups are supported

• Groups membership can be modified

LDAP SGOS 4

• How it works with SG4:

1. SG challenges the user

2. User sends basic

3. SG connect to LDAP server with search user/anonymous

49

4. SG searches for the user

5. SG connects with user account

6. SG compares attributes

LDAP SGOS 5

• How it works with SG5:

1. SG challenges the user

2. User sends basic

3. SG connect to LDAP server with search user/anonymous

50

4. SG searches for the user

5. SG connects with search user account

6. SG compares attributes

How to setup ?

• In authentication/LDAP Realm

– LDAP version

– LDAP server’s type(AD, Novell, Sun, other)

– Server ip address

– LDAP DN

– LDAP search user

51

– LDAP user attribute

Known LDAP limitations

• One compare request for all groups and attributes rules matched in policy

• No Regex on attribute (NetCache feature no more on roadmap)

– Attribute.userrigths=“.*1011.*”

– Next LDAP version should permit to retrieve all users

52

– Next LDAP version should permit to retrieve all users information and to test it locally

53

Novell SSO


Novell SSO

• Customers who use Novell eDirectory want a single sign-on (SSO) solution

• Want users to be able to login to Novell client and then be authenticated by the SG without being challenged

• IP address based

Works with BCAAA version 120 (4.2.3)

54

• Works with BCAAA version 120 (4.2.3)

Novell SSO: eDirectory Login

• How Novell client logins work

– User logs in with the Novell client which updates the eDirectory user’s networkAddress attribute with the IP address (and port) that they logged in from

– There is a networkAddress value for each IP address that the user has logged in from

– When a user logs out, the networkAddress value for that

55

– When a user logs out, the networkAddress value for that login is removed.

Novell SSO: Realm

• Authentication:

– BCAAA is used to make LDAP queries on the eDirectory server to map IP addresses to user's FQDNs

– When a user makes a request to the SG, the SG queries BCAAA for the user identity corresponding to the client IP address

• Authorization:

56

• Authorization:

– The Novell SSO realm uses BCAAA to query the eDirectory server via LDAP

– An LDAP realm is used by the Novell SSO realm for eDirectory LDAP config

– Authorization can be performed with the eDirectory server or with separate authorization server

Novell SSO: BCAAA

• BCAAA version 120 (4.2.3)

• BCAAA uses LDAP APIs for Novell SSO

– BCAAA authenticates via an LDAP bind

– Credentials are from the search user defined in the Novell SSO LDAP realm

BCAAA can run as LocalSystem and the machine does not

57

– BCAAA can run as LocalSystem and the machine does not require special trusts

Novell SSO: BCAAA Details

• BCAAA queries the root eDirectory server for all users that are currently logged in (following referrals as necessary)

– The query searches for all users that have a networkAddress attribute

• The search results are then used to create a list of IPs to

58

• The search results are then used to create a list of IPs to user FQDNs

Novell SSO: BCAAA Details

• BCAAA maintains the list in two ways

– Monitors the configured servers for login and logout events

• When an event is received, it adds and removes login entries as appropriate

– Does a full query of the eDirectory server at configurable intervals

• Determine the eDirectory structure

59

– Each separate tree requires a separate Novell SSO realm

– Determine the root server for each tree

• This will be the server for the Novell SSO LDAP search realm

– Determine how the partitions are replicated

• Monitor servers which contain partitions that are not replicated to the root server

Novell SSO: Server Relationships

LDAP Realm(Search and Monitor)

eDirectory ServerBCAAA

60

ProxySG

Users

Novell SSO: LDAP Realms Relasionship

1. Create an LDAP realm for each master eDirectory server

2. Create a Novell SSO realm for each of the LDAP realms

• each Novell SSO realm points to one LDAP realm

61

How to setup ?

• Specify agent ip and key password if SSL

• LDAP Edirectory for search req

• Mapping updates

62

63

Radius


Radius

• Rarely used

• No specific configuration

• Mainly for administrators authentication

• Can support OTP (One Time Password)

– Secure Safeworld, RSA

64

– Only http is supported

– Use form authentication

• No group support

– Need to use attribute : Blue-Coat-Group

– BC Vendor ID: 14501, attribute vendor type: 1

65

Authentication RealmsLocal Authentication

Local Authentication

• Proxy SG can use a local user database for

– Authentication

– Authorization

• Each Local Realm needs a local-user-list

– Users

66

– Groups

• Local user list provisioning :

– Cli commands

– Scripts

• Groups cannot be browsed via VPM

Local User List

• One script available :

– Perl Script

– set_auth.pl

– Takes as input a file text and push it to SG via HTTP

– Text file is .htpassword style :

67

• Login:encrypted_password group1, group2, …

• On user per line

• Password is encrypted UNIX DES or MD5

• Plaintext password < 64 caracters

How to setup

• Local-user-list

• Credentials cache

• VU

68

69

Authentication RealmsCertificate

• Use X509 certificates

• Identify user

• Can be authorized with :

– LDAP Realm

– Local Realm

Certificate Realm

70

– Local Realm

• Certificate cannot be forwarded to OCS

– Specifics information can be fwd in a header

• Installed certificate must be in PEM format

• Need origin style challenge

Revocation List

• Two types of CRL :

– Via policy and certificate’s serial numbers

– With external CRL List

• List contains revocated certificates

71

• OCSP will be available in 5.3

Setup Certificate Realms

• How to setup :

– Origin style challenge

– HTTPS virtual url if redirect used

– HTTPS service with verify-client attribute

– Create/install a server certificate

72

– Attach the correct server certificate on the service

– Create a Certificate Realm

– Install PKI root CA

– Use a Authorization Realm if needed

73

Authentication RealmsPolicy Substitution

Policy Substitution

• When user cannot be challenged !

– Non human client

– No understanding of http challenges

– Cannot prompt for login/pwd

– Hierarchical proxy already authenticated on first level

• 4 mechanisms :

74

• 4 mechanisms :

– NetBIOS

– RDNS

– Header

– Ident

• Can use Authorization Realm

How to setup ?

• In authentication/substitution Realm :

– Specify the policy substitution cpl code

User based on header

75

Substitution

• Most useful example is hierarchical architecture

– Central group based policy

– Central reporting

Authentication Server Authorization Server

76

Lvl1 ProxySG Lvl2 ProxySGInternetWAN

Users

Authorization challengeFor username

Get /urlX_header : username

Authentication Challenge

77

Authentication RealmsSequence Realm

Sequence realm

• Users are in different directories

• Cannot specify a source condition in VPM

• Sequence realm permit to

– Specify multiple realms as a single one

– Challenge once the user

78

– Challenge once the user

– Once basic are received, used them with different servers

• Specific :

– Only 1 IWA (first or last)

– No certificate realm

– Need SGOS 5.2 to tolerate errors

Sequence mechanisms

79

How to setup ?

• Specify realms list :

– Iwa first

– Then ldap

80

– Then local

• Tolerate errors

81

Authentication RealmsGuest users

Guest users

• Useful to handle :

– Guest users

– Non domain users

– Wifi subnets

– Authentication server errors

82

• User can be assigned as a guest

• Guest user can be assigned to a group

• Guest user name is customizable

– Ex: guest_$(c-ip)

How to setup ?

• Creat a VPM authentication layer

• Specify :

– Username

– Realm

83

– Realm

84

Authentication RealmsTolerate errors

Errors Handling

• SGOS 4 :

– if any authentication or authorization errors : Deny

• SGOS 5 :

– Deny by default

– Can specify tolerated errors :

85

• Authentication errors

• Authorization errors

• Be carefull on what an error is

– Cf TD on BCAAA agent unavailable and timeout (process VS network)

authentication workshop

Documents