Re: [squid-users] sharepoint pinning issue?

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 13 Feb 2013 14:08:48 +1300

On 13/02/2013 3:49 a.m., Alexandre Chappaz wrote:
> Hi,
>
> I know this is a subject that has been put on the table many times,
> but I wanted to share with you my experience with squid + sharepoint.
>
> Squid Cache: Version 3.2.7-20130211-r11781
>
> I am having an issue with autehtication :
> when accessing the sharepoint server, I do get a login/pw popup, I can
> login and see some of the pages behind, but when doing some operation,
> even though I am supposed to be logged in, the autentcation popup
> comes back.
> Here is what I find the the access log :
> 1360679927.561 43 X.X.X.X TCP_MISS/200 652 GET
> http://saralex.hd.free.fr/_layouts/images/selbg.png -
> FIRSTUP_PARENT/192.168.100.XX image/png

URL #1. No authentication required. non-pinned connection used.

> 1360679928.543 37 X.X.X.X TCP_MISS/401 542 GET
> http://saralex.hd.free.fr/_layouts/listform.aspx? -
> PINNED/192.168.100.XX -

URL #2. Sent to upstream on already authenticated+PINNED connection.
Upstream server requires further authentication details.
  --> authentication challenge?

> 1360679928.665 58 X.X.X.X TCP_MISS/401 795 GET
> http://saralex.hd.free.fr/_layouts/listform.aspx? -
> PINNED/192.168.100.XX -

URL #2 repeated. Sent to upstream on already authenticated+PINNED
connection. Upstream server requires further authentication details.
  --> possibly authentication handshake request?

> 1360679928.753 229 X.X.X.X TCP_MISS/200 20625 GET
> http://saralex.hd.free.fr/_layouts/images/fgimg.png -
> FIRSTUP_PARENT/192.168.100.XX image/png

URL #3. No authentication required. non-pinned connection used.

> 1360679928.788 68 X.X.X.X TCP_MISS/302 891 GET
> http://saralex.hd.free.fr/_layouts/listform.aspx? -
> PINNED/192.168.100.XX text/html

URL #2 repeated. Sent to upstream on already authenticated+PINNED
connection. Upstream server redirectes the client to another URL.
  --> authentication credentials accepted.

> 1360679928.921 45 X.X.X.X TCP_MISS/401 542 GET
> http://saralex.hd.free.fr/Lists/Tasks/NewForm.aspx? -
> PINNED/192.168.100.XX -

URL #4. Sent to upstream on already authenticated+PINNED connection.
Upstream server requires further authentication details.
  --> authentication challenge?

> 1360679929.019 47 X.X.X.X TCP_MISS/401 795 GET
> http://saralex.hd.free.fr/Lists/Tasks/NewForm.aspx? -
> PINNED/192.168.100.XX -

URL #4 repeated. Sent to upstream on already authenticated+PINNED
connection. Upstream server requires further authentication details.
  --> possibly authentication handshake request?

> 1360679929.656 81 X.X.X.X TCP_MISS/200 1986 GET
> http://saralex.hd.free.fr/_layouts/images/loadingcirclests16.gif -
> FIRSTUP_PARENT/192.168.100.XX image/gif

URL #5. no authentication required. non-pinned connection used.

> 1360679930.417 1322 X.X.X.X TCP_MISS/200 130496 GET
> http://saralex.hd.free.fr/Lists/Tasks/NewForm.aspx? -
> PINNED/192.168.100.XX text/html

URL #4 repeated. Sent to upstream on already authenticated+PINNED
connection. Upstream server provides the display response.
  --> authentication credentials accepted.

> 1360679934.618 53 X.X.X.X TCP_MISS/401 542 GET
> http://saralex.hd.free.fr/_layouts/iframe.aspx? -
> PINNED/192.168.100.XX -
> 1360679934.729 51 X.X.X.X TCP_MISS/401 795 GET
> http://saralex.hd.free.fr/_layouts/iframe.aspx? -
> PINNED/192.168.100.XX -
>
> could this be a pinning issue?
>
> Is V2.7 STABLE managing these things in a nicer way?

Unknown. But I doubt it. This is Squid using a PINNED connection to
relay traffic to an upstream server. That upstream server is rejecting
the clients delivered credentials after each object. There is no sign of
proxy authentication taking place, this re-challenge business is all
between client and upstream server.

You need to look at whether these connections are being pinned then
closed, and why that is happening. Squid-3.2 offers debug level 11,2
which will give you a trace of the HTTP headers to see if the close is a
normal operation from either end. Or whether they are keep-alive by
Squid and the upstream server is just constantly forcing re-auth (it
happens).

Amos
Received on Wed Feb 13 2013 - 01:08:55 MST

This archive was generated by hypermail 2.2.0 : Tue Feb 26 2013 - 12:00:04 MST