Here's a start:
Web chaining rules
Using Web chaining rules, you can conditionally route requests, depending on the destination. For example, an organization with headquarters in the United States and a branch office in the United Kingdom might set up a Microsoft Internet Security and Acceleration (ISA) Server 2006 computer at the branch office. The branch office server might be connected to an Internet service provider (ISP) in the United Kingdom. A Web chaining rule on the ISA Server computer at the branch office could direct requests for Internet hosts in the United Kingdom to the local ISP, with all other requests directed to the ISA Server computer at headquarters.
The downstream ISA Server computer at the branch office in the United Kingdom benefits from the ISA Server cache at headquarters. That benefit is augmented by additional caching of local objects—retrieved from the local ISP—on the ISA Server computer in the branch office.
The following figure illustrates how Web Proxy requests can be routed to different servers, depending on the requested destination.
In this figure, the ISA Server computer in the branch office routes client requests for sites in the United Kingdom (U.K.) to the ISA Server in the U.K. All other requests (marked "Request for international Web site" are routed directly to the Internet.
For instructions, see Create a Web chaining rule.
Routing Web requests
As part of the Web chaining rule configuration, you can specify how a Web Proxy client request should be routed:
- Retrieving the object directly from the specified destination.
- Routing the request to a specific upstream ISA Server computer. In this case, you can also specify a backup route if the primary route is unavailable.
- Redirecting the request to a hosted site. In this case, the request is routed to the specified Web site.
We recommend that you encrypt the traffic to the upstream ISA Server computer by using Secure Sockets Layer (SSL) bridging.
For instructions, see Configure how Web chaining rules retrieve requests.
ISA Server uses the backup route when the primary route is unavailable. The ISA Server computer periodically polls the upstream server that is specified as the primary route, to determine if it is available. As soon as the primary route is available, requests are sent to that server, rather than the server on the backup route. For instructions, see Configure a primary route for Web requests and Configure a backup route for Web requests.
In certain cases, the upstream server may require that the downstream proxy pass authentication. For those cases, credentials must be passed. These credentials are used by the upstream server to authenticate the downstream server.
When authentication is required, you can configure whether the Web server to which the request is redirected can authenticate the client. For instructions, see Allow delegation of credentials.
- When you pass credentials in plaintext to an upstream server, beware that the upstream server and network could potentially access those credentials. Over standard Hypertext Transfer Protocol (HTTP) connections, all information is passed as plaintext.
In a Web Proxy chaining scenario, user names and passwords can be specified using 7-bit characters only. Otherwise, Integrated Windows authentication will fail on the downstream proxy server.
Automatically poll upstream server for configuration option
In a chained scenario, an upstream array (with more than one member) might require Digest authentication. When the packets are always transferred to the same array member, the traffic will be successfully authenticated.
Consider a scenario in which a Web chaining rule is set to automatically poll the upstream server for configuration, and the upstream server requires Digest authentication. Typically, when a client request is chained to an upstream array, ISA Server automatically determines which array member should serve the request, and a request will always be served by the same array member. However, when the client sends an HTTPS request, ISA Server randomly determines which upstream array member serves the request; it might not be the same array member. In this case, Digest authentication may fail when the request is tunneled using SSL through a different upstream array member.
Thomas W Shinder, M.D.