You are on page 1of 53

AUTHENTICATION

SCOTT KIESTER
Authentication Architect
April 2014

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

AGENDA

Credentials
SG credential cache
Credential types (Basic, NTLM, Kerberos, etc.)
Surrogate credentials
What are they and why use them?

Authentication modes
Virtual URL

IWA
Realms: IWA-Direct / IWA-BCAAA
Joining an Active Directory domain
Group authorization

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

AGENDA

IWA / NTLM
How it works
Potential scalability problems and solutions
New IWA-Direct features in SGOS 6.5.2

IWA / Kerberos
How it works
Why it scales well
Configuration in IWA-BCAAA and IWA-Direct

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

AUTHENTICATION BASICS

Every connection must be authenticated


Each TCP connection from the browser

That can sometimes result in a large volume of


authentication requests
Viewing a single web page usually results in several connections

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

THE CREDENTIAL CACHE

Following a successful authentication, contains information


about the user
Authorization data for CPL (group=, attribute.name=, etc.)
Data for access-logging
Cached credentials (when possible)
Cached for both failed and successful attempts
Stored using secret heap type not included in core dumps

View cache at https://sg:8082/auth/user-logins


Select the appropriate realm
Shows user ID and authorization data
Cached credentials cannot be viewed

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

AUTHENTICATION REALMS

Authentication realms represent a specific type of


authentication to be performed by the SG
IE: LDAP, IWA, Windows SSO, Certificate (X.509), etc.

Realms contain settings that control how the authentication


is performed
External server configuration for some realm types
SSL settings (if applicable for realm type)

Credential cache settings


Virtual URL
More on this during authentication mode discussion

Authorization Data
Group memberships and user attributes
Split authorization (using a different realm for authorization)
Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

CREDENTIAL TYPES BASIC

Username and password are base-64 encoded


Allows for extended characters in usernames and passwords not
intended as a security mechanism
Use SSL!
Supported by most applications that support authentication

Credentials can be forwarded upstream (reverse proxy,


proxy chaining)
Always transmitted in the clear when responding to explicit
proxy challenges (HTTP 407)
True even for HTTPS URLs (HTTP CONNECT message)

Browser will include Basic credentials in every subsequent


request
Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

CREDENTIAL TYPES FORM

Credentials are presented via an HTTP POST


Browser wont cache credentials and therefore wont
include them in every request
Requires the use of a surrogate

Credentials are presented in clear text


Use an HTTPS virtual URL

Form can be customized


Alternative to Basic credentials

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

CREDENTIAL TYPES NTLM

Probably the most commonly used credential type with


SGOS
A hash of the password is sent to the server
The hash is different every time (password is hashed with server
nonce)

Credentials can NOT be cached or forwarded


because the hash is different every time

More secure than Basic


Least scalable credential type (more on that later)
Especially true with proxy mode (explicit proxy)
Credential must be sent to the authentication authority for verification
each time
Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

CREDENTIAL TYPES KERBEROS

Credential is a service ticket that is minted by a Kerberos


KDC (Key Distribution Center)
Encrypted with a secret shared between the SG and the KDC
Contains the user ID and AD group memberships

Better scalability than NTLM


Credential can be validated locally

Credential isnt cached


Credential cant be forwarded
Only Key Distribution Center (KDC) knows shared secrets for other
systems
Use Kerberos Constrained Delegation (KCD) in place of forwarding

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

10

CREDENTIAL TYPES X.509

Client certificate and private key


Client MUST hold the private key

Certificate realm relies on SSL-Mutual


Connection must be SSL
Typical use case is a realm configured with an HTTPS virtual URL that
terminates at an HTTP Reverse Proxy Service on the SG

Credential (client certificate) is verified during the SSL handshake


Realm retrieves the username from the client certificate

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

11

SURROGATE CREDENTIALS

A credential that is used in place of the users real


credential
Client IP address
Cookie
HMAC prevents tampering
Does NOT contain user credentials

Reduced system load


Validated on the SG no need to query the backend authentication
authority

Lifetime is configurable

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

12

