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: ngtech1...@gmail.com Web: https://ngtech.co.il/ My-Tube: https://tube.ngtech.co.il/ -----Original Message----- From: squid-users <squid-users-boun...@lists.squid-cache.org> On Behalf Of Bertrand Friconneau Sent: Thursday, 8 December 2022 10:54 To: squid-users@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@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@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users