On 18/08/2015 8:00 p.m., L.P.H. van Belle wrote: > Hai Amos, > > Thank you for your very clear responce.. few small questions.. > > Is there a way to setup the proxy for the following. > 1) use negotiate kerberos for auth, ( which is working already for all domain joined machines ) > 2) use a fall back that works, for now basic ldap works for non windows machines, and domain joined machines. > 3) use any other fallback way for authentication users on windows machines, that are not in the domain. > and without modify-ing anything in windows. as these are often guest machines. All Squid can do is offer mechanisms. The client is required to respond using the most secure that it can use. Configuring auth schemes in this order: auth_param negotiate program ... auth_param basic program ... Should meet your needs almost all the time. But it really depends on the client following either the specs or your offered order. Not all do. And some think "Negotiate" means "Negotiate/NTLM", and/or try that before Negotiate/Kerberos. > > Is a link to a radius server an option, dont have a radus jet, but can be installed. > and radius is also comming for my wifi authentication. > whould that fix my problem (3) above, in a authentication fallback setup. Basic auth RADIUS helper can use RADIUS as an authentication backend. Other than that I'm not familiar with it. > >> One puzzling thing is why Win7 client is trying to use NTLM in >> the first >> place. NTLM is disabled by default in Vista and later due to >> its lack of >> security. >> >> Try adding "auth_param negotiate keep_alive off" to close connections >> when Negotiate/NTLM is used and force the client to retry with other >> auth credentials on a clean connection. > > these : >>> auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth -s HTTP/hostname.fqdn@REALM > and >>> auth_param negotiate program /usr/local/bin/negotiate_wrapper > These lines, work both for negotiate kerberos. > The last, when useing : /usr/local/bin/negotiate_wrapper was tested with the parameter > negotiate keep_alive off. > > Above works fine with the domain joined pc, but not with the "non domain joined" PC. > the negotiate kerberos works very good, but the fall back not. ( as you explained ) > > I found that if i setup with only basic_ldap_auth, against the AD, then i can use both, > domain joined and not domain joined, but the first time it always gives a popup for authenticating. Take a look and see what its sending for Basic auth credentials on first try. You may need to use a Basic auth helper that allows stripping the @DOMAIN part off the credentials received. I think some systems send the user@DOMAIN in Basic with the machine name as DOMAIN. That wont work against any real DC server. > If once authenticated, it keeps it authenticated, aka windows/IE keeps the login and password. > even if i clear the history. For NTLM or Negotiate credentials being used. Then credentials once authenticated are tied permanently to the TCP connection(s) they were used on. You have to fully close all the affected TCP connections to "logout". The only reliable way to do that is shutdown the whole browser. For Basic auth credentials being used. They are only accepted so long as the auth backend keeps accepting them. HTTP actually requires the browser/client to send credentials on every single request. Squid checks these against the ones it seen being valid before, or once every credentialsttl timeout it re-checks fully against the backend server. > > Why i dont want this... > If a user is logging in the domain, and kerberos auth is used, then when going on internet, > the "correct" aka logged in user, is always used. > but when i use basic_ldap_auth, then it gives the user to put in an other username/password at popup, > then it remembers the login and a user now is internetting with an other users name. > > So, when im right, a fallback for all is not possible, due to NTLM auth? > I dont see where NTLM comes into that. >From your description fallback authentication *is* working. But with users able to send credentials that you dont want to allow their use of. That is a different (authorization) problem to solve. By authenticating successfully the user is "proving" that they are who they claim to be. Although Basic auth could possibly be a lie with somebody elses valid credentials. It is up to your authorization system to determine if the sener of credentials X:Y are still allowed to access anything, and what. Squid ACLs primarily used for that, but also the AD server can reject re-login verification after Basic auth credentialsttl by Squid helper - that will probably result in more popups. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
