曾几何时，南美有一个美丽的温暖的虚拟丛林，还有一个鱿鱼服务器住在那里。 这里是networking的感性形象：
<the Internet> | | A | B Users <---------> [squid-Server] <---> [LDAP-Server] 当Users请求访问Internet时， squid询问他们的名字和护照，通过LDAP他们进行身份validation，如果ldap批准他们，则授予他们。
大家都很开心，直到有些嗅探者偷走了用户和鱿鱼之间的通行证[pathA]。 这个灾难发生是因为squid使用了Basic-Authentication方法。
丛林里的人聚集在一起解决这个问题。 一些兔子提供使用NTLM的方法。 蛇喜欢Digest-Authentication而Kerberos推荐的树木。
毕竟，丛林的人和所有人提供的解决scheme很困惑！ 狮子决定结束这个情况。 他高呼解决scheme的规则：
然后，一只猴子提供了一个非常合理的，全面的，聪明的解决scheme，使他成为丛林的新国王！
你能猜到什么是解决scheme？
提示： squid和LDAP之间的path受到狮子的保护，因此解决scheme无法保护它。
注意：如果故事是无聊和杂乱的，但是大部分是真的！ =）
/~\/~\/~\ /\~/~\/~\/~\/~\ ((/~\/~\/~\/~\/~\)) (/~\/~\/~\/~\/~\/~\/~\) (//// ~ ~ \\\\) (\\\\( (0) (0) )////) (\\\\( __\-/__ )////) (\\\( /-\ )///) (\\\( (""""") )///) (\\\( \^^^/ )///) (\\\( )///) (\/~\/~\/~\/) ** (\/~\/~\/) *####* | | **** /| | | |\ \\ _/ | | | | \_ _________// Thanks! (,,)(,,)_(,,)(,,)--------'
Massimo解释说， Users – squid和squid – LDAP之间的authentication方法不一定是相同的。 我们可以使用任意的方法来获取用户的authentication信息和任意的方法来authentication收集到的数据。
但是有一个问题：所有types的authentication者的input/输出是不一样的。 例如：
Basicauthentication者应该读取一行中的“用户名密码”对，如果用户通过是正确的或者ERR ，则回复OK Digestauthentication者应该读取username:realm并回复HA(A1)或ERR的hex编码。 尽pipeclient-squid方法和squid-ldap方法没有直接关系，但是从客户端收集的数据必须与squid-ldap部分使用的方法兼容。 因此，如果我们改变用户端的validation方法，我们也许应该改变我们的validation器。
所以这个问题简化为：
在第一级，我（猴子！）在用户端寻找一个很好的authentication方法。 你推荐哪种方法是安全的，并被大多数浏览器支持 ？ 我在NTLM ， Kerberos和Digest之间感到困惑。
在哪里我可以find一个authentication，它支持所选方法的凭证信息，并通过LDAP进行身份validation。
Kerberos不是HTTPauthentication的选项。 IE浏览器以外的任何浏览器都不支持NTLM。 基本是不安全的，除非你把它放在AFAIK鱿鱼不能做的HTTPS。 所以你剩下的文摘
在这里可以帮助你的一个有趣的function是，Squid用来请求客户端浏览器进行authentication的方法（pathA）完全不需要和它用于实际validation用户提供的凭证的方法相关（pathB ）。 这意味着，你可以让Squid和客户端浏览器“交谈”NTLM，但是它可以很好地validation用户对Linux内部用户数据库（/ etc / passwd）的效果。 无需使用NTLM（在pathA上）获取的凭据实际针对Windows域（在pathB上）进行validation。 这同样适用于任何可能的客户端身份validation方法和服务器端身份validation方法的组合。
这意味着你的情况是，你可以安全地configurationSquid从客户端浏览器请求NTLM身份validation，而不是基本身份validation，这不会以任何方式要求您实际使用Samba / WinBind / AD /无论如何。
因此，您可以select任何您想要的方法进行客户端身份validation，但在使用您select的方法提供凭据后，仍然会继续对LDAP服务器进行validation。
当然，在squid.conf发生的squid.conf ：
#auth_param negotiate program <uncomment and complete this line to activate> #auth_param negotiate children 5 #auth_param negotiate keep_alive on #auth_param ntlm program <uncomment and complete this line to activate> #auth_param ntlm children 5 #auth_param ntlm keep_alive on #auth_param digest program <uncomment and complete this line> #auth_param digest children 5 #auth_param digest realm Squid proxy-caching web server #auth_param digest nonce_garbage_interval 5 minutes #auth_param digest nonce_max_duration 30 minutes #auth_param digest nonce_max_count 50 #auth_param basic program <uncomment and complete this line> #auth_param basic children 5 #auth_param basic realm Squid proxy-caching web server #auth_param basic credentialsttl 2 hours #auth_param basic casesensitive off
每个auth_param伪指令为客户端浏览器 （pathA）启用特定的身份validation，而“程序”部分设置Squid将实际使用的validation用户提供的凭据。 只要可以接收用户名和密码，并回答“是”或“否”，您就可以使用任何您想要的authentication程序（甚至是自定义程序）。
你只需要把你用来做LDAP查询的任何validation器拿到“auth_param ntlm”或“auth_param digest”语句中，而不是现在的“auth_param basic”。
你一定要使用squid_ldap_auth作为你的身份validation器，但是我不能确切地告诉你如何没有任何关于你正在使用的特定LDAP服务器的细节。
关于客户端authentication，任何一个都应该是好的; 我对NTLM非常满意，现在大多数浏览器都支持它。
这样的configuration在squid.conf中看起来像这样：
auth_param ntlm program /usr/lib/squid/squid_ldap_auth <parameters>
这将要求使用NTLM的用户证书（pathA），然后根据LDAP服务器validation它们（pathB）; 但这些“参数”严格依赖于您的LDAP实施和configuration。
这也可以帮助： http : //www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html 。