EXPLICIT AND TRANSPARENT PROXY

Explicit Proxy
The SG issues proxy challenges (HTTP 407)
Browser may initiate 10 or more concurrent connections to the proxy
server
The SG must authenticate every connection

SSL connections start with an HTTP CONNECT message

Transparent Proxy
The SG issues origin-style challenges (HTTP 401)

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

13

AUTHENTICATION MODES

Authentication modes determine how the user will be


authenticated

401 or 407 (transparent or proxy-style challenge)


Credential type (form vs Basic, NTLM vs Kerberos)
Surrogate credential type (cookie, IP, none)
Whether or not the client will be redirected

Mode types:
Origin / Form
Can be used with transparent or explicit clients

Proxy
Explicit clients only

IP (IP surrogate)
Cookie (cookie surrogate)
Redirect (redirect to virtual URL for credential challenge)
Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

14

PROXY MODE

Explicit proxy only


Default mode for explicit proxy
SG issues a 407 challenge on each connection
If credentials are not in the cache, authentication authority must be
contacted
Proxy mode + NTLM = poor scalability

Basic credentials will cross the wire in the clear


Even when URL is HTTPS (HTTP CONNECT message)

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

15

VIRTUAL URL

Used with redirect authentication modes


origin-[cookie|IP]-redirect
form-[cookie|IP]-redirect

Terminates at the SG, or is silently intercepted by the SG


Common storage location for the cookie surrogate (cookie
domain)
Used for credential challenges
Important detail for Kerberos and for preventing NTLM pop-ups

Can be HTTPS
Use an HTTPS Reverse Proxy service
Protects Basic credentials
Certificate realms MUST use an HTTPS virtual URL
Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

16

ORIGIN-COOKIE-REDIRECT MODE

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

17

COOKIE SURROGATE

HMAC protects against tampering


Tied to client IP by default
Does NOT contain user credentials or sensitive data
SG looks up data in the authentication cache

Cookies issued by one SG cannot be consumed by another


SG
Cookies from different SGs will not conflict with each other

BCSI-AC-<<SG serial number>>


Session cookie surrogate (default)

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

18

IP SURROGATE

Authentication Modes
Proxy-IP, [origin|form]-IP, [origin|form]-IP-redirect

SG checks client IP against authentication cache


Advantages
Fast, scales well
Useful for authenticating non-intercepted SSL connections, or apps
that dont support authentication

Disadvantages
Insecure
Will not work for multi-user systems (Citrix) or clients behind a NAT
device

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

19

AUTHORIZATION

Granting or denying users access to resources based on


their identity
CPL: user=, group=, attribute.<name>=
Groups-of-interest
Attributes-of-interest

Different realms provide different types of authorization


data
IWA: Groups
LDAP, RADIUS, SAML: Groups and attributes

Realms only report on groups-of-interest and attributes-ofinterest


Only these groups and attributes can be access-logged
Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

20

IWA

Native Windows Authentication


Authenticate against Active Directory (AD)

Most used authentication type


IWA-Direct
SG joins an Active Directory (AD) domain and communicates
directly with Domain Controllers

IWA-BCAAA
SG talks to a service running on a Windows server, which relies on
Windows API calls to validate credentials

Support is built-in to most major browsers


Basic/NTLM/Kerberos
NTLM is used most often
Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

21

IWA-DIRECT

SG joins a Windows domain


SG creates a machine account object in the domain
Domain join requires credentials with an account that will perform the
join
If the machine account already exists, the joining account must have write
rights to the SGs machine account object
SG will attempt to create the machine account if it doesnt exist
Once the join is finished, the SG discards the joining credentials

SG needs to resolve AD names in DNS. DNS must be


configured, or domain join will fail
Configure redundant DNS servers
Use of DNS group is encouraged
IE: Send all requests for your.ad.domain.com directly to a server for that
zone
Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

22

MACHINE ACCOUNT
(IWA-DIRECT)
The machine account has a password
Randomly-generated by the SG and sent to the DC in an encrypted
RPC
The SG logs in to the DCs using its machine account credential
Password is stored encrypted on the SG
SG silently changes the password every 15 days

