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
