Re: [squid-users] Re: Native Kerberos (squid_kerb_auth) with LDAP-Fallback (squid_ldap_auth)
On 09/17/2010 03:28 PM, Amos Jeffries wrote: Squid does not currently offer any way to selectively pick the auth methods to advertise. There are a few possible designs and someone was working on it a while back. Offering a specific authentication method for a defined network would be a nice feature, don't you think? ;-) Stripping away auth methods which have failed is not possible. Due to the problems of: How do you deal with a user typo'd in their password? or who recently changed password but the browser still sends the old one first?. Ok, you are of course right, it sounds complicated. But isn't there a basic-fallback mechanism for Kerberos/NTLM? Does this only work if there is a technical error with either Kerberos or NTLM? Or is it a client thing which has to pick the basic mechanism? The workaround that comes to mind is to run a "shell" squid instance for each client or at lest for each primary auth type which only does auth then funnels requests through to some parent proxy for handling. We are currently running 4 separate squid instances (each on it's own IP address, all of them share common acl-files, each has it's own independent cache) on any of two real servers (because Squid 3.1.x is not SMP capable), we could dedicate two of them for LDAP-only with an own VIP-address(loadbalancer is taking care of that) and the two others per server for NTLM. I am not happy with that setup, but there are not many other possibilities. I have no idea how the instances will share the resources, I would prefer 4 instances which share all requests instead of 2 for handling LDAP and 2 for handling NTLM-requests. Could lead to performance issues. Anyway, thanks for your response, Squid is a great piece of software! regards Peter
Re: [squid-users] Re: Native Kerberos (squid_kerb_auth) with LDAP-Fallback(squid_ldap_auth)
Perhaps you could install a separate squid at their sites, which in turn, routes through yours, dependant on the "inter-networking" topology between sites? - Chad E. Naugle Tech Support II, x. 7981 Travel Impressions, Ltd. >>> Amos Jeffries 9/17/2010 9:28 AM >>> On 18/09/10 00:14, guest01 wrote: > Hi, > > I am stuck with a similar problem, has there been any solution for > this topic? (Btw, I am running Squid 3.1.8 on RHEL5.5) > > We are trying to achieve following: > CompanyA (us): own Active Directory domain and we are hosting the > squid web server (central forward proxy for internet access with ICAP > capabilities) > CompanyB: completely independent Active Directory Domain > (CompanyC: might use our squid soon) > (CompanyD: might use our squid soon) > > We have one shared squid server which should authenticate CompanyA > with NTLM (or kerberos) and CompanyB with LDAP (they insist on LDAP, I > don't know why, but I suppose without a domain trust I could > authenticate only one company with NTLM or kerberos and would have > troubles, right?) > NTLM is the prefered authentication method and if a Client of CompanyA > wants to lookup something in the Internet, he will be authenticated > with NTLM. > If CompanyB wants to lookup something, the Browser submits NTLM data > (valid for their domain, not ours) which are not valid for our domain > and in theory, the browser should try Basic-Authentication (e.g. LDAP) > next, but that does not happen. It still tries NTLM (Firefox as well > as IE8 on Windows 7). For further infos, look at [1],[2]. > > Unfortunately, I don't have much options: > - disable ntml authentication in IE8 for CompanyB and then IE only > tries LDAP which works > - authenticate CompanyA by IP and disable NTML authentication (= our > current setup) > > Of course it would be possible to authenticate everybody by LDAP (we > are using a OpenLDAP metadirectory which talks to the ADs), but it is > only a Basic auth and a very bad idea > > Has anybody any additional idea? How do you guys handle authentication > for multiple independent customers? > > In my opinion, this is a client problem, unfortunately IE and even FF > are too dumb. From a functional perspective of view, it should be > standard to try the weaker (LDAP) authentication if the stronger > (NTLM) does not work (from a security perspective of view, I am glad > that this does not seem to work ;-)). Is there any option for the > squid to track authentication and only offer basic authentication if > ntlm failed [3]? Or anything similar? > > I would appreciate any response! > best regards > Peter Squid does not currently offer any way to selectively pick the auth methods to advertise. There are a few possible designs and someone was working on it a while back. Stripping away auth methods which have failed is not possible. Due to the problems of: How do you deal with a user typo'd in their password? or who recently changed password but the browser still sends the old one first?. The workaround that comes to mind is to run a "shell" squid instance for each client or at lest for each primary auth type which only does auth then funnels requests through to some parent proxy for handling. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.8 Beta testers wanted for 3.2.0.2 Travel Impressions made the following annotations - "This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you."
Re: [squid-users] Re: Native Kerberos (squid_kerb_auth) with LDAP-Fallback (squid_ldap_auth)
On 18/09/10 00:14, guest01 wrote: Hi, I am stuck with a similar problem, has there been any solution for this topic? (Btw, I am running Squid 3.1.8 on RHEL5.5) We are trying to achieve following: CompanyA (us): own Active Directory domain and we are hosting the squid web server (central forward proxy for internet access with ICAP capabilities) CompanyB: completely independent Active Directory Domain (CompanyC: might use our squid soon) (CompanyD: might use our squid soon) We have one shared squid server which should authenticate CompanyA with NTLM (or kerberos) and CompanyB with LDAP (they insist on LDAP, I don't know why, but I suppose without a domain trust I could authenticate only one company with NTLM or kerberos and would have troubles, right?) NTLM is the prefered authentication method and if a Client of CompanyA wants to lookup something in the Internet, he will be authenticated with NTLM. If CompanyB wants to lookup something, the Browser submits NTLM data (valid for their domain, not ours) which are not valid for our domain and in theory, the browser should try Basic-Authentication (e.g. LDAP) next, but that does not happen. It still tries NTLM (Firefox as well as IE8 on Windows 7). For further infos, look at [1],[2]. Unfortunately, I don't have much options: - disable ntml authentication in IE8 for CompanyB and then IE only tries LDAP which works - authenticate CompanyA by IP and disable NTML authentication (= our current setup) Of course it would be possible to authenticate everybody by LDAP (we are using a OpenLDAP metadirectory which talks to the ADs), but it is only a Basic auth and a very bad idea Has anybody any additional idea? How do you guys handle authentication for multiple independent customers? In my opinion, this is a client problem, unfortunately IE and even FF are too dumb. From a functional perspective of view, it should be standard to try the weaker (LDAP) authentication if the stronger (NTLM) does not work (from a security perspective of view, I am glad that this does not seem to work ;-)). Is there any option for the squid to track authentication and only offer basic authentication if ntlm failed [3]? Or anything similar? I would appreciate any response! best regards Peter Squid does not currently offer any way to selectively pick the auth methods to advertise. There are a few possible designs and someone was working on it a while back. Stripping away auth methods which have failed is not possible. Due to the problems of: How do you deal with a user typo'd in their password? or who recently changed password but the browser still sends the old one first?. The workaround that comes to mind is to run a "shell" squid instance for each client or at lest for each primary auth type which only does auth then funnels requests through to some parent proxy for handling. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.8 Beta testers wanted for 3.2.0.2
Re: [squid-users] Re: Native Kerberos (squid_kerb_auth) with LDAP-Fallback (squid_ldap_auth)
Hi, I am stuck with a similar problem, has there been any solution for this topic? (Btw, I am running Squid 3.1.8 on RHEL5.5) We are trying to achieve following: CompanyA (us): own Active Directory domain and we are hosting the squid web server (central forward proxy for internet access with ICAP capabilities) CompanyB: completely independent Active Directory Domain (CompanyC: might use our squid soon) (CompanyD: might use our squid soon) We have one shared squid server which should authenticate CompanyA with NTLM (or kerberos) and CompanyB with LDAP (they insist on LDAP, I don't know why, but I suppose without a domain trust I could authenticate only one company with NTLM or kerberos and would have troubles, right?) NTLM is the prefered authentication method and if a Client of CompanyA wants to lookup something in the Internet, he will be authenticated with NTLM. If CompanyB wants to lookup something, the Browser submits NTLM data (valid for their domain, not ours) which are not valid for our domain and in theory, the browser should try Basic-Authentication (e.g. LDAP) next, but that does not happen. It still tries NTLM (Firefox as well as IE8 on Windows 7). For further infos, look at [1],[2]. Unfortunately, I don't have much options: - disable ntml authentication in IE8 for CompanyB and then IE only tries LDAP which works - authenticate CompanyA by IP and disable NTML authentication (= our current setup) Of course it would be possible to authenticate everybody by LDAP (we are using a OpenLDAP metadirectory which talks to the ADs), but it is only a Basic auth and a very bad idea Has anybody any additional idea? How do you guys handle authentication for multiple independent customers? In my opinion, this is a client problem, unfortunately IE and even FF are too dumb. From a functional perspective of view, it should be standard to try the weaker (LDAP) authentication if the stronger (NTLM) does not work (from a security perspective of view, I am glad that this does not seem to work ;-)). Is there any option for the squid to track authentication and only offer basic authentication if ntlm failed [3]? Or anything similar? I would appreciate any response! best regards Peter additional infos: [1] http://img830.imageshack.us/img830/3920/squidntlmnotworking.png [2] squid config: #NTLM auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp auth_param ntlm children 5 auth_param ntlm keep_alive on # LDAP authentication auth_param basic children 5 auth_param basic realm Proxy auth_param basic credentialsttl 120 minute auth_param basic program /opt/squid/libexec/squid_ldap_auth -b "dc=squid-proxy" -D "uid=user" -w passwd -h server -f "(uid=%s)" [3] Tcpdump show me the header with following infos (squid offers ntlm and basic): GET http://fxfeeds.mozilla.com/en-US/firefox/headlines.xml HTTP/1.1 Host: fxfeeds.mozilla.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Proxy-Connection: keep-alive X-Moz: livebookmarks HTTP/1.0 407 Proxy Authentication Required Server: squid/3.1.8 Mime-Version: 1.0 Date: Fri, 17 Sep 2010 10:09:12 GMT Content-Type: text/html Content-Length: 1482 X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0 Vary: Accept-Language Content-Language: en-us Proxy-Authenticate: NTLM Proxy-Authenticate: Basic realm="Proxy" X-Cache: MISS from xlsqip02_1 Via: 1.0 xlsqip02_1 (squid/3.1.8) Connection: keep-alive On Fri, Aug 13, 2010 at 4:01 PM, Tom Tux wrote: > Hi > > I run squid with the named debug-options. The "cache.log"-output seems > a little bit complicated. So the only way I see, is to have a remarked > native ldap-authentication-configuration, which I can enable, if the > kerberos-mechanism fails. > > Or does somebody has such a config (kerberos with squid_kerb_ldap to > get ad-groups AND squid_ldap_auth with a memberOf-filter) running? > > Thanks a lot. > Regards, > Tom > > 2010/8/11 Amos Jeffries : >> Tom Tux wrote: >>> >>> 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 SQUI
Re: [squid-users] Re: Native Kerberos (squid_kerb_auth) with LDAP-Fallback (squid_ldap_auth)
Hi I run squid with the named debug-options. The "cache.log"-output seems a little bit complicated. So the only way I see, is to have a remarked native ldap-authentication-configuration, which I can enable, if the kerberos-mechanism fails. Or does somebody has such a config (kerberos with squid_kerb_ldap to get ad-groups AND squid_ldap_auth with a memberOf-filter) running? Thanks a lot. Regards, Tom 2010/8/11 Amos Jeffries : > Tom Tux wrote: >> >> 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 > > The "src" and "0.0.0.0" usernames (yes *usernames*) should be ignored by > Squid. > >> >> >> 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)? > > Run Squid with "debug_options 82,3 28,3" to check which ACLs are matching > and which denying. > > I notice the !INTERNET_ACCESS is required to pass before anything is > allowed. It could be that your Basic protocol credentials are not being > accepted by the Negotiate/Kerberos protocol group helper and inverting into > a deny. > > Amos > -- > Please be using > Current Stable Squid 2.7.STABLE9 or 3.1.6 > Beta testers wanted for 3.2.0.1 >
Re: [squid-users] Re: Native Kerberos (squid_kerb_auth) with LDAP-Fallback (squid_ldap_auth)
Tom Tux wrote: 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 The "src" and "0.0.0.0" usernames (yes *usernames*) should be ignored by Squid. 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)? Run Squid with "debug_options 82,3 28,3" to check which ACLs are matching and which denying. I notice the !INTERNET_ACCESS is required to pass before anything is allowed. It could be that your Basic protocol credentials are not being accepted by the Negotiate/Kerberos protocol group helper and inverting into a deny. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.6 Beta testers wanted for 3.2.0.1
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 : > 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 onewithout 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
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 onewithout 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
Re: [squid-users] Re: Native Kerberos (squid_kerb_auth) with LDAP-Fallback (squid_ldap_auth)
Hi Markus Thank you. So, do you know, how I have to implement the fallback-mechnism with squid_ldap_auth? 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 password-prompt appears (but not the right onewithout 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? Thanks a lot. Kind regards, Tom 2010/8/9 Markus Moeller : > Hi Tom, > > squid_kerb_ldap does not authenticate a user. It just looks up membership > info and can not replace squid_ldap_auth > > Markus > > "Tom Tux" wrote in message > news:aanlktimybsvmrsy7a7mhbaazvfv63wdfux1i5wd6t...@mail.gmail.com... >> >> Hi >> >> I've implemented a native kerberos-authentication with squid_kerb_auth >> and squid_kerb_ldap to query ad-group-memberships. This works fine. >> I'm trying to implement a fallback-mechanism with squid_ldap_auth. >> >> But the squid_ldap_auth-fallback is not working. My config looks like >> this: >> 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 >> >> http_access deny DENY_INTERNET_ACCESS >> http_access allow INTERNET_ACCESS >> http_access allow INTERNET_ACCESS_LDAP >> >> >> >> How do I have to implement the fallback-ldap? Do I need the >> "external_acl"-directive? Can I realise the fallback-mechanism also >> with squid_kerb_ldap? >> >> Thanks a lot. >> Kind regards, >> Tom >> > > >
