squid 中安全使用者認證的故事
從前，南美洲有一個美麗溫暖的虛擬叢林，那裡住著一個魷魚伺服器。這是網路的感知圖像：
<the Internet> | | A | B Users <---------> [squid-Server] <---> [LDAP-Server]當
Users請求訪問網際網路時，squid詢問他們的姓名和護照，通過 ldap 對他們進行身份驗證LDAP，如果 ldap 批准了他們，那麼他就批准了他們。每個人都很高興，直到一些嗅探器在使用者和 squid 之間的路徑中偷走了通行證
$$ path A $$. 這場災難的發生是因為魷魚使用了
Basic-Authentication方法。 叢林的人們聚集在一起解決問題。一些兔子提供使用NTLM的方法。樹木推薦Digest-Authentication時首選蛇。Kerberos畢竟，叢林人提供的許多解決方案都被迷惑了！獅子決定結束這種局面。他喊出了解決方案的規則：
- 解決方案是否安全！
- 該解決方案是否適用於大多數瀏覽器和軟體（例如下載軟體）
- 解決方案是否簡單且不需要其他龐大的子系統（如 Samba 伺服器）
- 方法不得依賴於特殊領域。（例如活動目錄）
然後，猴子提供了一個非常合理-全面-聰明的解決方案，使他成為新的叢林之王！
你能猜出解決方案是什麼嗎？
提示：
squid和 之間的路徑LDAP受獅子保護，因此解決方案不必保護它。**注意：**對不起，如果故事無聊和混亂，但大部分都是真實的！=)
/~\/~\/~\ /\~/~\/~\/~\/~\ ((/~\/~\/~\/~\/~\)) (/~\/~\/~\/~\/~\/~\/~\) (//// ~ ~ \\\\) (\\\\( (0) (0) )////) (\\\\( __\-/__ )////) (\\\( /-\ )///) (\\\( (""""") )///) (\\\( \^^^/ )///) (\\\( )///) (\/~\/~\/~\/) ** (\/~\/~\/) *####* | | **** /| | | |\ \\ _/ | | | | \_ _________// Thanks! (,,)(,,)_(,,)(,,)--------'更新：
Massimo解釋說
Users-squid和squid-之間的身份驗證方法LDAP不必相同。我們可以使用任意方法從使用者那裡獲取身份驗證資訊，並使用任意方法來獲取經過身份驗證的收集數據。但是有一個問題：所有類型的驗證器的輸入/輸出是不一樣的。例如：
- 身份
Basic驗證器應在一行中讀取“使用者名密碼”對並回复 aOK如果使用者密碼正確或ERR- 身份
Digest驗證器應讀取 ausername:realm並回復一個十六進制編碼的HA(A1)或ERR.儘管client-squid 方法和squid-ldap 方法之間沒有直接關係，但是從客戶端收集的數據必須與squid-ldap 部分使用的方法兼容。因此，如果我們在使用者端更改身份驗證方法，我們可能也應該更改我們的身份驗證器。
所以問題簡化為：
- 在第一級，我（猴子！）正在使用者端尋找一種好的身份驗證方法。您推薦哪種方法安全且受大多數瀏覽器支持？我在和
NTLM之間感到困惑。Kerberos``Digest- 我可以在哪裡找到支持所選方法的憑據資訊並通過 LDAP 進行身份驗證的身份驗證器。
Kerberos 不是 HTTP 身份驗證的選項。NTLM 在 IE 以外的任何瀏覽器中都沒有得到很好的支持。Basic 是不安全的，除非你把它放在 AFAIK squid 無法做到的 HTTPS 後面。所以你只剩下摘要了。
在這裡可以幫助您的一個有趣功能是 Squid 用於向客戶端瀏覽器請求身份驗證的方法（路徑 A）根本不需要與它用於實際驗證使用者提供的憑據的方法相關（路徑 B ）。這意味著，你可以讓 Squid 與客戶端瀏覽器“交談”NTLM，但它可以很好地根據 Linux 的內部使用者數據庫 (/etc/passwd) 驗證使用者。無需針對 Windows 域（在路徑 B 上）實際驗證使用 NTLM（在路徑 A 上）獲取的憑據。這同樣適用於客戶端身份驗證方法和伺服器端身份驗證方法的任何可能組合。
在您的情況下，這意味著您可以安全地將 Squid 配置為從客戶端瀏覽器請求 NTLM 身份驗證而不是基本身份驗證，這絕不會要求您實際使用 Samba/WinBind/AD/whatever。
因此，您可以選擇任何您想要的客戶端身份驗證方法，但在使用者使用您選擇的方法提供憑據後，仍會繼續針對 LDAP 伺服器驗證使用者。
當然，魔法發生在
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啟用特定的身份驗證（路徑 A），而“程序”部分設置 Squid 將實際用於驗證使用者提供的憑據的內容。您可以在此處使用您想要的任何驗證程序（甚至是自定義編寫的），只要它可以接收使用者 ID 和密碼並回答“是”或“否”。您只需要使用您用於執行 LDAP 查詢的任何身份驗證器並將其粘貼到“auth_param ntlm”或“auth_param digest”語句中，而不是現在的“auth_param basic”語句中。
更新：
您絕對應該使用squid_ldap_auth作為您的身份驗證器，但如果沒有有關您正在使用的特定 LDAP 伺服器的任何詳細資訊，我無法準確告訴您如何使用。
關於客戶端身份驗證，任何一個都應該是好的；我對 NTLM 很滿意，現在大多數瀏覽器都支持它。
這樣的配置在 squid.conf 中看起來像這樣：
auth_param ntlm program /usr/lib/squid/squid_ldap_auth <parameters>這將使用 NTLM 請求使用者憑據（路徑 A），然後針對 LDAP 伺服器（路徑 B）驗證它們；但這些“參數”嚴格取決於您的 LDAP 實現和配置。
這也可能有所幫助：http ://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html 。