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@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
