SteelHead™ Deployment Guide - Protocols : HTTP Optimization : Tuning Microsoft IIS Server
  
Tuning Microsoft IIS Server
This section describes the steps required to modify the IIS server so that it can maximize the performance of the HTTP Authentication optimization module. In some instances of the HTTP Authentication optimization requires the IIS server to behave in a certain way. For example, if NTLM authentication is in use, then the HTTP optimization module expects the NTLM authentication to use per-connection authentication.
Determining the Current Authentication Scheme on IIS
IIS 6 uses metabase to store its authentication settings. Although you can manually modify the metabase, the supported method in querying or modifying the metabase is to use the built-in Visual Basic (VB) script adsutil.vbs. The adsutil.vbs script is located in the C:\inetpub\adminscripts directory on the IIS server.
To determine the current setting on the IIS server
  • From the command prompt on the Windows server, enter the following command in the c:\inetpub\adminscripts directory:
    • cscript adsutil.vbs get w3svc/$WebsiteID$/root/NTAuthenticationProviders
    The $WebsiteID$ is the ID of the Web site hosted by the Web server. The $WebsiteID$ can be found in the IIS Manager and it's the number under the Identifier column.
    Figure 4‑16. Web Site ID in the Identifier Column
    If the output of the command is one of the following, it indicates that the server prefers Kerberos authentication and if that fails, it falls back to NTLM:
    The parameter "NTAuthenticationProviders" is not set at this node.
    NTAuthenticationProviders : (STRING) "Negotiate,NTLM"
    If the output of the command is the following, it indicates that the server only supports NTLM authentication:
    NTAuthenticationProviders : (STRING) "NTLM"
    Determining the Current Authentication Mode on IIS
    Both NTLM and Kerberos authentication can support either per-connection or per-request authentication. To determine the current authentication mode on IIS, use the same VB script, adsutil.vbs, but query a different node:
    cscript adsutil.vbs get w3svc/$WebsiteID$/root/AuthPersistSingleRequest
     
    The output of the command should be similar to the following text:
    The parameter "AuthPersistSingleRequest" is not set at this node; or
     
    AuthPersistSingleRequest : (BOOLEAN) False; or
     
    AuthPersistSingleRequest : (BOOLEAN) True
    Per-Connection or Per-Request NTLM Authentication
    If the authentication scheme is NTLM and the output of the authentication mode is either not set or false, then the server is configured with per-connection NTLM authentication. If the output of the authentication mode is true, then the server is configured with per-request NTLM authentication.
    Per-Connection or Per-Request Kerberos Authentication
    If the authentication scheme is Kerberos, you must perform extra steps you can determine whether the server is using per-connection or per-request authentication.
    To determine whether Kerberos is using per-connection or per-request (applies to IIS v6.0)
    Check the registry for key named EnableKerbAuthPersist under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters. If the key does not exist, or if the key does exist but has a value of zero, then Kerberos is using per-request authentication.
    Figure 4‑17. Registry Editor Window
    If the key exists but has a nonzero value, and the output from authentication mode is false, then Kerberos might be using per-connection Kerberos. Kerberos is using per-connection authentication if the server running is running IIS v6.0 and has the patch installed per Microsoft's knowledge base article http://support.microsoft.com/kb/917557.
    For information about IIS v7.0, go to http://support.microsoft.com/kb/954873.
     
    The following table shows the different combinations and whether Kerberos would perform per-connection or per-request authentication.
     
     
     
    EnableKerbAuthPersist/AuthPersistNonNTLM**
     
     
    Not-set
    Nonzero
    Zero
     
    AuthPersistSingleRequest
    Not-set
    Per-request
    Per-connection*
    Per-request
    TRUE
    Per-request
    Per-request
    Per-request
    FALSE
    Per-request
    Per-connection
    Per-request
    * requires IIS patch
    ** AuthPersistNonNTLM of IIS 7 replaces EnableKerbAuthPersist of IIS 6
    Changing the Authentication Scheme
    You can change the authentication by using the adsutil.vbs script.
    To modify the server so that it only supports NTLM authentication
  • From the command prompt on the Windows server, enter the following command:
    • cscript adsutil.vbs set w3svc/$WebsiteID$/root/NTAuthenticationProviders "NTLM"
    You can configure the server to attempt Kerberos authentication first before NTLM by changing the last parameter to Negotiate, NTLM.
    Remember to restart the IIS server after the changes have been made.
    Changing the Per-Connection/Per-Request NTLM Authentication Mode
    By default, NTLM uses per-connection authentication.
    To change per-connection NTLM to per-request NTLM
  • From the command prompt on the Windows server, enter the following command:
    • cscript adsutil.vbs set w3svc/$WebsiteID$/root/AuthPersistSingleRequest TRUE
    To change NTLM back to its default, replace the word TRUE with FALSE and restart the IIS server.
    When you use NTLM, the HTTP optimization module works best when per-connection authentication is set.
    Changing the Per-Connection/Per-Request Kerberos Authentication Mode
    By default, Kerberos uses per-request authentication. There are several ways to configure Kerberos to use per-connection authentication. For details, see Per-Connection or Per-Request Kerberos Authentication.
    HTTP Authentication Settings
    The following table shows some of the recommended configurations for the HTTP Authentication optimization. In this instance, assume that it is not possible to make any modifications on the IIS server.
    For example, if the authentication setting on the IIS server is per-request Kerberos, enabling Force NTLM forces the client to use NTLM and in turn, the HTTP optimization module can provide better optimization by using the URL Learning and Parse-and-Prefetch features. If NTLM authentication is not an option, then the only possibility is to enable Gratuitous 401.
    If you modify the settings on the IIS server, then Force NTLM might not be necessary. In this case, only the first row of the following table is applicable.
    The HTTP optimization module expects the default authentication behavior for both NTLM and Kerberos (in other words, per-connection authentication for NTLM and per-request authentication for Kerberos). Continuing with the example earlier, if the IIS server is configured to use the nonstandard authentication scheme by using per-request Kerberos and per-request NTLM, then using Force NTLM does not help as it changes from per-request Kerberos to per-request NTLM. In this case, URL Learning and Parse-and-Prefetch is not effective.
     
    IIS Authentication
    Recommended Configurations
    Notes
    per-connection NTLM
    Reuse Auth. + Strip Auth. Header + Grat. 401
     
    Reuse Auth. + Strip Auth. Header
     
    per-request Kerberos
    Reuse Auth. +Force NTLM + Strip Auth. Header + Grat. 401
    N/A if NTLM is not an option
    Reuse Auth. +Force NTLM + Strip Auth. Header + Grat. 401
    N/A if NTLM is not an option
    Grat. 401
     
    per-request NTLM
    Grat. 401
     
    per -connection Kerberos
    Reuse Auth. + Force NTLM + Strip Auth. Header
    N/A if NTLM is not an option
    Reuse Auth.
     
    Change to per-request Kerberos and turn on
     
    Grat. 401
     
    Don’t know
    Reuse Auth. + Strip Auth. Header + Grat. 401
     
    Reuse Auth. + Strip Auth. Header
     
     
    HTTP Optimization Module and Proxy Servers
    Some network deployments might involve HTTP proxy servers to speed up resource retrieval, apply access control policies, or audit and filter contents. In general, the SteelHeads provide full optimization benefits even with proxy servers in place. Optimized connections can be limited or even hindered in the following circumstances:
  • Proxy authentication - If the proxy server uses authentication, prefetching performance can be affected. Similar to Web server authentication, proxy authentication can limit the prefetching capability of the connection where prefetched resources are served when the proxy server uses per-connection authentication. In the case of the per-request mode, prefetching is not possible as every single request requires user authentication. HTTP authentication optimization features apply to both Web server and proxy authentication.
  • Proxy caching - A proxy server can maintain its own local cache to accelerate access to resources. Generally, proxy caching does not thwart HTTP optimization. If it caches objects for an excessively long time, Object Prefetch Table (OPT) might not provide full benefits as the retrieved resource might not be sufficiently fresh.
  • Selective proxying - If the same Web server is accessed directly by a client and through a proxy server, URL Learning might not work properly. URL Learning builds a prefetch tree by observing ongoing requests. This is based on the assumption that the same URL is requested by the client if the same base page is requested again.
    • When a prefetch tree is created without a proxy, the observed partial URLs comprise the tree. If another client asks for the same page but through a proxy, the proxy fails to forward the prefetched responses because it expects full URLs to be able to send the responses back to the client. Thus URL Learning might not work well when proxy is selectively employed for the same host. This only happens with URL Learning. Other prefetching schemes, such as Parse-and-Prefetch and Object Prefetch Table, are not subjected to this issue.
  • Fat Client - Not all applications accessed through a Web browser use the HTTP protocol. This is especially true for fat clients that run inside a Web browser that might use proprietary protocols to communicate with a server. HTTP optimization does not improve performance in such cases.
    • Determining the Effectiveness of the HTTP Optimization Module
    Figure 4‑18 shows that when an object is optimized by the HTTP optimization module, the response header contains the line X-RBT-Prefetched-By. The X-RBT-Prefetched-By line also contains the name of the SteelHead, the version of system, and the method of optimization. The different methods of optimization are:
  • UL - URL Learning.
  • PP - Parse-and-Prefetch.
    •  
  • MC - Metadata Response (pre-RiOS v6.0).
  • PT - Object Prefetch Table (RiOS v6.0 or later).
  • AC - Gratuitous 401.
    • Figure 4‑18. Response Header Contained in the Line X-RBT-Prefetched-By
    The response header can be captured by using tcpdump, HTTPWatch, Fiddler or similar tools. Because the HTTP optimization module is a client-side driven feature, the capture must be done on the client itself.