If I may add that with some conditions it would be possible to use some network level authentication. Indeed Browsers Clients and Servers do not support intercept and transparent proxy authentication but and a big one, If the network has Clients that uses a single seat per user(IE IP per PC) and have no central terminal service then you can workaround the impossible into possible. You could then allow a users to authenticate a web page and since then to some point of time such as couple seconds to minutes he will be authenticated. In big WIFI networks that works and support radius authentication it is possible to authenticate users against LDAP or AD and the session will be valid for the time that the WIFI session is open.
Another approach which I have implemented in the past was to use some kind of DNS service which systems interacts with as a "registration" DB. A user is logged in and the DHCP registers that a specific user has a specific IP and MAC address(there are couple much secure ways) then when the user authenticate itself using a web page\service the DNS PTR records for the IP is being updated. The proxy has an helper that checks the PTR of the IP and if exists it tells squid what is the username for the request. If not then it would return a missing username. The client authenticate for a specific amount of time and after that the DNS record is expunged. It is similar to the squid sessions helpers but works with another DB.. DNS. Another approach I have seen in products is to install some kind of authentication Daemon per DESKTOP which will extend a 60 seconds authorization and registration every 15-30-45 seconds using the AD or LDAP user. Eliezer ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: elie...@ngtech.co.il -----Original Message----- From: squid-users [mailto:squid-users-boun...@lists.squid-cache.org] On Behalf Of Alex Rousskov Sent: Friday, July 1, 2016 8:45 AM To: squid-users@lists.squid-cache.org Subject: Re: [squid-users] NOTICE: Authentication not applicable on intercepted requests. On 06/30/2016 01:19 PM, Eugene M. Zheganin wrote: > On 30.06.2016 17:04, Amos Jeffries wrote: >> Use a myportname ACL to prevent Squid attempting impossible things like >> authentication on intercepted traffic. > Sorry, but I still didn't get the idea. I have one port that squid is > configured to intercept traffic on, and another for plain proxy > requests. That is OK/normal, of course. > How do I tell squid not to authenticate anyone on the intercept one? By making your authentication rules port-specific. Squid does not authenticate by default so you are explicitly telling it to authenticate [some] users. You need to adjust those rules to exclude intercepted transactions. > From what I know, squid will send the authentication > sequence as soon as it encounters the authentication-related ACL in the > ACL list for the request given. Do have to add myportname ACL with > non-intercepting port for all the occurences of the auth-enabled ACLs, > or may be there's a simplier way ? I do not think there is. We could, in theory, [add an option to] ignore authentication-related ACLs when dealing with intercepted transactions, but I am not sure that doing so would actually solve more problems than it will create. Please note that, in many cases, your myportname ACLs can go at the very beginning of the authentication-sensitive rules to exclude intercepted transactions -- you may not have to prefix each auth-enabled ACL individually (because none of them will be reached after early myportname ACL guards). HTH, Alex. _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
