Authentication: Scott Kiester

AUTHENTICATION
SCOTT KIESTER
Authentication Architect
April 2014
Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 1

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

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

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

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

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)

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

CREDENTIAL TYPES – FORM
 Credentials are presented via an HTTP POST

 Browser won’t cache credentials and therefore won’t
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

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
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 isn’t cached
 Credential can’t be forwarded
• Only Key Distribution Center (KDC) knows shared secrets for other
systems
• Use Kerberos Constrained Delegation (KCD) in place of forwarding

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

SURROGATE CREDENTIALS
 A credential that is used in place of the user’s “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

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)

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

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
ORIGIN-COOKIE-REDIRECT MODE
1. GET OCS, check cookie surrogate

2. Redirect to virtual URL
3. GET virtual URL, check cookie surrogate
4. Credential Challenge (401)
5. GET virtual URL (with creds)
6. Set auth cookie, redirect to OCS w/cookie
7. GET OCS w/cookie
8. Set cookie, redirect to OCS
9. GET OCS (authenticated)

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)

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 don’t support authentication
 Disadvantages
• Insecure
• Will not work for multi-user systems (Citrix) or clients behind a NAT
device

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-of-
interest
• Only these groups and attributes can be access-logged

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
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 SG’s machine account object
– SG will attempt to create the machine account if it doesn’t 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
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 other’s machine account passwords

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 server’s machine account credentials
when authenticating users
• Technically, it’s leveraged by system libraries that are invoked by
BCAAA. BCAAA can’t access the credential directly.

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
 SG’s 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

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 user’s 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

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 SG’s/BCAAA server’s domain
• Global groups in the SG’s/BCAAA server’s forest
• Universal groups
 Domain Local groups from foreign domains and global
groups from foreign forests are NOT reported
• General rule: if the group can’t be assigned to an ACL on the BCAAA
box, then it won’t be included
 Nested groups are included
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

NTLM AUTHENTICATION
 Type 3 message is forwarded to DC for validation

 Detailed information at:
http://davenport.sourceforge.net/ntlm.html
Type 1 Message (Workstation capabilities)

NTLMSSP_NEGOTIATE
Type 2 Message (Server capabilities, challenge)

NTLMSSP_CHALLENGE
Type 3 Message (Client credential)

NTLMSSP_AUTH

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
 DC’s Netlogon service validates the credential
 On success, the DC provides:
• The user’s name
• The user’s domain
• Group memberships (SID list)
 Group SIDs are compared against the groups-of-interest
• Authorization is fast and cheap

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

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

CHOOSING A DC: COMMON PROBLEMS
 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 won’t switch DCs until its
Schannel connection is broken (IE: selected DC goes offline).

CHOOSING A DC: COMMON PROBLEMS
 What if the “wrong” DC is selected?

• The DC that responded fastest to the LDAP Ping wasn’t 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

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)

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

MAX CONCURRENT API
 Typical (historical) Schannel behavior only allows one

NTLM request at a time
 Microsoft’s 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

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 – don’t set it too high
• BCAAA won’t use all of the Schannel connections unless
NumThreads is increased
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 - won’t 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 can’t control where the BCAAA server will connect
Schannel

MAX CONCURRENT API
(IWA-DIRECT)
 Max Concurrent API setting can be configured for IWA-

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

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

TRUSTED DOMAINS
 Users from trusted domains may authenticate via IWA

• Domains trusted by the SG’s domain
• Domains trusted by the BCAAA server’s domain
 Cross-forest trusts are also supported
• Users who receive a prompt may have to enter a domain-qualified
username
– …because the user won’t 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”.

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 user’s
domain
• Increased latency
NTLM Request Schannel

scott@trusted.com (NTLM)
IWA-Direct DC
example.com example.com
Schannel
DC (NTLM)
trusted.com
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 isn’t enough

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 isn’t logged in
• …if it can’t do Kerberos
• …if Kerberos has been misconfigured
 Can’t completely replace NTLM, but can minimize its use

KERBEROS
(IWA-DIRECT)
 SG’s 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 SG’s machine account name is “sg”
3. TGS-REQ: HTTP/sg.example.com
4. TGS-REP KDC Shared secret

example.com (Machine account
password)
1. GET ocs.com
2. HTTP 407 (Negotiate)
Explicit proxy: 5. GET ocs.com IWA-Direct
sg.example.com (w/Kerberos credential) example.com
KERBEROS
 Transparent mode:
• Same as explicit mode, but authentication challenge is issued from
the realm’s 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

KERBEROS
 Client caches the service ticket

• 10 hour default lifetime
• Clients also have a “negative” cache to remember when they can’t
get service tickets (so they don’t 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 user’s group memberships change, the SG won’t 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

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
• Can’t 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 – that’s fine if
you only deploy one BCAAA server
SETSPN
 One user may have multiple SPNs assigned

• Fairly common use case
 One SPN may NOT be assigned to multiple users
• KDC won’t know which user’s 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

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-Coat-S
upport-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/custom
er-support-technical-webcasts
(requires BTO login)


Authentication: Scott Kiester

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Authentication: Scott Kiester

Uploaded by

Copyright:

Available Formats

AUTHENTICATION

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 1

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 2

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 3

 Every connection must be authenticated

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 4

 Following a successful authentication, contains information

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

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 5

 Authentication realms represent a specific type of

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 6

 Username and password are base-64 encoded

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 7

 Credentials are presented via an HTTP POST

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 8

 Probably the most commonly used credential type with

 Credential is a “service ticket” that is minted by a Kerberos

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 10

 Client certificate and private key

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 11

 A credential that is used in place of the user’s “real”

 Reduced system load

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 12

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 13

 Authentication modes determine how the user will be

 Explicit proxy only

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 15

 Used with “redirect” authentication modes

1. GET OCS, check cookie surrogate

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 17

 HMAC protects against tampering

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 18

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 19

 Granting or denying users access to resources based on

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 20

 “Native” Windows Authentication

 SG “joins” a Windows domain

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

 The machine account has a password

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 23

 BCAAA typically runs on a member server

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 24

 SGOS 6.4 and later are “multi-tenant”

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 25

 Group names are mapped to SIDs

 An RPC is sent to a DC to do the mapping

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 26

 Windows only tells the realm about the group memberships

 Password authentication protocol

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 28

 Type 3 message is forwarded to DC for validation

Type 1 Message (Workstation capabilities)

Type 2 Message (Server capabilities, challenge)

Type 3 Message (Client credential)

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 29

 NTLM Type 3 credential is sent to the DC via Schannel

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 30

 Schannel throughput is frequently the limiting factor

 Selecting the right DC is important for high-traffic

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 31

 A list of DCs from the local domain is obtained via DNS

Copyright © 2013 Blue Coat Systems Inc. All Rights Reserved. 32

 What if multiple SG/BCAAA boxes choose the same DC?