[squid-users] Cache-Peer - Negotiate

[Amos Jeffries]

On 22/03/2017 1:26 a.m., Hareesh wrote:
> Hi,
> I am trying to setup Squid as a local HTTP child proxy to a parent/corporate Cisco Ironport WSA proxy. I need help in setting up authentication(Negotiate) to be done automatically from any client who is trying to access internet through the child proxy. So here is what I did.
>    
>    - Installed Squid on Windows machine with the installable given by Diladele v 3.5.24. Configured the service to run with an account (domain\account1) that has admin rights to that machine.   
> 
>    - Got a keytab file for the account and host from our AD Admins. Here is the command run to get the keytab file.   
> 
>             ktpass /princ HTTP/server1.subdomain.domain.com at SUBDOMAIN.DOMAIN.COM/mapuser domain\account1 /crypto all  /pass <password_for_account1> /ptypeKRB5_NT_PRINCIPAL /out account.keytab
>    
>    - Copied that keytab file into etc\squid folder of my Windows installation of Squid.   
> 
>    -    
> 
>    - Set the following configuration in squid.conf.   
> 
> 
> http_port 3128cache_peer <parent_proxy_Ip> parent 80 0 no-query default proxy-only login=NEGOTIATE
> http_access allow allnever_direct allow allicp_access deny all
> dns_nameservers <DNS_IP1>  <DNS_IP2> 127.0.0.1
> My objective is **any allowed client** irrespective of Unix/Windows/domain/non-domain users should be able to reach to internet.

The non-domain users will bite you. Guaranteed. Not being part of the
domain means no credentials, which means no authentication can be performed.

Apart from that either the Negotiate works or it does not. That is
entirely dependent on whether the client has working credentials - which
is outside of Squid control. The particular client OS may reflect
whether that OS has working Kerberos credentials available, but that is
as far as OS comes into the equation.


> I will set up ACL to specify the IP addresses to use this proxy later. But for now, I am getting a 407 error from any machine trying to use this proxy. I am not sure what is going wrong. Please advise.

407 is entirely expected with secure types of authentication. No sane
client will broacast its credentials aross the network without first
being informed that they are necessary - and what type/scheme they have
to be. That takes the form of a 407 or 401.

What is expected is that the client handles that silently and re-tries
immediately with the required credentials. No further 407 *on that TCP
connection*.

The per-TCP connection detail is important. If you have persistent
connections enabled in the proxy you can expect some 407's then abunch
of authenticated traffic without any.

Browsers can open 8 connections _per tab_ on startup each of which has
to be authenticated separately. Other software usually only 1, but can
open ~4. This can result in a burst of 407's on first contact between
any particualr user and the proxy. It should stabilize quickly though,
and all happen quietly without the user being involved.



> I was looking at this link as well.
> Squid - Users - Parent proxy with authentication
> 
>   
> |  
> |   
> |   
> |   |    |
> 
>    |
> 
>   |
> |  
> |   |  
> Squid - Users - Parent proxy with authentication
>  Parent proxy with authentication. Hello, can someone please tell me, what my my cache_peer line must look like, ...  |   |
> 
>   |
> 
>   |
> 

I think you have the sequence reversed. It should be:

 user/client -> Squid -> Cisco -> Interwebs


The config line you have:
  cache_peer <parent_proxy_Ip> parent 80 0 no-query default proxy-only
login=NEGOTIATE

... tells Squid to login *as itself* to the upstream proxy.

That is fine if you want the users to login to Squid (or not for the
non-domain ones), and everything going through the upstream proxy to be
authenticated and logged against the Squid account.
 If so, then add the auth_param lines to verify the credentials Squid is
gettign from users.

For passing through the Negotiate credentials client-to-Cisco, you
should use "login=PASSTHRU connection-auth=on". Squid itself does not
participate in the authentication, so does not need any keytabs etc
setup for those clients.

However, as I mentioned above the non-domain users will bite you. They
dont have credentials so cannot authenticate at all.

With a bit of config trickery, you could use that line with
login=NEGOTIATE to send the Squid proxy account keytab details to get
them through the upstream.

The config trick is how to detect whether the client is off-domain
(dedicated http_port with myportname ACL?) then use cache_peer_access to
split that off-domain traffic through the login=NEGOTIATE peer while
on-domain goes through the login=PASSTHRU peer.

PS. this is just theoretcical config so YMMV.


HTH
Amos