Sie sind auf Seite 1von 86

BlueCoats Guide to Authentication V1.

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.


Authentication, Authorization Authentication Modes

Explicit mode authentication Transparent mode authentication

Authentication Realms

IWA Window SSO LDAP Novell Radius Local Certificate Substitution

Authentication, Authorization, Accounting


Used on Proxy SG for :

Authenticate device administrators

Can be used to setup authorization rules Configuration modifications logs

Authenticate users surfing to Internet

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


Devices administrators

Two profiles available today :

Read only Read/write

Users surfing to Internet

Can build a policy based on :

Usernames Groups Attributes

Reporting Exceptions tuning

Authentication Modes


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

Type of challenges can be :

Basic NTLM Negotiate (Kerberos)

Blue Coat Terminology

Need to understand differences between proxys deployment mode regarding the authentication mode Proxy can be setup as :

Explicit proxy Transparent proxy

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 can be :

Proxy Origin 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 ProxyAuthorization 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

HTTP 407 are ignored

Cache Authentication Information : Surrogate

Avoid challenging the user agent multiple times



Its the proxys 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

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 Cookie Surrogate







IP Surrogate






Explicit Proxy

Reverse Proxy

Transparent 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 dont need single auth for different servers [Origin/form]-redirect :

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


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

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 doesnt understand redirects, switch to origin including:

Non-HTTP requests Streaming clients (even over HTTP) POST or PUT from browsers that dont support 307 redirects POST or PUT with mime-type multipart/form

If the surrogate credential is set to cookie, but the client doesnt 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. 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


Origin Cookie Redirect : phase 1


Origin Cookie Redirect : phase 2

on a different domain


Origin Cookie Redirect : phase 3

on the same domain


Origin Redirect for explicit proxy

Why ?

Certificate Realm Siteminder Secure credential (HTTPS VU)

Why not ?

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


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

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 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 users credentials are compared to 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, users sessions are never challenged If you clear surrogate cache users will be re challenged 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 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 Posts content to replay it after authentication : request storage


Authentication Realms



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 :

BCAAA : Blue Coat Authentication and Authorization Agent Can be installed on Windows machine or Solaris (4.X) Using an Agent is a Microsofts 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.


No specific needs for users 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 :
Proxy BCAAA Domain Controller


Request No Auth Auth Challenge NTLM Negotiate NTLM Challenge NTLM Response Requested Data NTLM Negotiate Data NTLM Challenge Data NTLM Response Data Auth Confirmation Windows API Call w/NTLM Data Negotiation NTLM Challenge Data Windows API Call w/NTLM Response Data Auth Confirmation


IWA : Kerberos

Kerberos is future Microsofts 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 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 Users 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 :

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 [Debug] DebugLevel=0xffffffff

Advanced logs for BCAAA :


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

Try avoiding kerberos in explicit mode. Multiple Windows domains need bi-directional trust relationships or multiple realms.


Authentication Realms
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 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 : versions 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

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


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


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 All logons are written to a file which restores the state after a restart In 4.2.3, two BCAAAs can synchronize each other Configuration requires editing sso.ini file in the BCAAA install directory



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


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) Does not work with non-Windows or Win 95/98/ME Configuration requires editing sso.ini file in the BCAAA install directory



Windows SSO just provide identification Mechanism doesn't provide groups information Need to use Realms Authorization tab :

Create a LDAP Realm 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.



Need to run BCAAA as a domain user BCAAAs 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 queried


Authentication Realms



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) LDAP config propose 3 default schemes (AD, sun, novell) Nested groups are supported Groups membership can be modified


1. 2. 3.

How it works with SG4: SG challenges the user User sends basic SG connect to LDAP server with search user/anonymous SG searches for the user SG connects with user account SG compares attributes

4. 5. 6.


1. 2. 3.

How it works with SG5: SG challenges the user User sends basic SG connect to LDAP server with search user/anonymous SG searches for the user SG connects with search user account SG compares attributes

4. 5. 6.


How to setup ?

In authentication/LDAP Realm

LDAP version LDAP servers type (AD, Novell, Sun, other) Server ip address LDAP DN LDAP search user 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 information and to test it locally


Authentication Realms
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)


Novell SSO: eDirectory Login

How Novell client logins work

User logs in with the Novell client which updates the eDirectory users 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 login is removed.


Novell SSO: Realm


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


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



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

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)
BCAAA eDirectory Server



Novell SSO: LDAP Realms Relasionship


Create an LDAP realm for each master eDirectory server Create a Novell SSO realm for each of the LDAP realms


each Novell SSO realm points to one LDAP realm


How to setup ?

Specify agent ip and key password if SSL LDAP Edirectory for search req Mapping updates


Authentication Realms



Rarely used No specific configuration Mainly for administrators authentication Can support OTP (One Time Password)

Secure Safeworld, RSA 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


Authentication Realms
Local Authentication


Local Authentication

Proxy SG can use a local user database for

Authentication Authorization

Each Local Realm needs a local-user-list

Users Groups

Local user list provisioning :

Cli commands Scripts

Groups cannot be browsed via VPM


Local User List

One script available :

Perl Script Takes as input a file text and push it to SG via HTTP Text file is .htpassword style :

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


Authentication Realms


Certificate Realm

Use X509 certificates Identify user Can be authorized with :

LDAP Realm 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 certificates serial numbers With external CRL List

List contains revocated certificates

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 Attach the correct server certificate on the service Create a Certificate Realm Install PKI root CA Use a Authorization Realm if needed


Authentication Realms
Policy 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 :

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



Most useful example is hierarchical architecture

Central group based policy Central reporting

Authentication Server Authorization Server

Authorization challenge For username


Lvl1 ProxySG


Lvl2 ProxySG


Authentication Challenge

Get /url X_header : username

Authentication Realms
Sequence 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 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


How to setup ?

Specify realms list :

Iwa first Then ldap Then local

Tolerate errors


Authentication Realms
Guest users


Guest users

Useful to handle :

Guest users Non domain users Wifi subnets Authentication server errors

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


Authentication Realms
Tolerate errors


Errors Handling

SGOS 4 :

if any authentication or authorization errors : Deny

SGOS 5 :

Deny by default Can specify tolerated errors :

Authentication errors Authorization errors

Be carefull on what an error is

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