> >On Tue, 01 Dec 2009 12:12:52 +1300, Amos Jeffries <squid3@xxxxxxxxxxxxx> >wrote: >> On Mon, 30 Nov 2009 13:38:17 +0100, <vincent.blondel@xxxxxx> 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. -----------------------------------------------------------------