Do NOT join multiple SGs to the domain using the same


name
They will overwrite each others machine account passwords

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

23

MACHINE ACCOUNT
(IWA-BCAAA)
BCAAA typically runs on a member server
It can also run on a DC, but consider the security implications of
running a network service on a DC

Member servers (and workstations) have machine accounts


in AD
Member servers periodically change their machine account
passwords
just like an SG running IWA-Direct

BCAAA leverages the servers machine account credentials


when authenticating users
Technically, its leveraged by system libraries that are invoked by
BCAAA. BCAAA cant access the credential directly.
Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

24

MULTI-TENANCY
(IWA-DIRECT)
SGOS 6.4 and later are multi-tenant
meaning that the SG may join more than one AD domain at the
same time
This feature is NOT required to authenticate users from trusted
domains

SGs machine account name is the same in each domain


that it joins
Each IWA-Direct authentication realm is associated with a
domain that the SG has joined
Multiple realms can be associated with the same domain

Useful if you need to authenticate users from different


domains that have no trust relationship
Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

25

GROUPS-OF-INTEREST

Group names are mapped to SIDs


SID = Security Identifier
A unique identifier for a Windows account like a UNIX UID or GID, but
also identifies the domain of the account

An RPC is sent to a DC to do the mapping


Each users group memberships are automatically provided
to IWA-Direct/IWA-BCAAA after successful authentication
Group SIDs are provided, instead of names
SIDs are compared against the group-of-interest SIDs that were
obtained during initialization

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

26

GROUP MEMBERSHIPS

Windows only tells the realm about the group memberships


that it thinks the realm needs for authorization decisions
A Windows access token holds a maximum of 1024 group
memberships

Windows reports memberships in:


Domain Local groups in the SGs/BCAAA servers domain
Global groups in the SGs/BCAAA servers forest
Universal groups

Domain Local groups from foreign domains and global


groups from foreign forests are NOT reported
General rule: if the group cant be assigned to an ACL on the BCAAA
box, then it wont be included

Nested groups are included


Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

27

NTLM

Password authentication protocol


Generally does not scale as well as other password
authentication methods
NTLM credential cannot be cached

Credential must be validated by a Domain Controller (DC)


This can be a performance bottleneck

Sensitive information does not cross the wire


Client credential is hashed with client and server random data

Requires two round trips between client and SG

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

28

NTLM AUTHENTICATION

Type 3 message is forwarded to DC for validation


Detailed information at:
http://davenport.sourceforge.net/ntlm.html

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

29

NETLOGON / SCHANNEL

NTLM Type 3 credential is sent to the DC via Schannel


Schannel connection is authenticated using the machine account
Credentials are sent via encrypted RPC

DCs Netlogon service validates the credential


On success, the DC provides:
The users name
The users domain
Group memberships (SID list)

Group SIDs are compared against the groups-of-interest


Authorization is fast and cheap

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

30

NTLM THROUGHPUT

Schannel throughput is frequently the limiting factor


Historically, Windows default configuration has been to
process only one request at a time via Schannel
Sometimes referred to as Netlogon bottleneck

Problems can be made worse by:


High SG-to-DC or BCAAA-to-DC network latency
A DC that is already overloaded
Especially if that DC is processing Schannel requests on behalf of another
SG, BCAAA server, or some other authenticating service (IIS, TMG, etc.)

Selecting the right DC is important for high-traffic


environments

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

31

CHOOSING A DC
(IWA-DIRECT / IWA-BCAAA)
A list of DCs from the local domain is obtained via DNS
The server issues an LDAP Ping to the DCs and selects
the first one to respond
An LDAP Ping is a small LDAP-over-UDP packet that is sent to see if
the DC is alive

The server establishes an authenticated SMB connection


with the selected DC
This is the Schannel connection
Connection is authenticated using the machine credentials

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

32

CHOOSING A DC: COMMON PROBLEMS


(IWA-DIRECT / IWA-BCAAA)
What if multiple SG/BCAAA boxes choose the same DC?
No built-in mechanism to prevent that

