Hi, thanks for your message.
Not working yet. Please check where is my mistake.
I implemented a custom external ACL that checks on active directory via
ldap if a user is member of a particular group. If success returns:
OK group=Internet_Access
Else returns:
ERR
Squid.conf:
http_port 3128
auth_param basic program /usr/lib/squid/basic_ldap_auth -v 3 -b
dc=lab-novo,dc=br,dc=local -R -D
cn=ldap_proxy,ou=gestao_proxy,dc=lab-novo,dc=br,dc=local -w xxx -f
"sAMAccountName=%s" -u uid -P 10.0.0.1:389
acl login proxy_auth REQUIRED
http_access deny !login
external_acl_type group ttl=360 ipv4 %LOGIN /ext_danilo_ldap_group.sh
acl some_group external group Internet_Access
acl groupInternet note group Internet_Access
delay_pools 1
delay_class 1 1
delay_parameters 1 128000/128000
delay_access 1 allow groupInternet
Sqstat confirms that the bandwidth is not being limited.
Date: Wed, 17 Oct 2018 16:38:03 +1300
From: Amos Jeffries <***@treenet.co.nz>
To: squid-***@lists.squid-cache.org
Subject: Re: [squid-users] Delay pools and external acl
Message-ID: <c672c10a-e18f-8f4b-325b-***@treenet.co.nz>
Content-Type: text/plain; charset=utf-8
Post by Danilo VHi all,
Has anyone succeeded applying delay pools on groups from AD?
I'm using squid 3.5.23 with basic_ldap_auth.
I initially tried to combine mapping groups with external acl type
(ext_ldap_group_acl) to delay pools. It's a trap :-(
A trap?
For starters; "group" is an abstract concept buried in the depths of
authentication which has nothing to do with traffic. It is a purely
human scoping idea. Squid knows nothing of any "group".
The external ACL type which handles such complex non-traffic things is
clearly listed in the Squid FAQ (and the 'acl' directive documentation)
as being a "slow" / async ACL type.
Delay pools is also clearly listed as an access control which only works
with "fast" category ACL types.
<https://wiki.squid-cache.org/SquidFaq/SquidAcl#Fast_and_Slow_ACLs>
Post by Danilo VAfter doing more search I found about class 5 and note acl.
Has anyone a pratical implementation in this scenario?
Yes several admin have done so. But with custom helpers that integrate
with the new annotation system, or the Kerberos helpers that have been
upgraded to integrate as well. Other helpers have not been updated yet.
Your external ACL just needs to supply Squid with a "tag=XX" or
"group=XX " annotation to label the transaction with whichever group
matches.
# login is required to do group checking...
acl login proxy_auth REQUIRED
http_access deny !login
# the decision to allow the traffic into the proxy does group checks
and adds annotations...
external_acl_type group %LOGIN ...
acl some_group external group XX
http_access allow some_group_check
# the decision of what pool(s) to apply has to work FAST - so uses the
annotations already present or not present) as its decider:
acl groupXX note group XX
# or for older Squid
acl groupXX note tag XX
delay_access N allow groupXX
Amos