[squid-users] Update from Squid 4 to Squid 5 :

Tue Dec 13 22:46:16 UTC 2022

Hey,

What is the content of:
/etc/resolv.conf
?

It could be something related to default systemd dns services.

Eliezer
----
Eliezer Croitoru
NgTech, Tech Support
Mobile: +972-5-28704261
Email: ngtech1ltd at gmail.com
Web: https://ngtech.co.il/
My-Tube: https://tube.ngtech.co.il/

-----Original Message-----
From: squid-users <squid-users-bounces at lists.squid-cache.org> On Behalf Of Bertrand Friconneau
Sent: Thursday, 8 December 2022 10:54
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] Update from Squid 4 to Squid 5 :

Hi every one,

I can almost continue this tread

First, thanks for the help.

Amos, I made the changes you suggested, but same result.

I tested the folowings commands :
command : wbinfo -u

Can retrieve the users

command : klist
result : klist: No credentials cache found (filename: /tmp/krb5cc_0)

command : kinit administrateur at STEMARIE-AIZENAY.LOCAL
result : kinit: Ressource unavailable while getting initial credentials

So I tried to test the DNS :
nslookup 8.8.8.8
nslookup www.google.fr

And it fails

My Squid server can ping my local DNS, but that's all. No DNS resolution

In Sylog :
dans syslog :
Dec  7 15:53:01 squid winbindd[797]:   get_kdc_ip_string: get_kdc_list 
fail NT_STATUS_NO_LOGON_SERVERS
Dec  7 15:53:01 squid winbindd[797]: [2022/12/07 15:53:01.693756, 0] 
../../source3/libads/sasl.c:589(ads_sasl_spnego_bind)
Dec  7 15:53:01 squid winbindd[797]:   ads_sasl_spnego_bind: kinit 
succeeded but SPNEGO bind with Kerberos failed for 
ldap/srv-ad2.stemarie-aizenay.local - user[SQUID$], 
realm[STEMARIE-AIZENAY.LOCAL]: No logon servers are currently available 
to service the logon request.

The DNS server is configure in /etc/network/interfaces

The files /etc/hosts and /etc/hostname seem to be well configured

Iptable is not configured, everything is accepted

Any idée ?

Regards

Bertrand Friconneau

Le 10/11/2022 à 14:10, Amos Jeffries a écrit :
> On 10/11/2022 4:50 am, Bertrand Friconneau wrote:
>> Hi Everyone,
>>
>> I've got Squid 4.10 on Ubuntu 20.10 LTS
>>
>> I try to upgrade my server to Ubuntu 22.04 LTS
>>
>> But the users couldn't get internet no more.
>>
>> Here is the log in /var/log/squid/access.log :
>> 1668004454.050      0 172.22.200.1 TCP_DENIED/407 3951 CONNECT 
>> drive.google.com:443 - HIER_NONE/- text/html
>> 1668004454.052      0 172.22.200.1 TCP_DENIED/407 3951 CONNECT 
>> drive.google.com:443 - HIER_NONE/- text/html
>> 1668004454.057      0 172.22.200.1 TCP_DENIED/407 3951 CONNECT 
>> drive.google.com:443 - HIER_NONE/- text/html
>> 1668004454.063      1 172.22.200.1 TCP_DENIED/407 4454 CONNECT 
>> drive.google.com:443 - HIER_NONE/- text/html
>> 1668004454.076     10 172.22.200.1 NONE_NONE/500 0 CONNECT 
>> drive.google.com:443 infoe HIER_NONE/- -
>>
>> And on the client :
>> ERR_TUNNEL_CONNECTION_FAILED
>>
>> According to this page : 
>> https://wiki.squid-cache.org/ConfigExamples/Authenticate/Ntlm
>> The cause is due to challenge-response process of NTLM
>>
>> How can I solve it ?
>>
>> Regards
>>
>> Bertrand Friconneau
>>
>>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------- 
>>
>> Here is my config file of squid :
>>
>> dns_v4_first on
>> visible_hostname squid
>
> Please use an actual FQDN hostname. This is the proxies "visible" 
> hostname - eg sent as the domain name for URLs in error pages etc.
>
>>
>> error_directory /usr/share/squid/errors/French
>
> These days it would be better to use:
>
>   error_default_language fr
>
> or at least
>   error_directory /usr/share/squid-langpack/fr
>
>>
>> auth_param ntlm program /usr/bin/ntlm_auth 
>> --helper-protocol=squid-2.5-ntlmssp
>> auth_param ntlm children 250
>> auth_param ntlm keep_alive off
>>
> ...
>
>> http_access deny !Safe_ports
>>
>> http_access deny CONNECT !SSL_ports
>>
>> http_access allow localhost manager
>
> or maybe limit manager access to administrationzone
>
>> http_access deny manager
>>
>
> custom access policy rules should be down here:
>
>> http_access allow sitebypass
>> http_access deny tor
>> http_access deny url_exe
>
>> http_access allow administrationzone
>> #http_access allow pedagozone
>> #http_access allow xibozone
>
> All these below are of the same ACL type and all "allow" actions.
> Therefore you can combine them into one ACL definition.
>
>> http_access allow informatiquezone
>> http_access allow secuzone
>> http_access allow srvzone
>
>> http_access allow ntlm
>
> What about invalid logins, missing logins etc?
> We highly recommend that the line triggering auth is a "deny" policy 
> to reject all those.
>
>    http_access deny !ntlm
>
> ... then you allow what can be done by logged in accounts.
>
>   http_access allow localnet
> or
>  http_access allow all
>
>
> You may see a behaviour difference with this change to how Squid 
> handles the login.
> After doing it, of the problem continues try to get some debug 
> information from the auth helper to see what it is getting from the 
> client and why that is not being accepted.
>
>
> PS. Since you have Kerberos available, please consider moving away 
> from NTLM to using Negotiate/Kerberos auth. It has both better 
> security and far better performance for the proxy.
>
> Amos
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users