What if the fastest DC is offline, and comes back online


right after a DC is selected?
The SG/BCAAA server will connect Schannel to the selected DC,
ignoring the DC that just came online. It wont switch DCs until its
Schannel connection is broken (IE: selected DC goes offline).

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

33

CHOOSING A DC: COMMON PROBLEMS


(IWA-DIRECT / IWA-BCAAA)
What if the wrong DC is selected?
The DC that responded fastest to the LDAP Ping wasnt the fastest
overall
Schannel response time might be slower than some other DC(s)

Can I control which DC is chosen?


BCAAA: Windows resource kit has nltest.exe, but the results are not
sticky

IWA-Direct
Solution provided in SGOS 6.5.2

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

34

PREFERRED / ALTERNATE DC
(IWA-DIRECT)
Specify preferred and alternate DCs in Windows
Domain configuration (6.5.2 and later)
Those names were chosen to avoid confusion with Primary Domain
Controller and Backup Domain Controller

SG will always connect Schannel to the preferred DC, even


if a faster DC is available
If the preferred DC goes offline, the SG will connect to the
alternate
If both the preferred and alternate are offline, the SG will fall
back to the old behavior (LDAP Ping)

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

35

PREFERRED / ALTERNATE DC
(IWA-DIRECT)
A background thread checks to see when the preferred DC
comes back online, and automatically switches over
Allows each SG in a datacenter to use its own, dedicated
DC
Prevent the SGs from all connecting to the same DC

Only applies to Schannel communication


Other RPCs, LDAP traffic, Kerberos traffic may go to different DCs

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

36

MAX CONCURRENT API

Typical (historical) Schannel behavior only allows one


NTLM request at a time
Microsofts solution: MaxConcurrentAPI
Detailed explanation here:
https://
blogs.technet.com/b/ad/archive/2008/09/23/ntlm-and-maxconcurrentapi-conc
erns.aspx

Value that is configured in the registry

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

37

MAX CONCURRENT API


(IWA-BCAAA)
Registry value must be configured on the BCAAA server
and on the DCs
On the BCAAA server:
Controls the number of concurrent Schannel connections that will be
opened to the DC
Each Schannel connection can only process one request at a time

On the DC:
Controls the number of threads in the Netlogon service that process
NTLM requests

Also must increase NumThreads= parameter in bcaaa.ini


Value impacts all realms dont set it too high
BCAAA wont use all of the Schannel connections unless
NumThreads is increased
Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

38

MAX CONCURRENT API


(IWA-BCAAA)
What if I increase MaxConcurrentAPI on BCAAA, but NOT
on the DC?
BCAAA will establish multiple Schannel connections to the DC, but
the DC will only process one authentication request at a time
Requests will block at the DC - wont help performance much

For best results, MaxConcurrentAPI must be increased on


each DC in the site and/or domain of the BCAAA server
because we cant control where the BCAAA server will connect
Schannel

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

39

MAX CONCURRENT API


(IWA-DIRECT)
Max Concurrent API setting can be configured for IWADirect (6.5.2 and later)
Maximum number of concurrent Schannel connections setting in
Windows Domain configuration

Minimum is 2, maximum is 150


Win2k8 R2 and later support up to 150
Win2k8 R1 and earlier support up to 10

Use in conjunction with preferred/alternate DC feature to


avoid having to set MaxConcurrentAPI on every DC in the
domain

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

40

READ-ONLY DC (RODC)

DC that holds a read-only copy of an AD partition


AD administrator defines a password replication policy
Controls which user passwords the RODC is allowed to cache

Requests from users without cached passwords will be


forwarded to a writeable DC
Performance penalty

IWA-BCAAA supports RODCs


IWA-Direct 6.5.2 will connect to RODCs only if they are
specified as the preferred or alternate DC

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

41

TRUSTED DOMAINS

Users from trusted domains may authenticate via IWA


Domains trusted by the SGs domain
Domains trusted by the BCAAA servers domain

Cross-forest trusts are also supported


