Professional Documents
Culture Documents
IWA Authentication Fundamentals and Deployment Guidelines v2
IWA Authentication Fundamentals and Deployment Guidelines v2
IWA Authentication Fundamentals and Deployment Guidelines v2
IWA Authentication
Fundamentals and Deployment
Guidelines
© 2013 Blue Coat Systems, Inc. All rights reserved. BLUE COAT, PROXYSG, PACKETSHAPER,
CACHEFLOW, INTELLIGENCECENTER, CACHEOS, CACHEPULSE, CROSSBEAM, K9, DRTR,
MACH5, PACKETWISE, POLICYCENTER, PROXYAV, PROXYCLIENT, SGOS, WEBPULSE,
SOLERA NETWORKS, DEEPSEE, DS APPLIANCE, SEE EVERYTHING. KNOW EVERYTHING.,
SECURITY EMPOWERS BUSINESS, BLUETOUCH, the Blue Coat shield, K9, and Solera
Networks logos and other Blue Coat logos 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.
Document History
2
Contents
CONTENTS
.....................................................................................................................................................
3
LIST
OF
FIGURES
............................................................................................................................................
4
INTRODUCTION
.............................................................................................................................................
5
HOW
IT
WORKS
.............................................................................................................................................
5
INTEGRATED
WINDOWS
AUTHENTICATION
OVERVIEW
..................................................................................................
5
NTLM
-‐
Quick
Overview
.................................................................................................................................
5
Kerberos
-‐
Detailed
Overview
........................................................................................................................
6
Obtaining
Group
Membership
Information
...................................................................................................
9
Domain
Controller
Selection
Mechanism
.......................................................................................................
9
IWA-‐BCAAA
......................................................................................................................................................
10
NTLM
............................................................................................................................................................
10
Kerberos
.......................................................................................................................................................
11
IWA-‐BCAAA
Service
User
Permission
Requirements
....................................................................................
12
IWA-‐DIRECT
.......................................................................................................................................................
12
NTLM
............................................................................................................................................................
12
Kerberos
.......................................................................................................................................................
13
IWA-‐Direct:
User
Permission
Requirements
for
Joining
a
Windows
Domain
...............................................
14
PERFORMANCE
............................................................................................................................................
14
NTLM
VS.
KERBEROS
............................................................................................................................................
14
NETLOGON
/
MAXCONCURRENTAPI
TUNING
OPTIONS
...............................................................................................
15
IWA-‐Direct
....................................................................................................................................................
16
IWA-‐BCAAA
..................................................................................................................................................
16
SURROGATES
(IP,
COOKIE)
.....................................................................................................................................
17
Proxy-‐IP
Surrogates
......................................................................................................................................
17
Cookie
Surrogates
........................................................................................................................................
18
IWA
PERFORMANCE
NUMBERS
..............................................................................................................................
19
Authentications
per
Second
.........................................................................................................................
19
Throughput
Differences
................................................................................................................................
19
How
We
Measure
These
Numbers
...............................................................................................................
20
BCAAA
Server
Sizing
.....................................................................................................................................
20
RECOMMENDATIONS
...................................................................................................................................
20
ABOUT
TECHNICAL
BRIEFS
............................................................................................................................
21
3
4
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.
• 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:
• This assumes the realm was properly configured.
• Windows caches a hash of the user password entered on log in to the
workstation.
❐ The password doesn’t cross the wire.
❐ 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 a TGT.
• The client uses the user’s password hash to decrypt the session key in the
TGT.
Figure
1:
Kerberos
overview
❐ The client uses a Service Ticket to log in to “Kerberized” services.
❐ The KDC needs to know the Service Principal Name (SPN) of the service. ❐
6
❐ 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.
Figure
3:
Client
service
ticket
request
and
receipt
❐ 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.
Figure
4:
Session
key
decryption
Note: The client will cache the service ticket. By default, the ticket is cached for
10 hours, although that 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.
7
❐ Client presents service ticket to the service. The service decrypts the service
ticket.
• The service ticket identifies the user.
• 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.
Figure
5:
Login
with
Service
Ticket
❐ A Kerberos login
Figure
6:
A
Kerberos
Login
Process
❐ Kerberized service uses GSSAPI (Generic Security Services API) to validate
the Service Ticket.
❐ The service ticket is validated without going off-‐‑box.
8
9
IWA-‐BCAAA
This section describes how NTLM and Kerberos authentication work in an
IWABCAAA deployment.
NTLM
Figure 8 shows how IWA-‐‑BCAAA processes NTLM requests. Requests come in to 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.
Figure
8:
NTLM
Authentication
with
IWA-‐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 same time, it
can’t send the second request to the DC until it receives a response to the first
request.
10
Kerberos
❐ Prior to accessing the ProxySG appliance, the user logs into the local domain
and obtains a TGT.
❐ The user attempts to access a URL that requires authentication; the ProxySG
appliance sends a challenge asking for Kerberos credentials.
Figure
9:
Kerberos
Authentication
with
IWA-‐BCAAA:
SG
challenges
for
credentials
• 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.
Figure
10:
Kerberos
Authentication
with
IWA-‐BCAAA:
Client
provides
service
ticket
to
ProxySG
11
IWA-‐Direct
This section describes how NTLM and Kerberos authentication works in an
IWA-‐‑Direct deployment.
NTLM
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.
Figure
12:
NTLM
Authentication
with
IWA-‐Direct
12
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.
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.
Figure
13:
Kerberos
Authentication
with
IWA-‐Direct
• 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.
13
• 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 the same service key, as
it allows the key to be tied to a user’s password, rather than a machine
account password.
Performance
NTLM
vs.
Kerberos
Kerberos will perform better than NTLM.
❐ NTLM
14
❐ Kerberos
• Requires only one round-‐‑trip, and doesn'ʹt require the BCAAA server (or
the ProxySG appliance for IWA-‐‑Direct) to contact a DC.
• The client will contact the KDC to retrieve a service ticket that will be
presented to BCAAA (or the ProxySG appliance for IWA-‐‑Direct). Once
retrieved, it will be cached for typically 10 hours. (See"ʺKerberos -‐‑ Detailed
Overview"ʺ on page 2.)
• 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.
• 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 well understood, and therefore tends to be
under-‐‑utilized. Kerberos is a solid, scalable authentication protocol. It is faster and
more secure than NTLM.
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.
16
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.
Figure 15: IWA
Authentication
with
mis-‐configured
MaxConcurrentAPI
settings
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.
17
However, it’s not always possible to use Proxy-‐‑IP mode. Proxy-‐‑IP 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.
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.X-Forwarded-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.
Cookie
Surrogates
Another solution is to use origin-cookie-redirect. The Origin-cookie-redirect
can be used with an explicit proxy, but an exception has to be made for un-‐‑
intercepted HTTPS connections. Here’s an example:
<Proxy>
http.connect=yes authenticate(iwa_realm) authenticate.mode(proxy)
authenticate(iwa_realm) authenticate.mode(origin-cookie-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.
18
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 IWA-‐‑BCAAA-‐‑Kerberos.
19
❐ 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
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.
❐ Use IWA-‐‑BCAAA instead of IWA-‐‑Direct if the following conditions exist:
21