[squid-users] help with acl order and deny_info pages

Thu Sep 24 07:30:00 UTC 2015

On Sun, 20 Sep 2015 21:43:26 +1200
Amos Jeffries <squid3 at treenet.co.nz> wrote:

> On 17/09/2015 7:24 p.m., Marko Cupać wrote:
> > On Thu, 17 Sep 2015 03:00:56 +1200
> > Amos Jeffries <squid3 at treenet.co.nz> wrote:
> > 
> >> On 17/09/2015 12:37 a.m., Marko Cupać wrote:
> >>> Hi,
> >>>
> >>> I'm trying to setup squid in a way that it authenticates users via
> >>> kerberos and grants different levels of web access according to
> >>> ldap query of MS AD groups.After some trials and errors I have
> >>> found acl order which apparently does not trigger
> >>> reauthentication (auth dialogues in browsers although I don't
> >>> even provide basic auth).
> >>
> >> What makes you think browser dialog box has anything to do with
> >> Basic auth? All it means is that the browser does not know what
> >> credentials will work. The ones tried (if any) have been rejected
> >> with a challenge response (401/407) for valid ones. It may be the
> >> browser password manager.
> >>
> >> If you are using only Kerberos auth then users enter their Kerberos
> >> username and password into the dialog to allow the browser to fetch
> >> the Kerberos token (or keytab entry) it needs to send to Squid.
> >>
> >>
> >>> Here's relevant part:
> >>>
> >>> http_access deny !Safe_ports
> >>> http_access deny CONNECT !SSL_ports
> >>> http_access allow localhost manager
> >>> http_access deny manager
> >>> http_access deny to_localhost
> >>> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> >>> http_access deny !auth all
> >>> http_access allow !basic_domains !basic_extensions basic_users
> >>> http_reply_access allow !basic_mimetypes basic_users
> >>> http_access allow !advanced_domains !advanced_extensions
> >>> advanced_users http_access allow expert_users all
> >>> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> >>> http_access allow localhost
> >>> http_access deny all
> >>>
> >>> I'd like to know which acl triggered the ban, so I've created
> >>> custom error page:
> >>>
> >>> error_directory /usr/local/etc/squid/myerrors
> >>> deny_info ERR_BASIC_EXTENSION basic_extensions
> >>>
> >>> The problem is that my custom error page does not trigger when I
> >>> expect it to (member of basic_users accessing URL with extension
> >>> listed in basic_extensions) - ERR_ACCESS_DENIED is triggered
> >>> instead. I guess this is because of last matching rule which is
> >>> http_access deny all.
> >>
> >> Perhapse.
> >>
> >> But, basic_extensions is never the last listed ACL in a denial
> >> rule. There is never a deny action associated with the ACL. That
> >> is why the deny_info response template is not being used.
> >>
> >>>
> >>> Is there another way how I can order acls so that I don't trigger
> >>> reauthentication while triggering deny_info?
> >>
> >> Not without the ACL definition details.
> >>
> >> Amos
> > 
> > Hi Amos,
> > 
> > thank you for looking into this. Here's complete squid.conf (I
> > changed just private details such as domain, DN, password etc. in
> > external_acl_type).
> > 
> 
> <snip'ing bits of config not relevant to the answer>
> 
> > auth_param negotiate
> > program /usr/local/libexec/squid/negotiate_kerberos_auth \ -r -s
> > GSS_C_NO_NAME
> <snip>
> > # ldap query for group membership
> > external_acl_type adgroups ttl=60 children-startup=2
> > children-max=10 %LOGIN
> > \ /usr/local/libexec/squid/ext_ldap_group_acl -R \
> <snip>
> 
> 
> These ACLs...
> 
> > # map ldap groups to squid acls
> > acl basic_users external adgroups squid_basic
> > acl advanced_users external adgroups squid_advanced
> > acl expert_users external adgroups squid_expert
> 
> ... to here ...
> 
> 
> <snip>
> > # require proxy authentication
> > acl auth proxy_auth REQUIRED
> 
> ... and the "auth" one will all trigger 407 challenges *if* they are
> the last ACL on the line. Or if there are no credentials of any kind
> given in the request.
> 
> 
> > 
> > # custom error pages
> > deny_info ERR_BASIC_DOMAIN basic_domains
> > deny_info ERR_ADVANCED_DOMAIN advanced_domains
> > deny_info ERR_BASIC_EXTENSION basic_extensions
> > deny_info ERR_ADVANCED_EXTENSION advanced_extensions
> > 
> <snip>
> > # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> > http_access deny !auth all
> 
> Problem #1:
>  Any client with halfway decent security will not simply broadcast
> credentials on their first request of a new TCP connection, but will
> wait for a 407 challenge to indicate both their need and the type of
> credentials to send.
> 
> The "all" on this line will prevent that 407 happening. Instead it
> will simply produce a plain 403 ERR_ACCESS_DENIED for any request
> lacking (Kerberos) credentials.
> 
> NP: you can test whether this is your problem with a custom error
> page:
> 
>  acl test1 src all
>  deny_info 499:ERR_ACCESS_DENIED test1
>  http_access deny !auth test1
> 
> Your access.log should show the 499 status when its line matches.
> 
> 
> > http_access allow !basic_domains !basic_extensions basic_users
> > http_access allow !advanced_domains !advanced_extensions
> > advanced_users
> 
> Basically okay. These will trigger 407 *if* (and only if) the client
> sent Negotiate/Kerberos credentials AND does not have group permission
> to access the URL being requested.
> 
> Be aware this will probably produce the popups allowing users to
> change their credentials to those of another user account with the
> right group access. That may or may not be what you want.
> 
> 
> I usually find that *these* lines are the ones people most want not to
> popup. You have complex ACL tests so the order can be shuffled to
> this:
> 
>   http_access allow !basic_domains basic_users !basic_extensions
>   http_access allow !advanced_domains
> advanced_users !advanced_extensions
> 
> Which prevents the popups from group checking.
> 
> If you still want to retain the helper load reduction from having the
> extension test first, then append " all" to each of those lines
> instead of shuffling.
> 
> 
> > http_access allow expert_users all
> 
> 
> > # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
> > http_access allow localhost
> > http_access deny all
> > 
> 
> Problem 2:
> 
> Requests which somehow happen to get past the "deny !auth all" rule
> but not have a domain listed in your *_domains ACLs or _do_ match the
> paired *_extensions ACLs - will get denied by this final rule.
> 
> NP: you can test that like the earlier test, but use a different ACL
> name and 49x status code.

Amos,

I'm grateful for your help, but I'm even more confused now. I
changed http_access rules according to your advices, tried
different combinations, but I still can't achieve intended
behaviour. Perhaps I could try to better explain my goals, as maybe
there is a better way to solve what I'm trying to achieve.

I want to have 4 levels of web access:
expert access - if user is part of expert_users ad group
advanced access - if user is part of advanced_users AD group
basic access - if user is part of basic_users AD group
no access - if user is not part of any AD groups

Here's the difference in web access for groups:
expert access - allow all
advanced access - allow except some extensions and domains
basic access - allow except some more extensions and domains
no access - allow nothing

When a user is redirected to error page, there should be enough info
about error:
- user as seen by squid (or no user if not authenticated)
- group as seen by squid (or no group)
- acl that triggered the ban (not the last deny rule)

I'd really appreciate exact snippet of squid.conf which accomplishes
that, if possible.

Thank you in advance,
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/