Amos Jeffries wrote: > On 17/07/18 14:20, Victor Sudakov wrote: > > > > After upgrading to Squid 4.1 (from FreeBSD ports) I started having problems > > with Kerberos authentication. > > > > A user complained about being denied access. The strange things are that: > > > > 1. There was only one such user, others seemed to be authenticating > > properly (or just did not complain). > > > > 2. The user seemed authenticated but still was denied (!), a sample access.log entry: > > > > 1531737712.384 7 212.73.124.190 TCP_DENIED/403 9976 GET http://yandex.ru/zzzzzzzzzzzz user@xxxxxx HIER_NONE/- text/html > > > > The user tried different browsers on different hosts, with the same result. > > > > After downgrading to Squid 3.5.27 all went well again. > > > > Sorry I cannot provide more debugging info at present, I had to > > downgrade my two production Squids ASAP. > > > > Was there any major change between Squid 3 and 4 in the way > > Negotiate/Kerberos works? > > > > The biggest change is that bundled Kerberos auth helpers are now using > the newer v3.4+ helper protocol. That prevents some malformations of > Unicode and whitespace characters in the username or password which > Squid-3 might have been ignoring when it should have rejected. > > You may need to check both what you have on record in your AD/LDAP and > what the affected user thinks they need to enter. If the access.log line (like the one above) contained "user@xxxxxx" where the username and realm name are both correct and match those in the user's AD ticket, doesn't it mean that the Kerberos authentication has been successful ? But for some reason this user was being TCP_DENIED though he was mentioned in the "vip_users.txt" file. acl vip_users proxy_auth_regex -i "/usr/home/sudakov/squid/vip_users.txt" http_access allow sibptus vip_users Why was he receiving a HTTP 403 I wonder? 403 is authorization-related, isn't it ? The username and realm were correct but still a 403. I can reveal both log lines with the real username and realm, in a private mail, if this can help. I can even provide a tcpdump. > > There is also the less likely possibility that other non-auth ACLs are > rejecting the request for completely unrelated reasons. > Hmm. Looks quite the other way around, it looked like this user was being rejected for some non-auth reason. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
