[squid-users] Kerberos issues on 4.1

[Victor Sudakov]

Amos Jeffries 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 ?
> 
> It means the authentication helper provided a user label for logging.

Fine, if the same user label is sufficient to authenticate/authorize a
user in Squid 3.5, why is it not sufficient in Squid 4.1? 

I did not touch the config during the upgrade and downgrade.


> > 
> > 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.
> 
> Yes, exactly so. authenticate != authorized.

Please see above.
The user with this label *is* authorized by the "http_access allow sibptus vip_users" line.

> 
> What is the sibptus definition? 

acl sibptus src 212.73.124.190/32
acl sibptus src 212.73.125.240/28

All users use the same outside adresses.

> and what other http_access rules do you
> have after that line?

The complete list:

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow cisa_servers
http_access deny badsites                                                     
http_access deny ads
http_access deny private                                                      
http_access allow sibptus business
http_access allow authenticated_sibptus ecology
http_access allow sibptus vip_users
http_access allow sibptus mailservers mail_users
http_access allow localhost
http_access deny all

The unfortunate user is in the 

acl vip_users proxy_auth_regex -i "/usr/home/sudakov/squid/vip_users.txt"

If there were an option to debug which "http_access" line rejects him
I could try it.


-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
AS43859