RE: [squid-users] squid 2.7 with auth passthrough

>
>On Tue, 01 Dec 2009 12:12:52 +1300, Amos Jeffries
<squid3_at_treenet.co.nz>
>wrote:
>> On Mon, 30 Nov 2009 13:38:17 +0100, <vincent.blondel_at_ing.be> wrote:
>>>> Hello,
>>>>
>>>> Can somebody say me if WWW-Authenticate header is really functional
on
>>>> Squid 2.7.4 because I spent the whole day trying to help one
business
>>>> user with his application and always receive 401 error code.
>>
>> Yes the WWW-Authenticate header is functional. Squid by default
simply
>> passes it from the receiving connection to the sending connection
>without
>> change.
>>
>> The method of authentication using it may not be able to cope with
>> stateless HTTP behaviour.
>>
>>>>
>>>> my proxy should reach the origin IIS server directly next to the
>>>> always_direct/never_direct definitions and this is what I see in
the
>>>> logs. this does not work so I also made a special cache_peer
>>> definition
>>>> and tried with or without connection-auth=on, connection-auth=off
.. I
>>>> also tried with login=PASS but nothing works ...
>>>>
>>>> so my question is .. Is that a normal behaviour ? Do I do something
>>>> wrong ? Do I have to do something else ?
>>
>> Is the IIS server trying to do NTLM login across the web? This can be
a
>> major headache.
>>
>> NTLM and NTLM-like authentication assume end-to-end stateful
>connectivity.
>> This works okay when only stateful NAT or a hacked-up proxy is being
>used.
>> But fails if even one hop across the network is stateless.
>>
>> For NTLM and Negotiate you need both cache_peer options
>> "connection-auth=on login=PASS"
>
>Nearly forgot: If regular proxy authentication is also being used the
>"originserver" setting cannot be used with NTLM cache_peer pass-thru.
>
>>
>> Along with:
>> client_persistent_connections on
>> server_persistent_connections on
>>
>> NP: if you added "no-connection-auth" to http_port it needs to be
>absent.
>>
>> You may also want to raise the connection timeout
>> "persistent_request_timeout" but do so carefully, since each pconn
held
>in
>> a locked state by NTLM is N less client connections usable in
parallel.
>>

first of all many thks for your reply :-)

I made the settings and more proposed, here my conlusions ...

When I remove originserver the connection breaks immediatelly with "page
cannot be displayed"

When I set originserver forceddomain and connection-auth, sometimes it
works, sometines NOT .... when it fails the client also receives a "page
cannot be displayed"

so the normal working of the application prompts the user a first time
for credentials, this seems to work, the user can use the application
and when he wanna click on a specific button, it works and not depending
on what ?

Below you get the last lines of the squid logging but I wonder to not
always see the PARENT 10.66.125.102 but also NONE/ ???????

1259769370.111 20 10.67.229.216 TCP_MISS/304 466 GET
http://services.group.intranet/rec/Images/status1.gif - NONE/- -
1259769370.303 14 10.67.229.216 TCP_MISS/401 3016 GET
http://services.group.intranet/rec/images/open_detail.gif -
FIRST_UP_PARENT/10.66.125.102 text/html
1259769370.355 6 10.67.229.216 TCP_MISS/401 3301 GET
http://services.group.intranet/rec/images/open_detail.gif - NONE/-
text/html
1259769370.373 17 10.67.229.216 TCP_MISS/304 466 GET
http://services.group.intranet/rec/images/open_detail.gif - NONE/- -
1259769377.543 13 10.67.229.216 TCP_MISS/401 3016 POST
http://services.group.intranet/rec/Forms/BasicSkeleton.aspx?Nav=RequestA
bsence - NONE/- text/html
1259769377.589 10 10.67.229.216 TCP_MISS/401 3301 POST
http://services.group.intranet/rec/Forms/BasicSkeleton.aspx?Nav=RequestA
bsence - NONE/- text/html
1259769377.692 102 10.67.229.216 TCP_MISS/200 130429 POST
http://services.group.intranet/rec/Forms/BasicSkeleton.aspx?Nav=RequestA
bsence - NONE/- text/html
1259769381.417 18 10.67.229.216 TCP_MISS/401 541 POST
http://services.group.intranet/rec/Forms/BasicSkeleton.aspx?Nav=RequestA
bsence - FIRST_UP_PARENT/10.66.125.102 text/html

the POST in the last line just above is the query giving problems at
time to time

below the current config

client_persistent_connections on
server_persistent_connections on
acl protime url_regex -i ^http://services.group.intranet/rec
acl protime_src src 10.67.229.216
cache_peer 10.66.125.102 parent 80 0
forceddomain=services.group.intranet originserver proxy-only no-query
no-digest connection-auth=on login=PASS
cache_peer_access 10.66.125.102 allow protime
cache_peer_access 10.66.125.102 deny all
always_direct deny protime
never_direct allow protime

we are very closed to get a full final working solution but seems to
miss something else .... any idea ??

>
>Amos
>
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------
ING Belgium SA/nv - Bank/Lender - Avenue Marnix 24, B-1000 Brussels, Belgium - Brussels RPM/RPR - vat BE 0403.200.393 - BIC (SWIFT) : BBRUBEBB - Account: 310-9156027-89 (IBAN BE 45310-9156027-89).
An insurance broker, registered with the Banking, Finance and Insurance Commission under the code number 12381A.

ING Belgique SA - Banque/Preteur, Avenue Marnix 24, B-1000 Bruxelles - RPM Bruxelles - tva BE 0403 200 393 - BIC (SWIFT) : BBRUBEBB - Compte: 310-9156027-89 (IBAN: BE 45310-9156027-89).
Courtier d'assurances inscrit a la CBFA sous le no 12381A

ING Belgie nv - Bank/Kredietgever - Marnixlaan 24, B-1000 Brussel - RPR Brussel - btw BE 0403.200.393 - BIC (SWIFT) : BBRUBEBB - Rekening: 310-9156027-89 (IBAN: BE45 3109 1560 2789).
Verzekeringsmakelaar ingeschreven bij de CBFA onder het nr. 12381A.
-----------------------------------------------------------------
Received on Wed Dec 02 2009 - 17:33:25 MST