Názory k článku Integrace SQUID proxy serveru do Active Directory (2)

Diky za skvely clanek!
Planuje autor pripadny dalsi clanek s ACL a vyjimkami? Dokumentace se procist da, ale zkusenosti z provozu jsou nedocenitelne.

Jsem naprosto stejného názoru, také bych uvítal další článek.

Vyjímka z čeho? Že to vůbec nemá jít přes proxinu (což je práce pro nastavení firewallu) nebo jít přes proxinu bez ověřování?
Hodně problémů v kombinaci s ověřováním NTLM a negotation je v ředě squid 2.x, protože proxina trvala na dodržení přesně příslušné specifikace, kterou klienti nedodržují (a ani sám Microsoft ve své proxině), přechod na squid 3.x to řeší.
Pokud ani to nepomáhá, tak nastavení, že stránka má projít bez ověřeni např:

# pust ESET na update bez autorizace
acl ESETUPDATE url_regex ^http://*.eset.cz/
acl ESETUPDATE url_regex ^http://*.eset.sk/
acl ESETUPDATE url_regex ^http://*.eset.com/
http_access allow ESETUPDATE

A tohle musí být nacpané před pravidlem tvrvajícím na tom ověřování (v článku by to bylo před "http_access deny !auth").

Jinak pro takové firemní nasazení by slušelo i řešení autokonfigurace nastavení použití proxiny (přislušné DNS a DHCP záznamy a wpad skript dostupný přs HTTP), aby to hlavně pro notebookáře fungovalo OK (jsem ve firmě-jedu přes proxinu, jsem někde venku-jedu přímo, připojím se VPNkou na firmu-opět se přepne na firemní proxinu). Tohle mi ještě nechodí OK v případě, že je i IPv6 síť ve firmě. :-(

Také mám na Eseta lokální zrcadlo. Tohle je pravidlo, co slouží právě pro ně, aby se dostalo ke zdroji. Nepřipouštíme, aby cokoliv komunikovalo jinak, než skrz proxinu. Takže takovéto ACL vyjímky jsou většinou pro takovéto blbosti typu eset, wsus, ...

Nu, s jakou verzí Squid je to provozováno? On totiž má negotiate_wrapper-1.0.1 nějaké potíže v nových squdech a občas to s tím Kerberosem pěkně blbě, OK šlape v 3.0 a asi i 3.1. V řadě 3.2 zmatkuje. Sám autor přiznává a neřeší s tím, že se má použít squid_kerb_ldap (který celou tu konfiguraci uvedenou výše řeší sám v své režii Kerberos+NTLM+ba­sic).
Potom modul squid_kerb_auth, který je přímo součástí squid distribuce je občas dosti magický a není ocohoten s Kerbeors serverem domluvit s pomocí svého ticketu (ať už proti MIT KDC nebo Samba 4), celkem úspěšně řeší použití modulu negotiate_ker­b_auth.

Testuji to s 3.1.19 a slape dobre. S 3.2 nemam momentalne zkusenosti.

Osobne by som sa vobec z NTLM nezdrzoval. Ak nahodou niekde za proxinou bude server nastaveny tak ze bude vediet aj NTLM overovanie tak sa mozu diat cudne veci (NTLM na rozdiel od digest/basic nieje mozne "retazit")

Potíž nastane v okamžiku, kdy mskutil aktualizuje účet v ad, pak totiž nefunguje ten pro sambu a naopak, je třeba kerberos účet odlišit názvem, jinak blbý....