RE: Web Client Requests
- From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
- To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
- Date: Sun, 29 Jan 2006 11:30:25 -0800
Kewl - I taught Stefaan something - the scales are
nearly-kinda-sorta-like-almost getting balanced...
:-)
--------------------------------------------
Jim Harrison
MCP(NT4, W2K), A+, Network+, PCG
http://isaserver.org/Jim_Harrison/
http://isatools.org
Read the help / books / articles!
--------------------------------------------
-----Original Message-----
From: Stefaan Pouseele [mailto:stefaan.pouseele@xxxxxxxxx]
Sent: Sunday, January 29, 2006 11:17 AM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: Web Client Requests
http://www.ISAserver.org
Hi Jim,
Many thanks! Again, I've learned a lot!
Stefaan
-----Original Message-----
From: Jim Harrison [mailto:Jim@xxxxxxxxxxxx]
Sent: zondag 29 januari 2006 20:09
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: Web Client Requests
http://www.ISAserver.org
1 - yep.
2 - this is part & parcel to the discussion, since by default, the web
proxy
still intercepts the traffic even if the request is FWC-based. It can
*still* respond with a "407" and the FWC is not going to interfere.
Basically, the FWC isn't designed to be a proxy application.
3 - IE will generally treat *all* IP address-based URLs as remote,
regardless of the information it has. This is because it sees the dots
in
the URL and believes it to be an FQDN.
Examples:
- any application that uses WinHTTP (OL2K3, WinMedia) has to make use of
the
wpad script on its own, because the wpad support in WinHTTP is somewhat
limited.
- any application that makes "custom" interpretations of the wpad
functionality instead of using it as written.
The main point is that IE is only one of literally thousands of
"proxy-aware-sorta-like-kinda-maybe-a-little-bit-if-it-doesn't-rain-on-a
lternate-Thursdays" applications. Designing for one application almost
certainly guarantees incompatibility with the remaining ones.
--------------------------------------------
Jim Harrison
MCP(NT4, W2K), A+, Network+, PCG
http://isaserver.org/Jim_Harrison/
http://isatools.org
Read the help / books / articles!
--------------------------------------------
-----Original Message-----
From: Stefaan Pouseele [mailto:stefaan.pouseele@xxxxxxxxx]
Sent: Sunday, January 29, 2006 10:57 AM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: Web Client Requests
http://www.ISAserver.org
Hi Jim,
1. Quote: "The FWC goes transparent, not just because the destination is
part of the LAT (although it will do this, too), but because the wspad
and
mspclnt data include the ISA IP & port for the web proxy. This is a
separate case."
So, only access to the FWC source code can reveal that?
2. Quote: "I agree that crappy apps make including 127/8 a
near-guaranteed
requirement, but this isn't related to the question of whether or not
the
FWC should be performing auth for web proxy connections."
Oops, I thought we are discussing the case that the FWC can take over
the
authentication if the destination is configured for direct access in the
browser?
3. Quote: "We don't prepopulate the wpad address ranges because this
data
usage is inconsistent across applications (take IE, for instance). For
this
reason, address list population is left to the ISA admins."
What do you mean exactly with "is inconsistent across applications"? Can
you
give some IE examples other than '127.0.0.1'?
Thanks,
Stefaan
-----Original Message-----
From: Jim Harrison [mailto:Jim@xxxxxxxxxxxx]
Sent: zondag 29 januari 2006 19:40
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: Web Client Requests
http://www.ISAserver.org
Stefaan,
Here is what's incorrect (or at least incomplete):
"..because the destination is on the FWC's LAT.."
The FWC goes transparent, not just because the destination is part of
the
LAT (although it will do this, too), but because the wspad and mspclnt
data
include the ISA IP & port for the web proxy. This is a separate case.
I agree that crappy apps make including 127/8 a near-guaranteed
requirement,
but this isn't related to the question of whether or not the FWC should
be
performing auth for web proxy connections.
We don't prepopulate the wpad address ranges because this data usage is
inconsistent across applications (take IE, for instance). For this
reason,
address list population is left to the ISA admins.
--------------------------------------------
Jim Harrison
MCP(NT4, W2K), A+, Network+, PCG
http://isaserver.org/Jim_Harrison/
http://isatools.org
Read the help / books / articles!
--------------------------------------------
-----Original Message-----
From: Stefaan Pouseele [mailto:stefaan.pouseele@xxxxxxxxx]
Sent: Sunday, January 29, 2006 10:25 AM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: Web Client Requests
http://www.ISAserver.org
Hi Jim,
What is exactly incorrect in my statements? I don't see it :-(
Of course the Web proxy traffic isn't remoted by the FWC because the
destination is on the FWC's LAT. I only wanted to point out that there
is in
my opinion an inconsistency in what is included by default in the
wspad.dat
and the wpad.dat. It can't harm to include by default the LAT address
list
and 127/8 in wpad.dat too. Can we agree on that?
Thanks,
Stefaan
-----Original Message-----
From: Jim Harrison [mailto:Jim@xxxxxxxxxxxx]
Sent: zondag 29 januari 2006 18:26
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: Web Client Requests
http://www.ISAserver.org
Sorry - that's incorrect, Stefaan...
The FWC only "goes transparent" when the application is making a
connection
to the web proxy listener.
This is because you *don't* want the FWC interfering with the normal
client-to-proxy communications by making a remoted connection.
The assumption is that if the client application understand how to make
a
CERN proxy request, it also should understand how to behavior when it
receives a "407" response. If it doesn't, the app is clearly not in
compliance with RFC 2617.
Regarding the wpad address list, if you had snatched up the
copylattowebproxy.js script that I published last year, you'd have the
behavior you wanted.
The FWC wspad script *does* have the LAT address list, and so it
understands
when to be transparent based on the destination IP.
SP2 will include a changed wpad script that attempts to work around some
browser oddities (like IE believing that 127.0.0.1 is a remote IP).
--------------------------------------------
Jim Harrison
MCP(NT4, W2K), A+, Network+, PCG
http://isaserver.org/Jim_Harrison/
http://isatools.org
Read the help / books / articles!
--------------------------------------------
-----Original Message-----
From: Stefaan Pouseele [mailto:stefaan.pouseele@xxxxxxxxx]
Sent: Sunday, January 29, 2006 8:39 AM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: Web Client Requests
http://www.ISAserver.org
Hi Amy,
OK, here is some more info.
If you run on the FWC client the command 'fwctool printconfig' you will
see
that:
1. the LDT (Local Domain Table) contains what is defined in the network
properties > Domains tab on ISA.
2. the LAT (Local Address Table) contains what is defined in the network
properties > Addresses tab on ISA,
+ contains the multicast address range 224.0.0.0 - 224.255.255.254
+ contains the localhost address range 127.0.0.0 - 127.255.255.255
In other words all what is needed for proper operation of the Firewall
Client ;-)
However, for the browser that is *not* the case and MS should be shamed
about this!
If you request the 'wpad.dat' file from the ISA server, you will see
that:
1. the function MakeNames() contains what is defined in the network
properties > Domains tab on ISA,
+ contains whatever domains or computers (FQDN's) you defined in the
network properties > Web Browser tab on ISA.
2. the function MakeIPs() do NOT contains what is defined in the network
properties > Addresses tab on ISA,
+ do NOT contains the localhost address range 127.0.0.0 -
127.255.255.255,
+ do contains whatever IP ranges you defined in the network
properties >
Web Browser tab on ISA.
Why is the network properties > Addresses tab on ISA *and* the localhost
address range 127.0.0.0 - 127.255.255.255 not included by default in the
wpad.dat? That's not consistent with what we could expect! Grrrr.....
In other words, you'll have to work around that issue yourself by
defining
some extra entries in the network properties > Web Browser tab on ISA
;-)
HTH,
Stefaan
-----Original Message-----
From: Amy Babinchak [mailto:amy@xxxxxxxxxxxxxxxxxxxxxxxxxx]
Sent: zondag 29 januari 2006 14:59
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: Web Client Requests
http://www.ISAserver.org
I haven't tried putting the localhost into the fwc exception list. The
only
address in the exception list by default is the internal IP of the
server.
Do you also include this address?
Amy
-----Original Message-----
From: Stefaan Pouseele [mailto:stefaan.pouseele@xxxxxxxxx]
Sent: Sunday, January 29, 2006 8:28 AM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: Web Client Requests
http://www.ISAserver.org
Hi Amy,
The Firewall Client should take care of all authentication problems if
you
set those sites for direct access. However, are you sure that the
network ID
'127.0.0.0/8' is *always* set for direct access in IE and is included in
the
FWC's LAT? Many financial applications are using the network ID
'127.0.0.0/8' as some sort of local proxy service, at least here in
Belgium.
HTH,
Stefaan
-----Original Message-----
From: Amy Babinchak [mailto:amy@xxxxxxxxxxxxxxxxxxxxxxxxxx]
Sent: zaterdag 28 januari 2006 22:15
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: Web Client Requests
http://www.ISAserver.org
I don't know about that. You must just not be hearing about it from the
rest. The apps that are causing problems are from banks (401K
submission),
payroll services, stock brokerage services...essentially anything firmly
in
the bean counter realm. Schwab, ADP, Paychex, you name it. If it's
financial
they've got a java app that won't play nice with authentication, even
with
the Firewall Client installed.
Note to Tom: And these things aren't running on the server either,
they're
running on client workstations.
Amy
-----Original Message-----
From: Jim Harrison [mailto:Jim@xxxxxxxxxxxx]
Sent: Saturday, January 28, 2006 3:54 PM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: Web Client Requests
http://www.ISAserver.org
..except if the app is proxy-aware, then you get into the "worm ate the
bird" problem again...
I will stipulate that the SBS community seems to hit this particular
wall
more often than most; probably due to the
cheaposkinflintmothposcketicity of
their customers.
--------------------------------------------
Jim Harrison
MCP(NT4, W2K), A+, Network+, PCG
http://isaserver.org/Jim_Harrison/
http://isatools.org
Read the help / books / articles!
--------------------------------------------
-----Original Message-----
From: Thomas W Shinder [mailto:tshinder@xxxxxxxxxxx]
Sent: Saturday, January 28, 2006 12:34 PM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: Web Client Requests
http://www.ISAserver.org
Hey Jim,
That's what the Firewall client is for, so that you don't have to
disable
auth.
So, I'll have to update my maxim:
SecureNAT and Anonymous Access rules are for Losers and Servers.
How's that?
Tom
> -----Original Message-----
> From: Jim Harrison [mailto:Jim@xxxxxxxxxxxx]
> Sent: Saturday, January 28, 2006 1:13 PM
> To: [ISAserver.org Discussion List]
> Subject: [isalist] RE: Web Client Requests
>
> http://www.ISAserver.org
>
> You're right - I responded in reverse.
> If you:
> 1. disable the web proxy filter
> 2. remove authentication
>
> ..then no one is forced to authenticate and you are limited to
> IP-based access controls.
> Bad juju, IMHO...
>
> --------------------------------------------
> Jim Harrison
> MCP(NT4, W2K), A+, Network+, PCG
> http://isaserver.org/Jim_Harrison/
> http://isatools.org
> Read the help / books / articles!
> --------------------------------------------
> -----Original Message-----
> From: Amy Babinchak [mailto:amy@xxxxxxxxxxxxxxxxxxxxxxxxxx]
> Sent: Saturday, January 28, 2006 11:02 AM
> To: [ISAserver.org Discussion List]
> Subject: [isalist] RE: Web Client Requests
>
> http://www.ISAserver.org
>
> Yes unfortunately? Wouldn't it be no, unfortunately?
>
> Yes to me would mean that everything would authenticate except for
> what you specify.
>
> No would mean that everything would then go through without
> authentication.
>
> Amy
>
>
> -----Original Message-----
> From: Jim Harrison [mailto:Jim@xxxxxxxxxxxx]
> Sent: Saturday, January 28, 2006 10:36 AM
> To: [ISAserver.org Discussion List]
> Subject: [isalist] RE: Web Client Requests
>
> http://www.ISAserver.org
>
> Yes, unfortunately.
> This is exactly why I list this step among the "last line of
> defense".
>
> --------------------------------------------
> Jim Harrison
> MCP(NT4, W2K), A+, Network+, PCG
> http://isaserver.org/Jim_Harrison/
> http://isatools.org
> Read the help / books / articles!
> --------------------------------------------
> -----Original Message-----
> From: Amy Babinchak [mailto:amy@xxxxxxxxxxxxxxxxxxxxxxxxxx]
> Sent: Saturday, January 28, 2006 7:12 AM
> To: [ISAserver.org Discussion List]
> Subject: [isalist] RE: Web Client Requests
>
> http://www.ISAserver.org
>
> Yes, I am. So once you do that does any traffic bother to authenticate
> anymore?
>
> Amy
>
>
> -----Original Message-----
> From: Jim Harrison [mailto:Jim@xxxxxxxxxxxx]
> Sent: Saturday, January 28, 2006 10:05 AM
> To: [ISAserver.org Discussion List]
> Subject: [isalist] RE: Web Client Requests
>
> http://www.ISAserver.org
>
> Contrary to tribal knowledge, there's nothing special about the SBS
> installation of ISA other than some rules that make me nauseous and
> wizards that remove the burden of understanding. The SBS version of
> ISA is ISA Std Edition.
>
> I think you're referring to disassociating the Web Proxy filter from
> the HTTP protocol as is offered for some apps that can't authenticate
> at all?
>
> ..which brings up my next point - while it's true that there are some
> apps that think they have a direct link to their desired destination,
> this technique should be the *last* line of defense; not the first.
>
> --------------------------------------------
> Jim Harrison
> MCP(NT4, W2K), A+, Network+, PCG
> http://isaserver.org/Jim_Harrison/
> http://isatools.org
> Read the help / books / articles!
> --------------------------------------------
> -----Original Message-----
> From: Amy Babinchak [mailto:amy@xxxxxxxxxxxxxxxxxxxxxxxxxx]
> Sent: Saturday, January 28, 2006 5:59 AM
> To: [ISAserver.org Discussion List]
> Subject: [isalist] RE: Web Client Requests
>
> http://www.ISAserver.org
>
> So then in the SBS world once we check the box that allows apps to
> bi-pass the web proxy filter won't everything then bi-pass it? In the
> first ISA, she says, she would allow unauthenticated access and
> everything would then go through?
>
> Amy
>
> -----Original Message-----
> From: Jim Harrison [mailto:Jim@xxxxxxxxxxxx]
> Sent: Saturday, January 28, 2006 1:58 AM
> To: [ISAserver.org Discussion List]
> Subject: [isalist] RE: Web Client Requests
>
> http://www.ISAserver.org
>
> I'm not clear on "basic and authenticated", since basic is an
> authentication mechanism? If you mean "basic and <anything else
> offered>", it's up to the client to choose the strongest method it
> supports (RFC 2617).
>
> In the first "ISA, she say:", ISA advises the client what auth methods
> it will accept )Negotiate, NTLM, Kerberos in my example).
> In the second "Client, he say:", the client responds with the auth
> method it wants to use. In this response, the specified auth method
> *must* be one of the options ISA previously presented, or ISA will
> reject the auth attempt.
>
> --------------------------------------------
> Jim Harrison
> MCP(NT4, W2K), A+, Network+, PCG
> http://isaserver.org/Jim_Harrison/
> http://isatools.org
> Read the help / books / articles!
> --------------------------------------------
> -----Original Message-----
> From: Amy Babinchak [mailto:amy@xxxxxxxxxxxxxxxxxxxxxxxxxx]
> Sent: Friday, January 27, 2006 5:31 PM
> To: [ISAserver.org Discussion List]
> Subject: [isalist] RE: Web Client Requests
>
> http://www.ISAserver.org
>
> I'll probably get your post a day or two from now. They tend to come
> in blobs. 20 messages today, 300 tomorrow. I find it difficult to keep
> track of a thread. I don't even ask yahoo to send it out of their own
> system. It gets delivered to my yahoo account! Maybe I should sign up
> under a non-yahoo address and see if I have any better success.
>
> I understand that the authentication process starts all over again.
> What I'm asking is, if I enable basic and authenticated access for the
> listener, what determines whether ISA will accept basic or
> authenticated for a particular packet?
>
> Amy
>
> -----Original Message-----
> From: Jim Harrison [mailto:Jim@xxxxxxxxxxxx]
> Sent: Friday, January 27, 2006 5:24 PM
> To: [ISAserver.org Discussion List]
> Subject: [isalist] RE: Web Client Requests
>
> http://www.ISAserver.org
>
> sbs2k@xxxxxxxxxxxxxxx
>
> The point is that:
> 1. the clients know diddly (and maybe even squat) about the way the
> proxy is configured 2. unless the client is using proxy:keepalive in
> the client-to-proxy connection, each request is an introduction
> between the client and the proxy
>
> Thus, each new connection between the client and proxy incurs a new
> authentication requirement and the ball starts bouncing all over
> again.
>
> -------------------------------------------------------
> Jim Harrison
> MCP(NT4, W2K), A+, Network+, PCG
> http://isaserver.org/Jim_Harrison/
> http://isatools.org
> Read the help / books / articles!
> -------------------------------------------------------
>
>
> -----Original Message-----
> From: Amy Babinchak [mailto:amy@xxxxxxxxxxxxxxxxxxxxxxxxxx]
> Sent: Friday, January 27, 2006 14:11
> To: [ISAserver.org Discussion List]
> Subject: [isalist] RE: Web Client Requests
>
> Which forum?
>
>
>
> So here is where I get confused. If my web listener allows both
> non-authenticated and authenticated requests, then why after I allow
> non-authenticated access does ISA ever require authentication? Won't
> everything then be accepted with authentication?
>
>
>
> Amy
>
>
>
> ________________________________
>
> From: Greg Mulholland [mailto:greg@xxxxxxxxxxxxxx]
> Sent: Friday, January 27, 2006 3:38 PM
> To: [ISAserver.org Discussion List]
> Subject: [isalist] Web Client Requests
>
>
>
> Hey guys, im forwarding this message on behalf of Jim. He posted it to
> another list and true to form it was too good an explanation not to
> impart on the masses (or the cheesemakers).
>
>
>
> This traces the path of your IE (or other) http requests and explains
> why you will always see anonymous requests in your web logs. Thanks
> Jim
>
>
>
> Greg Mulholland
>
>
> >>>>>>>>>>>>>>
>
> Correct - all web clients do exactly that.
> This is also why the logs will forever contain anonymous requests even
> if all you allow are authenticated connections, because ISA will log
> those denied anonymous requests.
>
> What you can't tell from the logs is what happens after that in
> detail.
> This requires a bit of Netmon (or Ethereal, if you swing that
> way) sleuthing.
>
> Here's the bouncing ball:
>
> ** Client, he say:
> GET http://www.isaserver.org/ HTTP/1.1
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/x-shockwave-flash, application/vnd.ms-excel,
> application/vnd.ms-powerpoint, application/msword, */*
> Accept-Language: en-us
> Accept-Encoding: gzip, deflate
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
> .NET CLR 1.1.4322; InfoPath.1)
> Host: www.isaserver.org
> Proxy-Connection: Keep-Alive
>
> ** ISA, she say:
> HTTP/1.1 407 Proxy Authentication Required ( The ISA Server requires
> authorization to fulfill the request. Access to the Web Proxy service
> is denied. )
> Via: 1.1 HEARTOFGOLD
> Proxy-Authenticate: Negotiate
> Proxy-Authenticate: Kerberos
> Proxy-Authenticate: NTLM
> Connection: Keep-Alive
> Proxy-Connection: Keep-Alive
> Pragma: no-cache
> Cache-Control: no-cache
> Content-Type: text/html
> Content-Length: 4113
>
> ..note - the ISA in this case (as in yours, probably) logged this
> request as anonymous and responded saying that it allowed three
> authentication methods: Negotiate, Kerberos and NTLM. These are the
> default auth methods for any ISA installation (including SBS).
>
> ** Client, he say:
> GET http://www.isaserver.org/ HTTP/1.1
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/x-shockwave-flash, application/vnd.ms-excel,
> application/vnd.ms-powerpoint, application/msword, */*
> Accept-Language: en-us
> Accept-Encoding: gzip, deflate
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
> .NET CLR 1.1.4322; InfoPath.1)
> Host: www.isaserver.org
> Proxy-Connection: Keep-Alive
> Proxy-Authorization: NTLM
> TlRMTVNTUAABAAAAB7IIogQABAAzAAAACwALACgAAAAFASgKAAAAD0ZPUkRQUk
> VGRUNUSE9N
> RQ==
>
> Note that the client chose NTLM auth and passed the first part of the
> handshake in Base-64 encoding. Not to worry, this isn't like Basic,
> which is base-64 encoded plain text; this is base-64 encoded encrypted
> information. ISA also logs this request as anonymous.
>
> ** ISA, she say:
> HTTP/1.1 407 Proxy Authentication Required ( Access is denied. )
> Via: 1.1 HEARTOFGOLD
> Proxy-Authenticate: NTLM
> TlRMTVNTUAACAAAACAAIADgAAAAFgomiWWcfZe6QNCsAAAAAAAAAALQAtABAAA
> AABQLODgAA
> AA9IAE8ATQBFAAIACABIAE8ATQBFAAEAFgBIAEUAQQBSAFQATwBGAEcATwBMAE
> QABAAiAGgA
> bwBtAGUALgBqAGEAbABvAGoAYQBzAGgALgBvAHIAZwADADoAaABlAGEAcgB0AG
> 8AZgBnAG8A
> bABkAC4AaABvAG0AZQAuAGoAYQBsAG8AagBhAHMAaAAuAG8AcgBnAAUAIgBoAG
> 8AbQBlAC4A
> agBhAGwAbwBqAGEAcwBoAC4AbwByAGcAAAAAAA==
> Connection: Keep-Alive
> Proxy-Connection: Keep-Alive
> Pragma: no-cache
> Cache-Control: no-cache
> Content-Type: text/html
> Content-Length: 0
>
> Note that ISA also passed some NTLM data back to the client - this is
> part and parcel to NTLM authentication even outside of HTTP
>
> ** Client, he say:
> GET http://www.isaserver.org/ HTTP/1.1
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/x-shockwave-flash, application/vnd.ms-excel,
> application/vnd.ms-powerpoint, application/msword, */*
> Accept-Language: en-us
> Accept-Encoding: gzip, deflate
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
> SV1;.NET CLR 1.1.4322; InfoPath.1)
> Host: www.isaserver.org
> Proxy-Connection: Keep-Alive
> Proxy-Authorization: NTLM
> TlRMTVNTUAADAAAAGAAYAG4AAAAYABgAhgAAAAgACABIAAAACAAIAFAAAAAWAB
> YAWAAAAAAA
> AACeAAAABYKIogUBKAoAAAAPSABPAE0ARQBKAGkAbQBIAEYATwBSAEQAUABSAE
> UARgBFAEMA
> VABunrbKxTfLxwAAAAAAAAAAAAAAAAAAAABNhP8BkKK3ZR1MXfC2h14+Q4IQaVlWRH8=
>
>
> Note that the client passes the remaining part of the NTLM handshake -
> if ISA can resolve the credentials passed by the client during this
> process, all will be FD&H.
>
> ** ISA, she say:
> HTTP/1.1 200 OK
> Proxy-Connection: Keep-Alive
> Connection: Keep-Alive
> Content-Length: 40936
> Via: 1.1 HEARTOFGOLD
> Date: Fri, 27 Jan 2006 05:49:15 GMT
> Content-Type: text/html
> Server: Microsoft-IIS/6.0
> X-Powered-By: ASP.NET
> Set-Cookie: ASPSESSIONIDCCRRSRBC=EIBLFICAIMCPFBFCEKFFKBEA; path=/
> Cache-control: private
>
> This is where access is allowed (200 response).
>
> You should note that I haven't included anything that may have been
> passed in the HTTP body - it's not important to this discussion and
> only makes for an unweildy thread.
>
> --------------------------------------------
> Jim Harrison
> MCP(NT4, W2K), A+, Network+, PCG
> http://isaserver.org/Jim_Harrison/
> http://isatools.org
> Read the help / books / articles!
All mail to and from this domain is GFI-scanned.
------------------------------------------------------
List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com
------------------------------------------------------
You are currently subscribed to this ISAserver.org Discussion List as:
stefaan.pouseele@xxxxxxxxx To unsubscribe visit
http://www.webelists.com/cgi/lyris.pl?enter=isalist
Report abuse to listadmin@xxxxxxxxxxxxx
------------------------------------------------------
List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com
------------------------------------------------------
You are currently subscribed to this ISAserver.org Discussion List as:
jim@xxxxxxxxxxxx
To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=isalist
Report abuse to listadmin@xxxxxxxxxxxxx
All mail to and from this domain is GFI-scanned.
------------------------------------------------------
List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com
------------------------------------------------------
You are currently subscribed to this ISAserver.org Discussion List as:
stefaan.pouseele@xxxxxxxxx To unsubscribe visit
http://www.webelists.com/cgi/lyris.pl?enter=isalist
Report abuse to listadmin@xxxxxxxxxxxxx
------------------------------------------------------
List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com
------------------------------------------------------
You are currently subscribed to this ISAserver.org Discussion List as:
jim@xxxxxxxxxxxx
To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=isalist
Report abuse to listadmin@xxxxxxxxxxxxx
All mail to and from this domain is GFI-scanned.
Other related posts:
