Security
Empowers
Business
TECHNICAL BRIEF
IWA AUTHENTICATION FUNDAMENTALS AND
DEPLOYMENT GUIDELINES
INTRODUCTION
The purpose of this document is to explain how Integrated Windows Authentication (IWA) works with the ProxySG
appliance, to explain differences between the two realms (IWA-BCAAA and IWA-Direct), and to provide guidelines
for deployments and sizing.
Table of Contents
INTRODUCTION1
HOW IT WORKS
2
Integrated Windows Authentication Overview
2
NTLM - Quick Overview
2
Kerberos - Detailed Overview
2
Obtaining Group Membership Information
4
Domain Controller Selection Mechanism
4
IWA-BCAAA5
NTLM5
Kerberos5
IWA-BCAAA: Service User Permission Requirements
6
IWA-DIRECT6
NTLM6
Kerberos7
IWA-Direct: User Permission Requirements for Joining a Windows Domain
7
PERFORMANCE7
NTLM vs. KERBEROS
7
NETLOGON / MAXCONCURRENTAPI Tuning Options
8
IWA-Direct8
IWA-BCAAA8
SURROGATES (IP, COOKIE)
9
Proxy-IP Surrogates
9
Cookie Surrogates
10
IWA Performance Numbers
10
Authentications per Second
10
Throughput Differences
10
How We Measure These Numbers
11
BCAAA Server Sizing
11
RECOMMENDATIONS11
ABOUT TECHNICAL BRIEFS
11
1
TECHNICAL BRIEF
Security
Empowers
Business
How It Works
›› Two round trips are required between the client and BCAAA.
Integrated Windows Authentication Overview
›› The ProxySG appliance or BCAAA – depending on the realm – have
to contact a DC (through Netlogon) on the final round-trip.
Integrated Windows Authentication (IWA) can provide a single sign
on (SSO) user experience when configured correctly. Blue Coat has
implemented two flavors of IWA: IWA-Direct and IWA-BCAAA. With IWADirect, the ProxySG appliance is able to join the domain directly. With
IWA-BCAAA, the ProxySG appliance communicates with the BCAAA
agent, which is usually installed on a domain member server.
IWA uses credentials from the user’s initial workstation log on. When
configured correctly, domain users are not prompted for credentials, in
both explicit and transparent proxy deployments. Users from any trusted
domain can be authenticated.
Kerberos – Detailed Overview
• The client obtains a TGT (Ticket Granting Ticket) when the user logs in
to Windows.
• The KDC (Key Distribution Center) validates the client’s username and
password, and issues the TGT to the client.
›› The client uses the user’s password hash to decrypt the session
key in the TGT.
The supported authentication mechanisms are Basic, NTLM (NT
LAN Manager), and Kerberos. Basic and NTLM must go to a Domain
Controller (DC) to validate credentials and determine group membership.
Kerberos is more scalable then NTLM; ProxySG (IWA-Direct) or BCAAA
(IWA-BCAAA) can directly validate Kerberos tickets. Basic is very
scalable as well, since the ProxySG appliance is able to cache Basic
credentials. For security reasons, however, the majority of the ProxySG
appliance users no longer accept Basic credentials.
NTLM – Quick Overview
NTLM is a password authentication protocol.
• IWA will prompt the user if no password was used at log in.
• If the current user is a domain user who logged in with a password,
the browser won’t prompt for a password:
Client authenticates to KDC
with Username/Password
KDC
(Key Distribution
Center)
TGT
LOG IN
KDC Data
(Encrypted with the KDC’s key)
Client recieves TGT
(Ticket Granting Ticket)
Session Data
(Encrypted with the user’s password hash)
Figure 1: Kerberos overview
• The client uses a Service Ticket to log in to “Kerberized” services.
›› This assumes the realm was properly configured.
• The KDC needs to know the Service Principal Name (SPN) of the
service.
›› Windows caches a hash of the user password entered on log in to
the workstation.
• The service trusts the KDC to validate user credentials.
• The password doesn’t cross the wire.
›› A different hash is sent every time.
›› Incorporates a client nonce and a server nonce (random data).
• NTLM is less scalable than Kerberos.
The KDC shares a key with the service:
›› Symmetric encryption key
›› In Active Directory (AD), this key is the service account’s password
hash
• The KDC associates the SPN with the key.
2
TECHNICAL BRIEF
Security
Empowers
Business
KDC Service Ticket Example
The SPN in Figure 2 is “HTTP/bluecoat.com.”
Client presents TGT,
requests Service Ticket
KDC
LOG IN
Client recieves
Service Ticket
KDC
Figure 3: Client service ticket request and receipt
Trust/Service Key
• The service ticket is encrypted with the Service Key and the Session
Key.
• The client uses the Session Key (from the TGT) to decrypt the ticket.
Ticket Data
(Encrypted with the user’s Session Key)
Service Data
(Encrypted with the Service’s Key)
HTTP/bluecoat.com
Service
Figure 2: KDC service ticket example
• A user wants to authenticate to HTTP/bluecoat.com.
• The user presents his TGT to the KDC, and requests a service ticket.
• The KDC validates the TGT, then looks up the service key associated
with the SPN.
• The KDC generates a service ticket and sends it to the client.
Service Session Key
Decrypt with
Session Key
Service Ticket
Service Data
(Encrypted with the
Service’s Key)
Figure 4: Session key decryption
Note: The client will cache the service ticket. By default, the ticket
is cached for 10 hours, although that setting can be changed in AD
group policy. The client will not renew a cached service ticket until it
expires, or until the user logs in to Windows again. Since the ticket
contains group memberships, the user’s groups won’t get updated
until the client gets a new ticket. This means the ProxySG appliance
won’t learn about group membership changes until the client gets a
new ticket.
If an administrator makes a change to AD group membership and then
logs the user out of the ProxySG appliance, the ProxySG appliance
won’t pick up the group membership change until the client gets a
new ticket (for example, logs out of Windows and then logs back in).
Since NTLM gets new group memberships from the DC on each
authentication, NTLM doesn’t have that problem.
3
TECHNICAL BRIEF
Security
Empowers
Business
• The client presents the service ticket to the service. The service
decrypts the service ticket.
›› The service ticket identifies the user.
• The Kerberized service uses GSSAPI (Generic Security Services API)
to validate the Service Ticket.
• The service ticket is validated without going off-box.
›› Windows service tickets also contain group membership
information.
• The IWA service (ProxySG appliance for IWA-Direct or BCAAA for
IWA-BCAAA) can authenticate the user without contacting an external
server.
›› A Windows Service Ticket contains group membership information.
›› Windows can generate an access token without going off-box.
›› There is no longer a Netlogon bottleneck.
LOG IN
Login with Service Ticket
LOG IN
SERVICE
Service calls GSSAPI
to decrypt and validate
service ticket
Login with Service Ticket
Figure 7: Authentication Service calls GSSAPI
Service Ticket
Obtaining Group Membership Information
Service Data
(Encrypted with the
Service’s Key)
HTTP/bluecoat.com
Service
Figure 5: Login with Service Ticket
• The following illustration shows a Kerberos login
Service Ticket Response from KDC
Ticket Data
(Encrypted with the user’s Session Key)
This page contains a summary of the different group types and they
ways in which they may be used:
Client presents TGT,
requests Service Ticket
Service Data
(Encrypted with the Service’s Key)
KDC
Service Session Key
Client recieves
Service Ticket
Trust/Service Key
LOG IN
Login with Service Ticket
http://technet.microsoft.com/en-us/library/cc755692%28v=WS.10%29.
aspx
Groups are included in the PAC based on the server that is doing the
authentication (IE: BCAAA or the ProxySG). The page linked above
indicates where different group types can be used for authorization. The
PAC that it receives will contain all of the user’s universal groups, but
will only contain global groups from the joined domain forest, and only
domain local groups from that domain.
The technical reasons for that have to do with where the different group
types are stored in AD.
Service Ticket
Service Data
(Encrypted with the
Service’s Key)
HTTP/bluecoat.com
Service
Figure 6: A Kerberos Login Process
The method for obtaining the group memberships is the same for
IWA-Direct and IWA-BCAAA. After authenticating the user, the realm
receives a “Privilege Attribute Certificate”(PAC). The PAC contains the
group memberships. If Basic or NTLM credentials were used, then the
PAC is created by the DC and automatically provided to the realm after
successful authentication. If Kerberos credentials were used, then the
PAC is embedded in the credential.
Domain Controller Selection Mechanism
The ProxySG appliance (IWA-Direct) or the BCAAA server (IWA-BCAAA)
queries an SRV record in DNS and sends an “LDAP ping” pack to the
DCs that it finds. The LDAP ping is a small LDAP-over-UDP packet.
4
TECHNICAL BRIEF
Security
Empowers
Business
In SGOS 6.5.2 and later, customers can optionally specify a preferred
and alternate DC, and the ProxySG appliance will always use those. If
neither is available, then it will fall back to using an LDAP ping.
same time, it can’t send the second request to the DC until it receives a
response to the first request.
IWA-BCAAA
• Prior to accessing the ProxySG appliance, the user logs into the local
domain and obtains a TGT from the KDC.
This section describes how NTLM and Kerberos authentication work in
an IWA-BCAAA deployment.
NTLM
Kerberos
• The user attempts to access a URL that requires authentication; the
ProxySG appliance sends a challenge asking for Kerberos credentials.
Figure 8 shows how IWA-BCAAA processes NTLM requests. Requests
come into the ProxySG appliance and are forwarded to BCAAA. BCAAA
invokes SSPI (a Windows API), and Windows forwards the request
to a DC over the Netlogon Secure Channel (Schannel) for credential
validation.
Both IWA-Direct and IWA-BCAAA use Schannel to validate NTLM
credentials, and both are therefore subject to its limitations.
KDC
OCS
BCAAA
User logs in to Windows
and obtains TGT
NTLM
Requests
NTLM
Requests
LOG IN
User requests a page
from OCS. SG challenges
for Kerberos credentials
BCAAA
(MaxConcurrentAPI=1)
Schannel
NTLM Requests
(One at a time)
DC
(MaxConcurrentAPI=1)
Figure 8: NTLM Authentication with IWA-BCAAA
Figure 9: Kerberos Authentication with IWA-BCAAA: ProxySG challenges for credentials
• The client workstation obtains a Service Ticket from the KDC:
›› The Service Ticket is generated based on the authentication
challenge URL.
›› The challenge URL identifies the service.
›› The challenge URL depends on the authentication mode.
• The Service Ticket is presented to BCAAA.
Schannel is often a bottleneck for NTLM authentication. That’s
because in a typical scenario, the BCAAA server can only have
one Schannel request outstanding at a time, as represented by the
MaxConcurrentAPI=1 text in the above diagram (This value could be
modified. See “Netlogon / MaxConcurrentAPI Tuning Options” in this
document). For example, if BCAAA receives two NTLM requests at the
5
TECHNICAL BRIEF
Security
Empowers
Business
IWA-BCAAA: Service User Permission Requirements
BCAAA 5.5.x requires the “Act as part of the operating system”
privileges for IWA. If the ProxySG appliance will be used for Kerberos
Constrained Delegation, the “Impersonate users” privilege is required,
too.
KDC
OCS
Client requests Service
Ticket for challege URL
BCAAA
Service Ticket is
presented to BCAAA
BCAAA 6.1 does not need the “Act as part of the operating system”
or “Impersonate users” privileges to do IWA or Kerberos Constrained
Delegation.
IWA-Direct
LOG IN
This section describes how NTLM and Kerberos authentication works in
an IWA-Direct deployment.
NTLM
Figure 10: Kerberos Authentication with IWA-BCAAA: Client provides service ticket to
ProxySG
• BCAAA validates the Service Ticket without consulting a DC.
›› Validation is performed with Windows SSPI API.
›› Security Services Provider Interface, similar to GSSAPI.
Figure 12 shows how IWA-Direct processes NTLM requests. Requests
come in to the ProxySG appliance and are forwarded to a Domain
Controller (DC) over the Netlogon Secure Channel (Schannel) for
credential validation.
Both IWA-Direct and IWA-BCAAA use Schannel to validate NTLM
credentials, and both are therefore subject to its limitations.
›› The Service key is the password hash of the BCAAA service user.
›› If running as a local system, this is the machine account password.
Schannel
NTLM Requests
(One at a time)
NTLM
Requests
Users
ProxySG
(MaxConcurrentAPI=1)
Server
(MaxConcurrentAPI=1)
Figure 12: NTLM Authentication with IWA-Direct
KDC
OCS
BCAAA
BCAAA validates Service Ticket
and sends authentication
result to SG
LOG IN
Figure 11: Kerberos Authentication with IWA-BCAAA: SG validates service ticket
Schannel is often a bottleneck for NTLM authentication. That’s because
the ProxySG appliance with IWA-Direct in SGOS 6.3 and SGOS 6.4 can
only have one Schannel request outstanding at a time, as represented
by the MaxConcurrentAPI=1 text in Figure 12 (In SGOS 6.5.2+, this
is the default value, however it could be increased. See “Netlogon /
MaxConcurrentAPI Tuning Options” in this document). For example, if
the ProxySG appliance receives two NTLM requests at the same time, it
can’t send the second request to the DC until it receives a response to
the first request.
6
TECHNICAL BRIEF
Security
Empowers
Business
Kerberos
• Prior to accessing the ProxySG appliance, the user logs in to the local
domain and obtains a TGT.
• The user attempts to access a URL that requires authentication.
In response, the ProxySG appliance sends a challenge, asking for
Kerberos credentials.
the same service key, as it allows the key to be tied to a user’s
password, rather than a machine account password.
IWA-Direct:
User Permission Requirements for Joining a Windows Domain
The account used to join the ProxySG appliance to the domain
needs sufficient rights to add workstations to the domain. A regular
user account will work if you’re only joining a few workstations/SGs.
Microsoft allows regular “Domain User” accounts to join up to 10
workstations to the domain by default. More information can be found
here:
http://support.microsoft.com/kb/243327
GET Service Ticket for
sg.example.com
KDC
Shared Key
(Machine account password)
Log in with
Kerberos Service Ticket
(Includes Group
Memberships)
IWA-Direct
sg.example.com
Figure 13: Kerberos Authentication with IWA-Direct
• The client workstation obtains a Service Ticket from the KDC.
›› The Service Ticket is generated based on the authentication
challenge URL.
• The challenge URL identifies the service.
• The challenge URL depends on the authentication mode.
• The Service Ticket is presented to the ProxySG appliance.
• The ProxySG appliance validates the Service Ticket without
consulting a DC.
›› Validation is performed with GSSAPI, which is part of the MIT
Kerberos library that has been ported to SGOS.
›› Service key: If the “explicit proxy/load balancer” feature has NOT
been configured in the IWA-Direct realm (the typical scenario), the
service key is the ProxySG appliance’s machine account password.
Otherwise, the service key is the password hash of the load
balancer user. This allows multiple ProxySG appliances to share
http://support.microsoft.com/kb/251335
If the user wants to pre-create the ProxySG’s computer account, they
may do so. However, if they do that, then the user account they use
to join the domain must have sufficient rights to modify the computer
object. (That is no different from joining Windows boxes to the domain
using a pre-created machine account.)
After the ProxySG has joined the domain, it will “forget” the user
credentials that were supplied during domain join. Those credentials are
used only to create/modify the ProxySG’s machine account object. After
domain join, all access to AD will use the machine account credentials.
For both authentication and VPM browsing, the ProxySG’s machine
account does not need any more privileges than a “normal” machine
account for a Windows box.
The customer should not grant extra privileges to the ProxySG’s
machine account unless they’re planning to set up EMAPI or Kerberos
Constrained Delegation. That account should never have Domain Admin
privileges.
Performance
NTLM vs. Kerberos
Kerberos will perform better than NTLM.
• NTLM
›› NTLM (challenge/response) authentication requires two round-trips
between browser and BCAAA.
7
TECHNICAL BRIEF
Security
Empowers
Business
›› After the second round-trip, the BCAAA server (or the ProxySG
appliance for IWA-Direct) has to contact a DC to validate the user’s
password and retrieve a Windows access token that contains the
user’s group memberships.
• Kerberos
However, it is important to know that this parameter must be changed
on all DCs (since there isn’t a way to guarantee that the BCAAA server
or the ProxySG appliance will always use the same DC), and on the
BCAAA server and the ProxySG appliance (with SGOS 6.5.2 and later).
Modifying only one side of the communication will not work.
›› Requires only one round-trip, and doesn’t require the BCAAA server
(or the ProxySG appliance for IWA-Direct) to contact a DC.
NTLM
Requests
›› The client will contact the KDC to retrieve a service ticket that
will be presented to BCAAA (or the ProxySG appliance for IWADirect). Once retrieved, it will be cached for typically 10 hours.
(See”Kerberos - Detailed Overview” on page 2.)
NTLM
Requests
BCAAA
(MaxConcurrentAPI=10)
›› BCAAA (or the ProxySG appliance for IWA-Direct) can validate
the Service Ticket without contacting a DC, because the ticket is
encrypted with a key that BCAAA shares with the KDC.
Schannel
NTLM Requests
(Ten at a time)
›› The Service Ticket also contains a list of the user’s groups, so
BCAAA (or the ProxySG appliance for IWA-Direct) doesn’t need to
contact a DC to retrieve authorization information.
›› Authentication is successful when BCAAA (or the ProxySG
appliance for IWA-Direct) successfully decrypts and validates
the ticket.
Kerberos is one of the best solutions to NTLM scalability problems.
Unfortunately, it’s not widely (or well) understood, and therefore tends to
be under-utilized. Kerberos is a solid, scalable authentication protocol. It
is faster and more secure than NTLM.
Netlogon / MaxConcurrentAPI Tuning Options
As described in “How It Works” on page 1, Netlogon can be a
bottleneck. Netlogon is a Windows service that process authentication
requests (both incoming and outgoing). Windows maintains a Netlogon
Secure Channel to one DC from each domain needed. By default,
Netlogon will process only one authentication request at a time. If
BCAAA (IWA-BCAAA) or ProxySG appliance (IWA-Direct) receives
requests faster than the DC processes them, the requests will back up
at BCAAA or at the ProxySG appliance.
The MaxConcurrentAPI setting controls the number of concurrent
requests that can be processed by Schannel. This parameter can
be modified to support a larger number of Schannel connections.
DC
(MaxConcurrentAPI=10)
Figure 14: IWA Authentication with increased MaxConcurrentAPI settings
IWA-Direct
The ProxySG appliance with IWA-Direct (SGOS 6.3 and SGOS 6.4)
is using a hard-coded MaxConcurrentAPI=1 setting. This means the
setting cannot be modified.
The ProxySG appliance with IWA-Direct (SGOS 6.5.2 and later) offers
the option to modify MaxConcurrentAPI settings using the command
max-secure-channel-requests. In addition to that, you can also specify
preferred DCs (a primary and a backup DC) using the command
preferred-dc so that the ProxySG appliance can use the nearest DCs
with the lowest response time.
IWA-BCAAA
Changing the MaxConcurrentAPI setting does work for IWA-BCAAA,
and is fully transparent to BCAAA.
There are a few organizations where Microsoft has recommended
modifying this parameter to increase NTLM authentication performance.
The biggest challenge is that this change is also required on the
DCs (including trusted domain DCs), and that’s probably why some
organizations are not willing to implement this change.
8
TECHNICAL BRIEF
Security
Empowers
Business
Figure 15 shows a scenario in which the MaxConcurrentAPI settings
have not been changed on the DC of a trusted domain. In this case,
there are no performance gains for users who belong to Domain B, but
only for users who belong to Domain A.
NTLM
Requests
NTLM
Requests
Users from
Domain B
BCAAA: Domain A
Proxy-IP Surrogates
The caching problem is often solved by using the Proxy-IP
authentication mode. Switching to Proxy-IP mode in the example
above would cut down on the number of NTLM requests by a factor of
10, since the ProxySG appliance only needs to authenticate the first
connection from each client.
Note: A detailed discussion about how each authentication mode
works goes beyond the scope of this document. Details are available
in the SGOS Administration Guide.
(MaxConcurrentAPI=10)
Schannel
NTLM Requests
(One at a time)
DC: Domain B
(MaxConcurrentAPI=1)
However, it’s not always possible to use Proxy-IP mode. Proxy-IP mode
won’t work for multi-user systems such as Citrix, nor will it work for
users behind a network address translation (NAT) device. Furthermore,
using the IP address as the credential isn’t very secure, since IPs
are easily spoofed. That’s why a short surrogate cache interval is
recommended.
Schannel
NTLM Requests
(Ten at a time)
DC: Domain A
(MaxConcurrentAPI=10)
Figure 15: IWA Authentication with misconfigured MaxConcurrentAPI settings
Surrogates (IP, Cookie)
The use of surrogates can help to dramatically lessen the NTLM
authentication load on the ProxySG appliance, and in turn, the DC.
This is especially critical when NTLM is used with an explicit proxy.
Modern browsers will often open 10 or more concurrent connections to
the ProxySG appliance when loading a single Web page; the ProxySG
appliance must authenticate each of those connections.
When using NTLM, the ProxySG appliance can’t cache user credentials
as it does with Basic authentication. Each new connection therefore
results in an NTLM authentication request that is forwarded to a DC, as
shown in Figure 16.
GET cnn.com
(10+ New
Connections)
In proxy chaining deployments, it is still possible to use IP surrogates at
the parent proxy by looking at the X-Forwarded-For header instead of
the source IP address. The following policy tells the ProxySG appliance
to use the X-Forwarded-For header as IP surrogates:
<Proxy>
authenticate.credentials.address(“$(request.header.XForwarded-For)”)
This requires the child proxy to set the X-Forwarded-For header and to
populate it with the client IP address. If the child proxy is a Microsoft ISA
or TMG server, the cloud authentication connector can be used to set
this header field. Other proxies like the ProxySG appliance are able to
do this without additional software.
Note: Another option in proxy chaining environments could be to use
Kerberos constrained delegation, which should work with ISA or TMG.
However, no research has been performed on this setup
10+ NTLM
Requests
Client using
Explicit Proxy
DC
Figure 16: IWA Authentication without surrogates
9
TECHNICAL BRIEF
Security
Empowers
Business
Cookie Surrogates
Another solution is to use origin-cookie-redirect. The Origin-cookieredirect can be used with an explicit proxy, but an exception has to be
made for unintercepted HTTPS connections. Here’s an example:
<Proxy>
http.connect=yes authenticate(iwa_realm) authenticate.
mode(proxy)
authenticate(iwa_realm) authenticate.mode(origincookie-redirect)
The above policy will authenticate each HTTP CONNECT request
without using a surrogate.
HTTP CONNECT requests are sent by browsers in explicit proxy mode.
Their purpose is to tell the proxy server that the browser wants to set
up an SSL tunnel with the origin content server (OCS). The ProxySG
appliance can’t redirect HTTP CONNECT requests because they only
contain a hostname, rather than a full URL for the requested resource
at the OCS. If the ProxySG appliance were to redirect the request, it
wouldn’t be able to redirect the client back to the originally requested
resource.
The above policy will authenticate all requests, except HTTP CONNECT
requests, using a cookie surrogate. Depending on the number of HTTPS
connections in the example above, the policy could result in a nearly
ten-fold drop in NTLM authentications.
IWA Performance Numbers
Authentications per Second
For an IWA realm, NTLM functionality is the most important attribute.
Most IWA customers still use NTLM, rather than Kerberos or Basic.
NTLM performance is about the same between IWA-BCAAA and IWADirect in SGOS 6.3 and 6.4 on a ProxySG 9000-40 (but slightly different
on all other platforms, see Throughput Differences below for more
details). When BCAAA is running on a member server (as it is nearly
always deployed), it is able to process about 500-600 authentications
per second, which matches the performance of IWA-Direct when using a
ProxySG 9000-40.
The 500-600 authentications-per-second number is representative
of an optimal environment. Those numbers were generated in an
environment where a domain with a single DC was used, the DC was a
single hop away from the BCAAA server (very low network latency), and
the DC was not being used by any other network services. It is unlikely
that a customer could achieve the same throughput in a production
environment, unless they can guarantee that all of the aforementioned
factors always match the lab environment where the tests were
performed.
Note: The performance numbers were generated using the default
MaxConcurrentAPI settings. The 500-600 authentications-per-second
number represents a best-case scenario. It is unlikely that such
throughput could be achieved in a production environment. The actual
performance of NTLM in production depends on how quickly the
customer’s DC is able to service authentication requests.
DC performance is the single largest factor that affects NTLM
throughput, and that can vary widely. It is difficult to predict how DCs
will perform in each customer environment, because several factors can
affect performance. In some environments, some DCs might perform
substantially better than others. Some of the major factors affecting DC
performance are discussed in this document.
We have not performed any performance tests with
MaxConcurrentAPI=10 so far. The number of authentications-persecond will definitely increase, but probably not by a factor of 10. This
document will be updated as soon as we have run tests with modified
MaxConcurrentAPI settings.
Throughput Differences
The difference between IWA-BCAAA-NTLM and IWA-Direct-NTLM in
terms of throughput (using the default MaxConcurrentAPI settings) is, on
average, 82%. In other words, the throughput with IWA-Direct-NTLM is
about 82% of the numbers with IWA-BCAAA-NTLM (exception: ProxySG
9000-40, where the performance is about the same for both methods).
The difference between IWA-BCAAA-Kerberos and IWA-Direct-Kerberos
in terms of throughput is close to 90%. In other words, the throughput
with IWA-Direct-Kerberos is about 90% of the numbers with IWABCAAA-Kerberos.
10
TECHNICAL BRIEF
Security
Empowers
Business
How We Measure These Numbers
The base traffic pattern is the same for all the tests, but the number of
connections is different on each platform, in order to load the machine
to what we consider its peak, at 70% CPU. The base traffic pattern is:
• Explicitly proxied
• The same cache hit rate (20% of requests are cache hit/40 cache
miss/40 non-cacheable)
• Using varying objects that average to a 12k object size
• Each client connection pipelines 10 requests
BCAAA Server Sizing
With current servers, hardware is not a limiting factor. Often when we
max out Schannel, the BCAAA server’s CPU is hovering around 10%
- 15%. As a result, we no longer have any BCAAA server hardware
recommendations.
The hardware is more likely to matter in cases in which
MaxConcurrentAPI has been increased, or Kerberos is being used,
although we don’t have any performance test numbers for these cases.
Recommendations
• Authentication Mechanism: Use Kerberos instead of NTLM whenever
possible.
• Surrogates: Use surrogates whenever possible. Consider using
X-Forwarded-For header based surrogates in proxy chains.
Blue Coat Systems Inc.
www.bluecoat.com
Corporate Headquarters
Sunnyvale, CA
+1.408.220.2200
EMEA Headquarters
Hampshire, UK
+44.1252.554600
APAC Headquarters
Singapore
+65.6826.7000
›› Use IWA-BCAAA instead of IWA-Direct if the following conditions
exist:
• In case the customer has performance issues with NTLM:
›› Discuss modifying the MaxConcurrentAPI settings option.
›› If customers are not willing to modify MaxConcurrentAPI settings,
using nltest.exe (from the Windows resource kit) is another option.
Nltest.exe can tell you which DC BCAAA is using for Schannel,
and will allow you to forcibly switch to a DC that you specify. Some
customers run nltest.exe in a cron job each night to ensure their
BCAAA servers are always using the fastest DCs.
›› SGOS 6.5.2 or later and IWA-Direct can be used to specify a
preferred DC.
›› Another solution is to create multiple IWA-BCAAA realms on the
ProxySG appliance, and to deploy a BCAAA server for each realm.
Incoming requests can be authenticated by one realm or the other
by client subnet, HTTP header, or some other criteria known prior to
authentication.
About Technical Briefs
Technical briefs are designed to illustrate the features and capabilities
of Blue Coat products. By describing generic solutions, technical briefs
provide a foundation that Blue Coat customers can use to understand
how Blue Coat products can be used to solve specific problems.
These technical briefs are not intended to solve customer-specific
requests; if you need a customized solution to address a specific
concern, contact Blue Coat Professional Services at professionalservices@bluecoat.com.
›› NTLM is used for authentication AND
›› The MaxConcurrentAPI settings have been modified AND
›› Surrogates cannot be used
›› The customer is not willing to upgrade to SGOS 6.5.2 or later
© 2013 Blue Coat Systems, Inc. All rights reserved. Blue Coat, the Blue Coat logos, ProxySG, PacketShaper, CacheFlow, IntelligenceCenter, CacheEOS, CachePulse, Crossbeam, K9, the K9 logo, DRTR, Mach5, Packetwise, Policycenter, ProxyAV, ProxyClient,
SGOS, WebPulse, Solera Networks, the Solera Networks logos, DeepSee, “See Everything. Know Everything.”, “Security Empowers Business”, and BlueTouch are registered trademarks or trademarks of Blue Coat Systems, Inc. or its affiliates in the U.S. and
certain other countries. This list may not be complete, and the absence of a trademark from this list does not mean it is not a trademark of Blue Coat or that Blue Coat has stopped using the trademark. All other trademarks mentioned in this document owned by
third parties are the property of their respective owners. This document is for informational purposes only. Blue Coat makes no warranties, express, implied, or statutory, as to the information in this document. Blue Coat products, technical services, and any other
technical data referenced in this document are subject to U.S. export control and sanctions laws, regulations and requirements, and may be subject to export or import regulations in other countries. You agree to comply strictly with these laws, regulations and
requirements, and acknowledge that you have the responsibility to obtain any licenses, permits or other approvals that may be required in order to export, re-export, transfer in country or import after delivery to you. v.TB-IWA-DEPLOYMENT-GUIDE-EN-v1b-1013
11