RE: [squid-users] Squid Not Forwarding Authentication Information To SharePoint

Scott

I take it to mean that from your description below that you are using
windows integrated authentication to your Sharepoint server via the
transparent proxy.

Are you successfully connecting to your Sharepoint server from outside your
company's network? If so what authentication are you using and is it via a
proxy?

Regards Mike

-----Original Message-----
From: Scott Cameron [mailto:scott.cameron@ubisoft.com]
Sent: Thursday, 19 April 2007 2:28 PM
To: squid-users@squid-cache.org
Subject: RE: [squid-users] Squid Not Forwarding Authentication Information
To SharePoint

Hi guys,

We're running Sharepoint 2007 here and I have absolutely no problems
with a transparent squid proxy. I want to add in the HTTP/1.1 patch,
but for now we're using stock SQUID 2.6STABLE12. This, of course, is
extremely inefficient for NTLM, but works surprisingly well.

I have an extremely basic configuration:

http_port 80 transparent
client_persistent_connections on
server_persistent_connections on
persistent_connection_after_error on

The HTTP/1.1 patch w/ SQUID-CVS works, but breaks with
persistent_connection_after_error, which is required for NTLM. It's on
my plate to look at sooner or later.

I don't know if you're using NTLM, but if not, you should check out the
CVS version with Henrik's 1.1 patch.

Scott

-----Original Message-----
From: Mike Withers [mailto:m.withers@uws.edu.au]
Sent: Wednesday, April 18, 2007 9:13 PM
To: 'Caleb Anthony'
Cc: squid-users@squid-cache.org
Subject: RE: [squid-users] Squid Not Forwarding Authentication
Information To SharePoint

Anthony

I posted in May and October 2006 on a similar problem with no success.
Here
is what I know so far:

-----Original Message-----
From: Caleb Anthony [mailto:caleb.anthony@gmail.com]
Sent: Wednesday, 18 April 2007 7:49 AM
To: squid-users@squid-cache.org
Subject: [squid-users] Squid Not Forwarding Authentication Information
To
SharePoint

Hello,

I am currently testing out Squid as a reverse proxy for Microsoft
SharePoint services.

<comment>Share point uses front-page extensions. A similar problem as I
was
looking at front page to upload files to a web server.</comment>

So far everything web-based is working great. Squid is passing
credentials to the back end server correctly through the use of
login=PASS, pages are loading correctly, etc...

There is one problem however. When a user opens up a Word document,
and tries to save or save as, the save/save as window hangs for about
30 - 45 seconds, and then eventually loads a much different looking
window than if not going through the reverse proxy. I can post
screenshots if it will help.

I finally turned on a packet sniffer to watch the traffic. I saved two
sessions: one using the proxy and one going direct to the server. The
only difference that I see is that the proxy isn't forwarding the
WWW-Authenticate header when performing the save/save as.

Going direct to the SharePoint server:

GET /Shared%20Documents/Forms/AllItems.aspx HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, application/x-shockwave-flash, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
If-Modified-Since: Tue, 17 Apr 2007 20:19:37 GMT
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
IE6SP1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; InfoPath.1; .NET CLR
2.0.50727)
Host: xxxxxxx.xx.xx.xxx.xxx:4458
Connection: Keep-Alive
Cookie: WSS_KeepSessionAuthenticated=4458;
MSOWebPartPage_AnonymousAccessCookie=4458
Authorization: Negotiate xxxxx

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Length: 56495
Content-Type: text/html; charset=utf-8
Expires: Mon, 02 Apr 2007 20:19:52 GMT
Last-Modified: Tue, 17 Apr 2007 20:19:52 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 12.0.0.4518
WWW-Authenticate: Negotiate xxxxx
X-AspNet-Version: 2.0.50727
Set-Cookie: WSS_KeepSessionAuthenticated=4458; path=/
Set-Cookie: MSOWebPartPage_AnonymousAccessCookie=4458; expires=Tue,
17-Apr-2007 20:49:52 GMT; path=/
Set-Cookie:
http%3A%2F%2Fxxxxxxx%2Exx%2Exx%2Exxx%2Exxx%3A4458%2FDiscovery=WorkspaceS
iteN
ame=xxx&WorkspaceSiteUrl=xxx&WorkspaceSiteTime=xxx;
expires=Thu, 17-May-2007 20:19:52 GMT; path=/_vti_bin/Discovery.asmx
Date: Tue, 17 Apr 2007 20:19:51 GMT

Now through the proxy:

GET /Shared%20Documents/Forms/AllItems.aspx HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, application/x-shockwave-flash, */*
Referer: http://xx.xxx.xx.xxx:4458/default.aspx
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1;
IE6SP1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; InfoPath.1; .NET CLR
2.0.50727)
Host: xx.xxx.xx.xxx:4458
Connection: Keep-Alive
Authorization: Negotiate xxxxx
Cookie: MSOWebPartPage_AnonymousAccessCookie=4458;
WSS_KeepSessionAuthenticated=4458

HTTP/1.0 200 OK
Date: Tue, 17 Apr 2007 20:25:15 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 12.0.0.4518
X-AspNet-Version: 2.0.50727
Set-Cookie: WSS_KeepSessionAuthenticated=4458; path=/
Set-Cookie: MSOWebPartPage_AnonymousAccessCookie=4458; expires=Tue,
17-Apr-2007 20:55:15 GMT; path=/
Set-Cookie:
http%3A%2F%2Fxx%2Exxx%2Exx%2Exxx%3A4458%2FDiscovery=WorkspaceSiteName=xx
x&Wo
rkspaceSiteUrl=xxx&WorkspaceSiteTime=xxx;
expires=Thu, 17-May-2007 20:25:15 GMT; path=/_vti_bin/Discovery.asmx
Cache-Control: private, max-age=0
Expires: Mon, 02 Apr 2007 20:25:15 GMT
Last-Modified: Tue, 17 Apr 2007 20:25:15 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 56318
X-Cache: MISS from xx.xxx.xx.xxx
X-Cache-Lookup: MISS from xx.xxx.xx.xxx:80
Via: 1.0 xx.xxx.xx.xxx:80 (squid/2.6.STABLE12)
Connection: keep-alive

Any suggestions would be appreciated. Thanks.

<comment>The problem is at several levels. The frontpage extensions
require
HTTP1.1. Squid currently doesn't do this but I seem to remember a post a
while ago about a patch in one of the nightly builds.

The next problem is that the session setup to authorisation seems to
require
a series of zero content messages where the header info is part of
session
initiation. It also seems that (and I'm guessing here) that the
frontpage
extensions require the zero content body to be passed as well. I've seen
somewhere info that currently the caching part of the squid code doesn't
cache zero content body messages and that Adrian Chadd was looking at
modifying the code to deal with this. Hope this helps. I haven't had
time to
dig any further.</comment>
Received on Thu Apr 19 2007 - 19:59:03 MDT