Justin Popa wrote:
> Afternoon everyone, I have a small problem.
>
> I've got a user who needs to access a website, and when he goes there
> he occasionally gets an Access Denied error. Looking in the logs, I
> see the following:
>
> 10.150.6.53 - hoffmand [04/Feb/2008:13:53:33 -0500] "GET
> http://buymtdonline.arinet.com/EW54MTD/MTDC/Include/cfgCustom.js
> HTTP/1.0" 200 13276 TCP_MISS:DIRECT
> 10.150.6.53 - (hoffmand) - [04/Feb/2008:13:53:33 -0500] "GET
> http://buymtdonline.arinet.com/scripts/EmpartISAPI.dll? HTTP/1.0" 403
> 1403 TCP_DENIED:NONE
> 10.150.6.53 - hoffmand [04/Feb/2008:13:53:33 -0500] "GET
> http://buymtdonline.arinet.com/scripts/EmpartISAPI.dll? HTTP/1.0" 200
> 4908 TCP_MISS:DIRECT
>
> Note: In the second line I added the (hoffmand) because it's obviously
> his traffic, just not marked as such.
Which indicates Squid did not receive authentication details for that
request.
> Now, for the fun stuff. We use
> AD for our authentication source and that works great. I've also
> looked through our deny statements in squid.conf, of which there are
> only 3 and here they are:
>
> 1) Blocking based on url. The blocked entries are all like
> myspace.com, facebook.com, 2girls1cup.com, etc...
>
> 2) Blocking based on streaming media. These entries are like .avi,
> .mov, .wmv, etc.
>
> 3) Blocking if Active Directory authentication failed.
>
> Any thoughts on what this might be just looking at it? Obviously I'm
> sure you guys need more, but any help you can give me in starting to
> track down the why would be awesome. Thanks
>
Squid did not receive authentication details with the first request for
EmpartISAPI.dll, threw the 403 and then (likely*) got the same request
with authentication details. I would assume all this happened with out
the client seeing anything. At least in this instance. I don't know
enough about NTLM authentication to say why the browser would not send
authentication details with that request.
Chris
* With the default squid.conf setting "strip_query_terms on" there is no
way to tell if that is indeed the same request, but assuming the time
stamps are accurate, it's likely.
Received on Mon Feb 04 2008 - 14:47:39 MST
This archive was generated by hypermail pre-2.1.9 : Sat Mar 01 2008 - 12:00:04 MST