[squid-users] another win2003 ad auth question, but NOT a 'howto' question...

Hi all, I have another win2003 AD SSO auth question, hopefully different. I search and didn't find about what I'm looking for. It's not a 'how to configure' question, I did fine with that part. I notice that I have at least to options to do SSO authentication against a Windows 2003 AD. The ntlm_auth helper that comes with Squid 2.5/2.6 (called SMB) and the ntlm_auth that comes with the Samba 3. I have both working on a test server without problems and doing single sign one (negotiation). Both work with IE and Firefox. My question is about security and performance. I read that with both NTLM auth, for each request I will have TWO DENIED before the authentication processor starts. What is the impact on performance comparing to a solution using SASL/Shadow of NCSA? I have a medium site WAN (about 16 sites) where the biggest have about 110 clients. Each site has it own squid proxy server. I'm also concerned about security, with the clients Windows AD password been sent to the proxy server. The NTLM authentication process (with negotiation) does need to send the password? I tried to read about it but I didn't understand it very well. If it's been send, with tcpdump I notice that it's not in clear text, but if so, what is the strength of the crypto used? How easy will it be for someone to break it? Has anybody have any clues, recommendations or experiences in similar configurations? Which ntlm_auth will be best concerning performance and security? What about a KERBEROS/GSSAPI/SSPI helper for squid on Linux? Do we have any work on progress in that direction? If so, what can I do to help? Squid is awesome. Thanks for everybody, the squid team and users. Regards, Tiago Quadra. Esta mensagem, incluindo seus anexos, pode conter informacoes privilegiadas e/ou de carater confidencial, nao podendo ser retransmitida sem autorizacao do remetente. Portanto, se voce recebeu esta mensagem por engano, por favor, nos informe respondendo imediatamente a este e-mail e em seguida apague-a. A empresa MULTIPLAN nao se responsabiliza por conclusoes, opinioes, ou outras informacoes nesta mensagem que nao se relacionem com sua linha de negocios.
Received on Sun Jul 23 2006 - 09:21:57 MDT