You can change the authentication by using the adsutil.vbs script.

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.

By default, NTLM uses per-connection authentication.

To change NTLM back to its default, replace the word TRUE with FALSE and restart the IIS server.

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.

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.

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:

Figure: Response header contained in the line X-RBT-Prefetched-By 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:

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.

You can look at the client-side SteelHead log messages to determine whether or not the HTTP optimization module is functioning. The logging level on the SteelHead must be set at info level logging for the messages to appear in the log. If the HTTP optimization module is prefetching objects, a message similar to the following appears in the logs:

This only applies to the URL learning and parse-and-prefetch. No log messages are displayed for metadata response or object prefetch table.

The key specified in the log message is not necessarily the object that triggered the prefetch operation. In RiOS 6.0 and later, the log message includes the object that triggered the prefetch operation.

While automatic configuration is typically the preferred method of configuration, you have the option of manual configuration. The following use case shows a manual configuration.

A customer has a 1.5 Mbps link with 100 ms latency between the branch office and the data center. The PCs in the remote office are running Microsoft Windows XP with Internet Explorer 7. Users in the remote offices are complaining of slow access for SAP Netweaver and Microsoft SharePoint. The SAP Netweaver server has an IP address of 172.30.1.10 and the Microsoft SharePoint server has an IP address of 172.16.2.20.

Because both SAP Netweaver and Microsoft SharePoint are well-known applications, the customer configured the following on the client-side SteelHead.

After configuring the settings above, the customer noticed a significant improvement in response time for SAP Netweaver but no changes for Microsoft SharePoint—even though the connections are optimized with good data reduction. One of the users mentioned that the Microsoft SharePoint portal required authentication, which might be the reason why parse-and-prefetch did not work. Unfortunately, the system administrator in charge of the SharePoint portal cannot be reached at this moment and you cannot check the authentication setting on the server.

Instead of checking the authentication on the server, you can capture tcpdump traces and check for the authentication scheme in use. Figure: TCP dump trace confirming Kerberos enabled shows the server has Kerberos enabled and hence the client attempts to authenticate using Kerberos first.

Figure: TCP dump trace showing per-request Kerberos confirms that by scrolling through the trace, the per-request Kerberos is configured on the server.

Figure: Enable force NTLM shows that given this information, the best option is to enable Force NTLM for the SharePoint server.

Taking another trace on the client-side SteelHead confirms that the only authentication option available is NTLM. Because there is no other authentication option but NTLM, the client is forced to authenticate via NTLM and parse-and-prefetch and prefetches can once again function as before.

In this instance, it is not necessary to enable the other features, as the entire transaction took place over a single connection. If the client uses multiple TCP connections, then it might be necessary to enable reuse auth, strip auth header, and gratuitous 401. Enabling the rest of the features does not provide any benefit in this instance, but it does not cause any problems either.