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
