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@xxxxxxxxxxxxx>: > 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 >
