Re: [squid-users] Unusual behaviour when linking ACLs to delay pools

Richard Greaney wrote:
> Hi all
>
> I have a problem so strange it's almost laughable.
>
> I'm trying to set up a site with delay pools, but I only want to
> forward members of a particular Active Directory group to the delay
> pool. I have an authenticator that I have used on countless sites,
> which checks to see whether a given user belongs to an AD group,
> nested or otherwise. When I put a user in this group and use my acl to
> prevent that group from say, accessing a website, it blocks them as
> expected. When I apply that same ACL against the delay pool, however,
> it doesn't send members into the pool. However, if I alter the ACL to
> check for membership of ANOTHER group, then they ARE sent into the
> pool. Confused?

Highly likely that the membership assignment or lookup of the group you
want is not working in the background authentication systems.

>
> Here's my config:
>
> -------------
> external_acl_type ldap_group ttl=70 %LOGIN
> /usr/local/squid/libexec/squid/squid_ldap_group.pl #custom
> authenticator to check for membership of nested AD groups
> auth_param basic program /usr/local/squid/libexec/squid/adauth.pl
> #custom authenticator to verify a user/pass combination are correct
>
> delay_initial_bucket_level 100
> delay_pools 1
> delay_class 1 2
> delay_parameters 1 -1/-1 8000/2048
>
> acl all src 0.0.0.0/0.0.0.0
> acl validusers proxy_auth REQUIRED
> acl badfiles urlpath_regex -i "/etc/squid/badfiles.txt"
> acl throttled external ldap_group Internet-Throttled
> acl inetallow external ldap_group Internet-Allow
> acl inetdisallow external ldap_group Internet-Disallow
>
> delay_access 1 allow throttled
> delay_access 1 deny all
>
> http_access deny throttled badfiles
> --------------
>
> So if I put a user in the group "Internet-Throttled", they won't be
> sent into the pool, but will be prohibited from downloading files in
> the badfiles.txt list. Group membership testing is working for the
> http_access deny, but not for delay_access
> But if I alter the definition of the 'throttled' acl so it refers to
> members of the AD group "Internet-Allow", then all members of that
> group ARE sent to the delay pool
>
> I'm finding it hard to attribute blame anywhere. It seems to be that
> it can't be the authenticator, the group, or the delay pool syntax as
> they all work fine under certain circumstances.
>
> Any advice is greatly welcomed.
>
> Thanks
> Richard

Alternatively...

delay_access is what we call a "fast" group access control.

This category are tested so often on high-speed pathways they can only
use the data immediately available in memory and will not do remote
lookups for auth or external helper results.

They will *sometimes* be able to use cached in-memory results from
previous lookups. So the the "slow" category ACL types are not
prohibited in "fast" category access controls. But they are not
guaranteed to work 100% of the time either.

I suspect your http_access rules are different when testing for the two
groups. In such a way that the "throttled" ACL never gets tested in
http_access (causing its result to be cached for delay_Access).

My favorite hack for pre-caching these types of lookup results for later
use is to test the ACL by itself early in the config with !all tacked on
the end of the line (which prevents the line as a whole matching and
doing the allow/deny).

ie
   http_access deny throttled !all
   http_access deny inetallowed !all

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.6
   Beta testers wanted for 3.2.0.1