Re: [squid-users] Re: Native Kerberos (squid_kerb_auth) with LDAP-Fallback (squid_ldap_auth)

Hi Amos

Thanks a lot for this explanation. Both configurations seperately -
native kerberos and native ldap - are working fine. But in
combination, there is still one problem.

Here is my actual configuration (combined two mechanism) again:

auth_param negotiate program /usr/local/squid/libexec/squid_kerb_auth -i
auth_param negotiate children 50
auth_param negotiate keep_alive on
external_acl_type SQUID_KERB_LDAP ttl=3600 negative_ttl=3600 %LOGIN
/usr/local/squid_kerb_ldap/bin/squid_kerb_ldap -d -g "InternetUsers"
acl INTERNET_ACCESS external SQUID_KERB_LDAP

external_acl_type SQUID_DENY_KERB_LDAP ttl=3600 negative_ttl=3600
%LOGIN /usr/local/squid_kerb_ldap/bin/squid_kerb_ldap -d -g
"DenyInternetUsers"
acl DENY_INTERNET_ACCESS external SQUID_DENY_KERB_LDAP

# LDAP-Fallback
auth_param basic program /usr/local/squid/libexec/squid_ldap_auth -R
-v 3 -b "dc=xx,dc=yy" -D "cn=binduser,dc=xx,dc=yy" -w "something" -f
"(&(&(objectClass=Person)(sAMAccountName=%s))(memberOf=cn=InternetUsers,DC=xx,DC=yy))"
-c 3 -h ldaps://xx.xx.xx.xx -h ldaps://xx.xx.xx.xx
auth_param basic children 20
auth_param basic realm "Internet Access"
auth_param basic credentialsttl 2 hour
acl INTERNET_ACCESS_LDAP proxy_auth REQUIRED src 0.0.0.0

And here the relevant part of the http_access-directives:
http_access deny DENY_INTERNET_ACCESS
http_access deny !INTERNET_ACCESS
http_access deny !INTERNET_ACCESS_LDAP
http_access allow INTERNET_ACCESS
http_access allow INTERNET_ACCESS_LDAP
http_access deny all

With this configuration, I'm able to access with kerberos, but never
with ldap. I always got a "access denied". What directives do I have
to change/add, to get both accesses (kerberos & ldap)?

Thanks a lot.
Tom

2010/8/10 Amos Jeffries <squid3_at_treenet.co.nz>:
> Tom Tux wrote:
>>
>> Hi Markus
>>
>> Thank you.
>> So, do you know, how I have to implement the fallback-mechnism with
>> squid_ldap_auth?
>
> You already configured it.
>
> When challenging for credentials Squid sends a list of the supported
> authentication protocols. One entry for each auth_param type configured.
> In your case Squid sends: Negotiate, Basic.
>
> The client software is responsible for picking one of those protocol options
> to send the credentials. You cant change its choice other than offering a
> different set or order of auth_param types.
>
> Your access rules as stated do this:
>
>>>> http_access deny DENY_INTERNET_ACCESS
>
> check the authenticated users group.
>  step 1: first challenge to find out who the user *is*.
>  step 2: check the group membership
>  step 3: *maybe* reject if they are in a blocked group.
>
>>>> http_access allow INTERNET_ACCESS
>  step 1: allow if they are a valid logged in user.
>
>>>> http_access allow INTERNET_ACCESS_LDAP
>
>  never used. only invalid users get this far.
>
> ... end of access list. implicit !allow --> access denied.
>
>>
>> For instance, if I deny read-rights for the squid-user to the file
>> /etc/krb5.keytab, I would expect, that the squid_ldap_auth-mechanism
>> would authenticate the user with a password-prompt. But in my case: A
>
> Maybe yes, maybe no.
>
> Squid would re-challenge for all Negotiate credentials indefinitely.
> Constantly offering Negotiate as available but never being able to
> authenticate any of the Negotiate credentials received.
>
>  * Dumb client software would loop infinitely trying to use Negotiate and
> asking the user for new credentials. Since Squid constantly said it was
> available. Infinite popups.
>
>  * Semi-smart client software would move on to the other protocol but
> confuse the credentials (or not having stored them) will ask the user for
> new ones. Single or few Popups *per-page*.
>
>  * Smart client software remembers that they failed to auth with Negotiate
> and move on to send the credentials with Basic. No popup.
>
>
>> password-prompt appears (but not the right one....without the correct
>> realm) and I can enter the correct userid/pw -> no success. If I make
>> a native basic-authentication with squid_ldap_auth (without
>> combination with kerberos), then the authentication works fine.
>>
>> Any hints for the fallback-configuration with squid_ldap_auth? Is
>> there even a way, to have a fallback-mechanism with squid_ldap_auth?
>
> To get things working use this method to setup:
>
>  1) get one of the two auth methods working fully by itself.
>
>  2) comment out those auth_param settings.
>
>  3) setup the other auth method and get it working fully by itself.
>
>  4) undo comments in (2). ordering the auth_param by preferred protocol.
>
>  5) test that the combined setup still fully works.
>
> Hint: for testing groups, its probably best to deny invalid users
> immediately before any of the more complex tests:
>
> A general access config would look something like this:
>
>  # block invalid users
>  http_access deny !INTERNET_ACCESS
>
>  # block users denied access
>  http_access deny DENY_INTERNET_ACCESS
>
>  # allow LAN visitors (NP: already logged in and allowed access)
>  http_access allow localnet
>
>  # allow external users if logged in.
>  http_access allow INTERNET_ACCESS
>  http_access deny all
>
> Amos
> --
> Please be using
>  Current Stable Squid 2.7.STABLE9 or 3.1.6
>  Beta testers wanted for 3.2.0.1
>
Received on Wed Aug 11 2010 - 12:35:47 MDT