On 16.02.2012 03:12, Günter Merz wrote:
Hello,
I'm using squid_kerb_ldap (via external_acl_type) to authenticate via
kerberos and authorize access via ldap groups.
This seems to work. Partly anyway. My problem is:
Most of the traffic is authorized as shown in the access.log file
which shows GETs and CONNECTs using the respective kerberos id
(user@DOMAIN) but some GETs and CONNECTs lack that kerberos id (-)
and
consequently fail (TCP_DENIED).
I tested if an earlier ACL might prevent those transfers from being
allowed by inserting an ACL right before the external_acl_type to
allow all transfers from the host I was using. This didn't show any
TCP_DENIEDs.
Um, of course not. "allow all" will never deny anything. Absolutely
anything is permitted.
I also wondered if the browser could be at fault (not requesting each
GET with the respective kerberos id) so I changed from Firefox to
Chromium. The behaviour was identical.
Can anyone think of a reason for this behaviour or another way to
debug for the cause?
Beyond seeing "TCP_DENIED" when the credentials are missing, What makes
you think there is a fault?
4xx status messages is simply the mechanism HTTP uses for the proxy to
inform the client software about things it needs to do. In this case
adding the credentials to its request. It can (and should) retry
immediately with credentials and get accepted. At best all 4xx status
are minor problems easily corrected in the background by the client.
5xx status are the major errors, only the server admin can fix those.
You also omitted details about what software versions you are dealing
with. It's hard to diagnose a bug fixed in say 2005 without knowing your
software came out in 2002. Likewise to ignore bugs fixed already in your
version.
Amos