[squid-users] Kerberos issues on 4.1

[Victor Sudakov]

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 at REA.LM 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 at REA.LM"
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