On 11/04/2014 10:18 p.m., Kein Name wrote: > > > Amos Jeffries schrieb: >>> Config: >>> cache_peer 10.1.2.3 parent 8000 0 no-query originserver login=PASS >>> >> >> This is a origin server peer. The header delivered to it is >> WWW-Authenticate. Proxy-Authenticate is invalid on connections to origin >> servers. >> >> Is your proxy a reverse-proxy or a forward-proxy? >> > > > It is a reverse proxy. > Okay. In which case Squid is operating as an origin itself. As in; working solely on the WWW-Authenticate header and you can switch all my earlier mentions of Proxy-Auth header to WWW-Auth. > >> Which of the servers (your proxy or the origin) is validating the >> authentication? >> >> > > The origin server. > That might explain why %ul is not working. %ul is the username from login authenticated / validated by the proxy. If the proxy is not validating the authentication itself, then you only have access to the username via an external ACL helper partially decoding the auth header token and returning the username found to Squid. That value appears in either %un "any user name/label known" or %ue "user=X kv-pair from external ACL helper" > >>> The config seems to work, squid shows me the login dialog of the >>> cache_peer. For several reasons I have to feed the username back as a >>> header value.... >>> I also tried login=PASSTHRU for testing, but without any difference. >> >> FWIW: >> * "PASSTHRU" sends the received Proxy-Authenticate header (if any) >> through to the peer untouched. Leaving no header if none provided by the >> client. For NTLM on a reverse-proxy with the origin performing authenticate is exactly why this PASSTHRU was created. You *may* also need the connection-auth=on option to be set on both the http_port directive and the cache_peer directive since authentication is not enabled in the proxy. End-to-end connection pinning required by NTLM should be enabled automatically when the WWW-Authenticate:NTLM is sighted, but these ensure that it is working anyway. >> >> * "PASS" tries to convert credentials to Basic auth and deliver to the >> peer in Proxy-Authenticate. Will try to generate a header from any >> available other sources of credentials if none are provided by the client. >> >> In both of the above the peer being an origin treats them as not having >> www-Authenticate header (naturally) and responds with a challenge to get >> some. >> >> > > The origin peer creates the "WWW-Authenticate: NTLM" request upon which > the rev proxy shows the user/password popup request. > The Rev Proxy then replies with a "Authorization: NTLM > TlRMTVNTUAADAAAAGAAYAGYAAADuAO4A [...]" Header. > So I think PASS is OK, as nothing seems to be converted from NTLM... > Or am I wrong? By "proxy" I hope you mean these details are coming from the client and being passed on as-is by the proxy? Amos
