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

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