Users who receive a prompt may have to enter a domain-qualified
username
because the user wont be in the Global Catalog (GC) of the local forest
Domain-qualified name is provided automatically when the browser submits
cached credentials from workstation logon. Those cases just work.

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

42

NTLM / TRUSTED DOMAIN

SG/BCAAA always connects Schannel to a DC from the


local domain
The local DC forwards credentials to a DC from the users
domain
Increased latency

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

43

KERBEROS

Better scalability than NTLM


Single round-trip
Credentials are validated without contacting a DC
No Schannel (Netlogon) bottleneck

No performance penalty for trusted domains

Requires extra configuration


Just checking the Kerberos box in an IWA realm isnt enough

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

44

KERBEROS

User credential is a service ticket


Service ticket is encrypted with a secret shared between the
SG/BCAAA and the KDC (Key Distribution Center)

Client obtains the service ticket from the KDC


Client is contacting the DC, rather than the SG/BCAAA
Wireshark: TGS-REQ / TGS-REP

Client silently falls back to NTLM


if a domain user isnt logged in
if it cant do Kerberos
if Kerberos has been misconfigured

Cant completely replace NTLM, but can minimize its use

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

45

KERBEROS
(IWA-DIRECT)
SGs Service Principal Name (SPN) must resolve in DNS
The SPN in this example is HTTP/sg.example.com. The hostname
portion (sg.example.com) must resolve in DNS.

The SGs machine account name is sg

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

46

KERBEROS

Transparent mode:
Same as explicit mode, but authentication challenge is issued from
the realms virtual URL
In the example on the previous slide, virtual URL would be
sg.example.com

Must specify a hostname


for the proxy server in explicit mode
for the virtual URL in transparent mode
Will not work if you specify an IP address

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

47

KERBEROS

Client caches the service ticket


10 hour default lifetime
Clients also have a negative cache to remember when they cant
get service tickets (so they dont waste time on another attempt)

Service ticket contains group memberships


Authorization is fast and cheap
Group SIDs are included the Privilege Attribute Certificate (PAC)
If users group memberships change, the SG wont know until the
user gets a new service ticket

To clear the ticket cache


Use krbtray.exe (from the Windows resource kit)
Log out of Windows and log back in
Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

48

KERBEROS
(IWA-BCAAA)
BCAAA service must be configured to run under a
designated Kerberos user account
The account therefore needs the log on as a service privilege on
the BCAAA server
If running BCAAA 6.1 or later log on as a service is the only special
privilege that is required
No more need for act as part of the operating system

Use Windows setspn utility (see next slide) to associate


an SPN with the Kerberos user
Cant have primary and alternate BCAAA servers unless you use the
setspn approach
...because both BCAAA servers need to share a single SPN
SGOS admin guide also talks about using the machine name thats fine if
you only deploy one BCAAA server
Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

49

SETSPN

One user may have multiple SPNs assigned


Fairly common use case

One SPN may NOT be assigned to multiple users


KDC wont know which users password to use, so it will simply fail
the request
Clients will silently fall back to NTLM. KDC will write an error
message to its event log.
Use setspn X to search for duplicate SPNs

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

50

BLUE COAT CUSTOMER FORUMS

New Blue Coat Customer Forums now available


Community where you can learn from and share your valuable
knowledge and experience with other Blue Coat customers
Please visit the Customer Forums pages at
https://forums.bluecoat.com/forumdisplay.php?133-Blue-CoatSupport-Videos
to view three new Knowledge Assets / Support Videos on
ProxySG Authentication.
Research, post and reply to topics relevant to you at your own
convenience
Blue Coat Moderator Team ready to offer guidance, answer
questions, and help get you on the right track
Access at forums.bluecoat.com and register for an account
today!
Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

51

THANK YOU FOR JOINING TODAY!

Please provide feedback on this webcast and suggestions


for future webcasts to:

supportnewsletter@bluecoat.com

Webcast replay and


slide deck found here:
https://bto.bluecoat.com/training/custo
mer-support-technical-webcasts
(requires BTO login)

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

52

Copyright 2013 Blue Coat Systems Inc. All Rights Reserved.

53

You might also like