[isalist] Re: Think Outside the GUI challenge #2
- From: "Roy Tsao" <caohuiming@xxxxxxxxxxxxx>
- To: <isalist@xxxxxxxxxxxxx>
- Date: Fri, 24 Nov 2006 18:43:40 +0800
TKS4Giving detailed explanation..., Jim!
----- Original Message -----
From: Jim Harrison
To: isalist@xxxxxxxxxxxxx
Sent: Friday, November 24, 2006 12:03 AM
Subject: [isalist] Re: Think Outside the GUI challenge #2
..and closer still.
The problem is exactly that; a web filter or ISA (mis)configuration is
blocking CARP or Intra-Array status requests.
Cust #1 - Intra-array traffic blocked by filter or ISA configuration
ISA array members determine array membership availability using a two-part
process;
1. Query ISA storage for array membership
2. Query each server for its status via the web proxy listener on the
defined intra-array IP.
This status request is made as
http://intra.array.ip.addr:web.proxy.port/array.dll?Get.Info.v3. The queried
server will respond with its current availability as configured in CARP load
settings.
If:
1. ISA storage gives incorrect information about
a. the array membership
b. the Intra-array IP of those members
2. The web proxy listener on the Intra-array IP defined for server 'X'
is either non-functional or misconfigured
..then intra-array status queries will fail. When this occurs, the
requesting server will remove the unresponsive server from the WPAD server
list.
Cust #2 - Server-side CARP blocked by filter or ISA configuration:
Not counting Amy's interpretation :-p, CARP comes in two flavors; server-side
and client-side.
1. Client-side CARP is a web request from a client that is able to use
the same cache-discovery algorithm as the ISA array members to direct the
request to the server most likely to actually hold the content. For IE,
allowing automatic discovery or "Configuration URL" allows this to occur.
2. Server-side CARP is a web request between ISA array members that is
made on behalf of the original client. This occurs when the clients are not
configured, or simply don't know how to use the wpad script. More often than
not, the application is configured to use a static proxy, but this can also
occur with SecureNET & FWC traffic as well. Note that these requests are made
to the Intra-Array IP as defined in ISA storage <HINT>
When ISA "A" needs to ask ISA "B" for the content being requested, it does
so using a two-part process (David hinted at this):
1. ISA "A" authenticates to ISA "B" using its machine account as part
of a request for http://ms_proxy_intra_array_auth_query. For ISA Servers as
domain members, this authentication should be Kerberos. If not, or the
Kerberos ticket request fails <HINT>, it will be NTLM.
2. If the authentication is successful <HINT>, ISA "A" forwards the
original client request to ISA "B"
Thus, if
1. the web filter is not aware of the two requests that cannot contain
user-accounts, and it fails all requests that cannot be resolved to users,
..or
2. The web proxy listener for the defined intra-array IP is disabled or
otherwise non-functional,
Server-side CARP and Intra-Array status requests will fail.
..on a side note.
There are at least two separate web filters that I know of (can't talk out of
school, tho) that will make their own LDAP-based user-account lookups even
after ISA has already provided them with the "domain\user" context. This
happens because these applications allow (nay; encourage) you to use something
other than your own AD- or SAM-based user-grouping mechanisms. If you use
Windows or AD groups to organize users into "FTP allowed", "kitty porn allowed"
groups, there would be no need to duplicate this effort in a separate user
grouping process.
Oh yeh - Happy ThanxGiving, everyone!
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On
Behalf Of Roy Tsao
Sent: Wednesday, November 22, 2006 11:00 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: Think Outside the GUI challenge #2
If so, to config that webfilter not to listen for the reqeust from specific
ip range used by ISA EE
----- Original Message -----
From: Jim Harrison
To: isalist@xxxxxxxxxxxxx
Sent: Thursday, November 23, 2006 1:32 PM
Subject: [isalist] Re: Think Outside the GUI challenge #2
Roy's getting closer.
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On
Behalf Of Roy Tsao
Sent: Wednesday, November 22, 2006 9:28 PM
To: isalist@xxxxxxxxxxxxx; isapros@xxxxxxxxxxxxx
Subject: [isalist] Re: Think Outside the GUI challenge #2
The plug-in Webfilter hijack the connection to webproxy listerner?
----- Original Message -----
From: Jim Harrison
To: isalist@xxxxxxxxxxxxx ; isapros@xxxxxxxxxxxxx
Sent: Thursday, November 23, 2006 1:16 PM
Subject: [isalist] Re: Think Outside the GUI challenge #2
Nope; all IP & DNS settings and records are proper for each deployment.
All CSS communication is proper.
All ISA storage data is proper.
Don't tell me you all give up so easy?
J
From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx]
On Behalf Of Roy Tsao
Sent: Wednesday, November 22, 2006 8:26 PM
To: isalist@xxxxxxxxxxxxx; isapros@xxxxxxxxxxxxx
Subject: [isalist] Re: Think Outside the GUI challenge #2
Maybe A record of each ISA node is not properly configured in DNS.
----- Original Message -----
From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
To: <isapros@xxxxxxxxxxxxx>; <isalist@xxxxxxxxxxxxx>
Sent: Wednesday, November 22, 2006 11:31 PM
Subject: [isalist] Think Outside the GUI challenge #2
> http://www.ISAserver.org
> -------------------------------------------------------
>
> Just last week, I encountered an interesting scenario; two separate
> customers using two completely different ISA plug-ins hit exactly the
> same problem, although it manifested differently for each.
>
> Cust #1
> Scenario: ISA 2004 EE, 4 array members W2K3 SP1, separate CSS, all
> domain-joined.
> Problem: When requested, each array member produced a wpad script that
> only included itself. In no case did the wpad script list any of the
> other three array members.
>
> Cust #2
> Scenario: ISA 2004 EE, LARGE multiple-array deployment, separate,
> multiple CSS, W2K3 SP1, all domain-joined.
> Problem: CARP requests continuously failed.
>
>
> In both cases, the same relative behavior for each plug-in caused the
> problem - what was it?
>
>
> All mail to and from this domain is GFI-scanned.
>
> ------------------------------------------------------
> List Archives: //www.freelists.org/archives/isalist/
> ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
> ISA Server Articles and Tutorials:
http://www.isaserver.org/articles_tutorials/
> ISA Server Blogs: http://blogs.isaserver.org/
> ------------------------------------------------------
> Visit TechGenix.com for more information about our other sites:
> http://www.techgenix.com
> ------------------------------------------------------
> To unsubscribe visit http://www.isaserver.org/pages/isalist.asp
> Report abuse to listadmin@xxxxxxxxxxxxx
>
All mail to and from this domain is GFI-scanned.
All mail to and from this domain is GFI-scanned.
All mail to and from this domain is GFI-scanned.
Other related posts:
