RE: [squid-users] Squid/LDAP re-challenges browser on http_access deny

From: Dion Beauglehall <beauglehalld_at_vermontsc.vic.edu.au>
Date: Wed, 7 Oct 2009 16:53:57 +1100

HI,

It works fine for the straight "deny", but I have one acl (from an external helper) which has been designed to be used as an allow list, which (of course), I want to use as a deny. Putting

deny !papercutallow dummy

Seems to just hang squid.....

Thoughts? Suggestions?

In the meantime, I've contacted papercut about whether the external helper can work as a deny group.......

Regards,
Dion

-----Original Message-----
From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Sent: Wednesday, 7 October 2009 2:53 PM
To: Dion Beauglehall
Cc: squid-users_at_squid-cache.org
Subject: RE: [squid-users] Squid/LDAP re-challenges browser on http_access deny

On Wed, 7 Oct 2009 14:23:45 +1100, "Dion Beauglehall"
<beauglehalld_at_vermontsc.vic.edu.au> wrote:
> Hi,
>
> I am now having issues with custom error pages,
>
> I have the deny_info line for the accessdeny acl, but it isn't getting
used
> (I assume because the access deny line finished with all). Eg:
>
> deny_info ERR_ACCESS_DENIED_MISUSE accessdenied
> http_access deny accessdenied all
>
> I have tried removing the "all", but that puts me back into a
re-challenge
> loop (which is why "all" was included).
>
> I am hoping to have a list of denied messages which give instructions to
> the user on the steps required to fix the issue, depending on what reason
> they were denied for. Is there any suggestions someone can offer, or is
> there relevant variables (eg. The acl which denied them) which can be
> passed to an external handler? I'd rather do it with static ERR pages,
but
> whatever works!

Magic voodoo:

acl dummy src all
deny_info ERR_ACCESS_DENIED_MISUSE dummy
http_access deny accessdenied dummy

See how it works? ;)

Amos

>
> -----Original Message-----
> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
> Sent: Monday, 14 September 2009 12:20 PM
> To: Dion Beauglehall
> Cc: squid-users_at_squid-cache.org
> Subject: RE: [squid-users] Squid/LDAP re-challenges browser on
http_access
> deny
>
> On Mon, 14 Sep 2009 12:12:27 +1000, "Dion Beauglehall"
> <beauglehalld_at_vermontsc.vic.edu.au> wrote:
>> Hi Amos,
>>
>> The changes you suggested worked perfectly. Thankyou. What I'm not
> quite
>> sure of is why. I assume in this context, the "all" at the end of the
> line
>> is not acting as a user list, but a URL list or something else?
>
> It's an IP-based test doing a very fast catch-all. This changing the
type
> of ACL last seen at denial so Squid does not equate the deny with
unusable
> credentials and re-challenge.
>
> Amos
>
>>
>> Regards,
>> Dion
>>
>>
>> -----Original Message-----
>> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
>> Sent: Thursday, 10 September 2009 11:30 AM
>> To: squid-users_at_squid-cache.org
>> Subject: Re: [squid-users] Squid/LDAP re-challenges browser on
> http_access
>> deny
>>
>> On Thu, 10 Sep 2009 10:55:58 +1000, "Dion Beauglehall"
>> <BeauglehallD_at_vermontsc.vic.edu.au> wrote:
>>> Hi,
>>>
>>> I’m configuring a squid proxy box with LDAP authentication, and ACLs
>> based
>>> on LDAP groups. I have the LDAP authentication working, as are groups.
>>>
>>> However, when I add a user to an “Access Denied” group, squid then
> causes
>>> the browser to bring up a authentication dialog box. Most squid
> installs
>> I
>>> have seen bring up a squid “Cache Access Denied” screen at this point.
>>> This is what I would like it to do.
>>>
>>> I am unsure if what I am experiencing is expected behaviour, or whether
> I
>>> have an error in my config file.
>>>
>>> I am running Squid 2.7STABLE6 on a Windows 2008 server. Relevant lines
>>> from squid.conf are below. Note that the LDAP works correctly, and so
I
>>> have not provided details. What is not acting as I expected is the
>>> behaviour of Squid when it hits the “http_access deny accessdenied”
> line.
>>
>>> This seems to be what re-challenges the browser.
>>>
>>> As we are a school, we need to ensure that both the user is a valid
user
>>> (from the initial challenge, which collects their machine login,
>> invisible
>>> to the user), and that they have not been denied for some reason (hence
>> the
>>> denied group). The re-challenge will lead to students logging into
> squid
>>> with their friends account. A Cache Access Denied screen is a much
>> better
>>> alternative.
>>
>> Yes it was a config issue.
>> Re-writing your ACLs slightly to follow that exact logic as described
> above
>> should solve your problem.
>>
>>>
>>> Note that once I have this working, there will be other “denied” groups
>> to
>>> deny on, prior to allowing access.
>>>
>>> Any suggestions or ideas are appreciated.
>>>
>>> Regards,
>>> Dion
>>>
>>>
>>> auth_param basic program c:/squid/libexec/squid_ldap_auth.exe ......
>>> auth_param basic children 5
>>> auth_param basic realm VSC
>>> auth_param basic credentialsttl 5 minutes
>>>
>>> external_acl_type ldapgroup &LOGIN ......
>>>
>>> acl ldap-auth proxy_auth REQUIRED
>>>
>>> acl accessdenied external ldapgroup InternetAccessDeny
>>> acl accessallowed external ldapgroup InternetAccess
>>>
>>> http_access deny accessdenied
>>
>> Change the above line to:
>> http_access deny accessdenied all
>>
>> ... which will produce the "Access Denied" page instead of a challenge.
>>
>> Any other denied groups need to go in here one to a line with "all" at
> the
>> end of each line.
>>
>>
>> After all them add a new line:
>> http_access deny !ldap-auth
>>
>> ... which will cause Squid to challenge if no credentials are given yet.
>> People who have given _any_ valid credentials will not be asked twice.
>> This action was being done as side-effect of the accessdenied ACL test,
> but
>> with the new version it needs to be done separately.
>>
>>
>>> http_access allow accessallowed
>>> http_access deny all
>>
>>
>> Amos
>>
>> --- Scanned by M+ Guardian Messaging Firewall ---
>
> --- Scanned by M+ Guardian Messaging Firewall ---

--- Scanned by M+ Guardian Messaging Firewall ---
Received on Wed Oct 07 2009 - 05:54:09 MDT

This archive was generated by hypermail 2.2.0 : Wed Oct 07 2009 - 12:00:02 MDT